You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: