Skip to content
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

Support fork id upgrades without down time for the trusted state #2236

Closed
agnusmor opened this issue Jun 28, 2023 · 0 comments · Fixed by #2237
Closed

Support fork id upgrades without down time for the trusted state #2236

agnusmor opened this issue Jun 28, 2023 · 0 comments · Fixed by #2237
Assignees
Labels
Milestone

Comments

@agnusmor
Copy link
Contributor

agnusmor commented Jun 28, 2023

Rationale

When doing a forkid upgrade, now it is needed to stop the RPC service to avoid generate new trusted batches and wait until the pending batches are virtualized and verified. When this is finished we do the forkid upgrade at SC level and then we resume the operation (new batches are generated using the new fork id). This implies to have the network down during a long time. The idea is to have a mechanism that stops to generate new virtual and verified batches while we wait that the pending batches are virtualized/verified, but without the need to stop the RPC service and continuing with the generation of trusted batches and confirming txs (thus the user don't have the "perception" that the network is stopped or it is being upgraded)

Implementation

The idea is to add a configuration parameter to define a future batch (ForkUpgradeBatchNumber) that will be the batch that will use the new forkid. The sequencesender will continue working as usual until it reaches this batch, at this moment the sequence including this batch need to be closed and sent to L1 and the sequencesender will stop sequencing (virtualize) new batches. Also the sequencer/rpc will work with the current forkid until it reaches the ForkUpgradeBatchNumber, at this point rpc/sequencer will start to use the new forkid with the executor. When all the batches until ForkUpgradeBatchNumber are virtualized/verified, we will proceed to update the SC to set the new forkid (from this ForkUpgradeBatchNumber) and after this we will set ForkUpgradeBatchNumber=0 (to disable it) and restart the node to start to work as usual with the new SC forkid and also we will start Provers using new forkid to verfiy the new batches from ForkUpgradeBatchNumber

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant