Skip to content

fix: Rollup invalid archive error#14785

Merged
spalladino merged 2 commits intonextfrom
palla/invalid-archive
Jun 6, 2025
Merged

fix: Rollup invalid archive error#14785
spalladino merged 2 commits intonextfrom
palla/invalid-archive

Conversation

@spalladino
Copy link
Contributor

@spalladino spalladino commented Jun 4, 2025

Fixes multiple Rollup__InvalidArchive errors that were popping up on tests since #13700.

Example from this run:

09:42:54 [09:42:54.569] VERBOSE: sequencer Unable to build/enqueue block Rollup__InvalidArchive(0x2fdc940e38cff0a9fd112204b3ad9b7e75c3efaf9495dd7aeaecbcc8d2bba20f, 0x18674a63a7dd5a173cff9633512b7e5bd6b5536ea0b7c96929dcc68473c31e45)

The cause for this was the removal of the canProposeAtNextEthBlock check here. This call to the rollup contract was removed since we were now manually checking the proposer using the epoch cache (which is a good thing!), but we lost the check for the latest archive root.

This meant that, if the sequencer started building before the archiver was caught up to the previous block, it would build off an older chain tip, and only get rejected during block publishing. Note that in an actual setting, it should actually fail to collect attestations, since the proposal should be deemed invalid by validators due to a wrong parent, but most of our e2e tests don't have a committee.

This PR makes the sequencer check that the archiver has synched to the previous L1 block before proceeding. Note that L1 missed slots would cause issues here, but we can address that when we get to #14766. In addition, this PR restores the early call to canProposeAtNextEthBlock to be on the safe side before we start building.

@spalladino spalladino force-pushed the palla/invalid-archive branch from e2a75a4 to 7e0ff04 Compare June 4, 2025 20:51
@spalladino spalladino marked this pull request as ready for review June 4, 2025 21:00
@spalladino spalladino force-pushed the palla/invalid-archive branch from 7e0ff04 to 3411e8a Compare June 4, 2025 21:11
// Double check we are good for proposing at the next block before we start operations.
// We should never fail this check assuming the logic above is good.
const proposerAddress = proposerInNextSlot ?? EthAddress.ZERO;
const slotAndBlock = await this.publisher.canProposeAtNextEthBlock(chainTipArchive.toBuffer(), proposerAddress);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will this fail when no committee? 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvm, checked the L1 contract and it returns 0 address 👍

@@ -623,7 +666,7 @@ export class Sequencer {
* We don't check against the previous block submitted since it may have been reorg'd out.
* @returns Boolean indicating if our dependencies are synced to the latest block.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit to update the jsdoc here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! Will sneak in the change along with another PR.

Comment on lines +274 to +276
this.log.warn(`Failed canProposeAtTime check with ${ignoredErrors.find(e => err.message.includes(e))}`, {
error: err.message,
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this warning going to be potentially printed every run of the sequencer work loop?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This now only gets called after all the "manual" checks in the sequencer, so it gets printed only if the sequencer has done all checks locally for building a block and they pass, but the rollup contract disagrees.

@spalladino spalladino added this pull request to the merge queue Jun 6, 2025
Merged via the queue into next with commit 2145465 Jun 6, 2025
4 checks passed
@spalladino spalladino deleted the palla/invalid-archive branch June 6, 2025 14:01
danielntmd pushed a commit to danielntmd/aztec-packages that referenced this pull request Jul 16, 2025
Fixes multiple `Rollup__InvalidArchive` errors that were popping up on
tests since AztecProtocol#13700.

Example from [this run](http://ci.aztec-labs.com/c82b760acf321da6):
```
09:42:54 [09:42:54.569] VERBOSE: sequencer Unable to build/enqueue block Rollup__InvalidArchive(0x2fdc940e38cff0a9fd112204b3ad9b7e75c3efaf9495dd7aeaecbcc8d2bba20f, 0x18674a63a7dd5a173cff9633512b7e5bd6b5536ea0b7c96929dcc68473c31e45)
```

The cause for this was the removal of the `canProposeAtNextEthBlock`
check
[here](https://github.com/AztecProtocol/aztec-packages/pull/13700/files#diff-1c2150b6e6b122e3a184b1132b8d6946e4e27fefe53381035810638fabcebe9cL384).
This call to the rollup contract was removed since we were now manually
checking the proposer using the epoch cache (which is a good thing!),
but we lost the check for the latest archive root.

This meant that, if the sequencer started building _before_ the archiver
was caught up to the previous block, it would build off an older chain
tip, and only get rejected during block publishing. Note that in an
actual setting, it should actually fail to collect attestations, since
the proposal should be deemed invalid by validators due to a wrong
parent, but most of our e2e tests don't have a committee.

This PR makes the sequencer check that the archiver has synched to the
previous L1 block before proceeding. Note that L1 missed slots would
cause issues here, but we can address that when we get to
#[14766](AztecProtocol#14766).
In addition, this PR restores the early call to
`canProposeAtNextEthBlock` to be on the safe side before we start
building.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants