feat(e2e): added timeout tests and switch to seconds in timestamps #17
Conversation
| uint64 nanoTimestamp = uint64(block.timestamp * 1_000_000_000); | ||
| if (msg_.packet.timeoutTimestamp <= nanoTimestamp) { | ||
| revert IBCInvalidTimeoutTimestamp(msg_.packet.timeoutTimestamp, nanoTimestamp); | ||
| if (msg_.packet.timeoutTimestamp <= block.timestamp) { |
There was a problem hiding this comment.
The implications of this, combined with the packetCommitment creation that changes from seconds to nanoseconds, as far as I can tell are:
- The packet from the other chain will need to use seconds
- The packet commitment from the other chain will need to also commit to nanoseconds
There was a problem hiding this comment.
The packet commitment from the other chain is ibc-go, so it already uses nanoseconds.
We do not impose any requirements on the packet being submitted to the counterparty chain. We only require that packets submitted to this chain by the relayer use seconds.
There was a problem hiding this comment.
Ok, I see. All packet and light clients need to be nanoseconds on ibc-go and all packets and light clients need to be second in the evm implementation. And the relayers just need to translate the timestamps, is that correct?
| uint64 nanoTimestamp = uint64(block.timestamp * 1_000_000_000); | ||
| if (msg_.timeoutTimestamp <= nanoTimestamp) { | ||
| revert IBCInvalidTimeoutTimestamp(msg_.timeoutTimestamp, nanoTimestamp); | ||
| if (msg_.timeoutTimestamp <= block.timestamp) { |
There was a problem hiding this comment.
The implications for sending packets like this would only be that the light client needs to use seconds (since that is what it will check against for a timeout). That seems both reasonable and easy to reason about.
There was a problem hiding this comment.
sp1 light client is already using seconds for timestamps
No description provided.