In several places we compute the expected timestamp of the next L1 block as l1Client.getBlock().timestamp + ethereumSlotDuration. This allows us to query the expected state of the rollup contract on the next L1 block.
|
const time = (currentL1Timestamp ?? 0n) + BigInt(this.l1constants.ethereumSlotDuration); |
|
const nextEthTimestamp = BigInt((await this.publicClient.getBlock()).timestamp + BigInt(this.ethereumSlotDuration)); |
|
const ts = BigInt((await this.publicClient.getBlock()).timestamp + BigInt(this.ethereumSlotDuration)); |
|
const timeOfNextL1Slot = (await this.client.getBlock()).timestamp + slotDuration; |
|
const ts = BigInt((await this.l1TxUtils.getBlock()).timestamp + this.ethereumSlotDuration); |
However, if there's a missing L1 block, then the next L1 block will land 24 seconds after the latest one, not 12. Using the wrong L1 timestamp affects the resulting L2 slot, which means we may operate under a wrong committee/proposer.
Note that missed L1 blocks are somewhat common, so we can definitely get hit by this.
I'm not sure about the best fix. One option is to avoid relying on l1Client.getBlock().timestamp, and use the system clock instead, assuming it's reasonably synchronized. Another option is to try and hit the consensus endpoint (as opposed to the execution), but I don't know if it'd be consistently reliable. Thoughts?
In several places we compute the expected timestamp of the next L1 block as
l1Client.getBlock().timestamp + ethereumSlotDuration. This allows us to query the expected state of the rollup contract on the next L1 block.aztec-packages/yarn-project/archiver/src/archiver/archiver.ts
Line 365 in 7fa2424
aztec-packages/yarn-project/sequencer-client/src/global_variable_builder/global_builder.ts
Line 60 in 7fa2424
aztec-packages/yarn-project/sequencer-client/src/global_variable_builder/global_builder.ts
Line 105 in 7fa2424
aztec-packages/yarn-project/ethereum/src/contracts/rollup.ts
Line 374 in 7fa2424
aztec-packages/yarn-project/sequencer-client/src/publisher/sequencer-publisher.ts
Line 298 in 7fa2424
However, if there's a missing L1 block, then the next L1 block will land 24 seconds after the latest one, not 12. Using the wrong L1 timestamp affects the resulting L2 slot, which means we may operate under a wrong committee/proposer.
Note that missed L1 blocks are somewhat common, so we can definitely get hit by this.
I'm not sure about the best fix. One option is to avoid relying on
l1Client.getBlock().timestamp, and use the system clock instead, assuming it's reasonably synchronized. Another option is to try and hit the consensus endpoint (as opposed to the execution), but I don't know if it'd be consistently reliable. Thoughts?