bug: Wrong computation of next L1 block timestamp on missed slots

[spalladino]

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

const time = (currentL1Timestamp ?? 0n) + BigInt(this.l1constants.ethereumSlotDuration);

aztec-packages/yarn-project/sequencer-client/src/global_variable_builder/global_builder.ts

Line 60 in 7fa2424

const nextEthTimestamp = BigInt((await this.publicClient.getBlock()).timestamp + BigInt(this.ethereumSlotDuration));

aztec-packages/yarn-project/sequencer-client/src/global_variable_builder/global_builder.ts

Line 105 in 7fa2424

const ts = BigInt((await this.publicClient.getBlock()).timestamp + BigInt(this.ethereumSlotDuration));

aztec-packages/yarn-project/ethereum/src/contracts/rollup.ts

Line 374 in 7fa2424

const timeOfNextL1Slot = (await this.client.getBlock()).timestamp + slotDuration;

aztec-packages/yarn-project/sequencer-client/src/publisher/sequencer-publisher.ts

Line 298 in 7fa2424

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?

[just-mitch]

Definitely I'd prefer to use system time, and there should be a single reference point in the node that serves wall time, l1 slot, and l2 slot.

Then that component can check for clock skew.

[spalladino]

FWIW we already have a DateProvider we pass around to some components

[just-mitch]

It should just be generalized to TimeProvider. God or just Clock haha

[AztecBot]

This issue was automatically closed because it was referenced in PR #21769 which has been merged to the default branch.

View workflow run