-
Notifications
You must be signed in to change notification settings - Fork 450
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modify the batch poster to support the delay buffer feature #2758
base: bold-review
Are you sure you want to change the base?
Conversation
Get the delay message accumulator from the previous message.
* Test batch poster without delay buffer works * Test delay buffer don't force batch without delayed messages
Rebase the delay buffer PR on top of BoLD's little merge. Then, use the BoLD version of the contracts when appropriate instead of using the delay-buffer development branch.
The tests are failing because of the base branch (bold-review). Locally, the delay-buffer tests are passing, so I'm setting this PR as ready to review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks like a very good PR.
@@ -0,0 +1,321 @@ | |||
package deploy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing copyright header.
This PR introduces the delay buffer from the sequencer inbox to the batch poster. The delay buffer is a feature that limits repeated sequencer censorship while maintaining the property that allows the sequencer to recover after an outage.
At the high level, we want to achieve two things. The first is ensuring the batch poster posts batches often enough not to consume blocks from the delay buffer. The second is modifying the batch poster to post delay proofs when a batch contains a delayed message.
An immutable field called isDelayBufferable is in the sequencer inbox to indicate whether the delay buffer is enabled. We use this field to enable or disable the delay buffer feature in the batch poster. When getting this field, if the EVM returns an execution error, the batch poster assumes it is using an old version of the contracts.
When creating a batch, if the delay buffer is enabled, the batch contains a delayed message, and the time since the first delayed message is greater than the threshold, then the batch poster posts the batch immediately. We do this to ensure we are not consuming from the delay buffer.
If the batch contains a delayed message, the batch poster includes a delay proof when submitting it. A delay proof contains the accumulator hash of the last accepted delayed message and the current batch's first delayed message. The batch poster stores the contents of the first delayed message in the batchSegments structure to reference it later. Then, depending on whether the batch contains a delayed message, it calls the corresponding contract method in the encodeAddBatch function.
The delay buffer system tests use the BoLD version of the contracts, so this PR also adds initial support for them in the NodeBuilder. All other tests are left unmodified and use the legacy version of the contracts.
Close NIT-2510