feat: enforced batch mode #68
Conversation
zimpha
force-pushed
the
feat/enforced-batch
branch
from
8612778 to
aee35b9
Compare
zimpha
force-pushed
the
feat/enforced-batch
branch
from
aee35b9 to
d851e8e
Compare
There was a problem hiding this comment.
LGTM!
with the new batch design this will need to change again but the main mechanism of
- track time of latest finalized batch
- if too much time elapsed allow anyone to commit batch + proof and disallow sequencer to submit via usual methods
- only allow security council to deactivate this enforced/permissionless mode
should stay the same and just the interface of what/how a batch needs to be passed should change.
| @@ -46,6 +46,15 @@ library BatchHeaderV3Codec { | |||
| } | |||
| } | |||
|
|
|||
| /// @notice Get the blob versioned hash of the batch header. | |||
| @@ -172,6 +197,11 @@ contract ScrollChain is OwnableUpgradeable, PausableUpgradeable, IScrollChain { | |||
| _; | |||
| } | |||
|
|
|||
| modifier whenEnforcedBatchNotEnable() { | |||
There was a problem hiding this comment.
| modifier whenEnforcedBatchNotEnable() { | |
| modifier whenEnforcedBatchNotEnabled() { |
| } | ||
| } | ||
| // initialize enforcedBatchParameters | ||
| enforcedBatchParameters.maxDelayEnterEnforcedMode = _maxDelayEnterEnforcedMode; |
There was a problem hiding this comment.
I assume it won't be updated when we set it. Sure I can add a method to update it.
| * Structs * | ||
| ***********/ | ||
|
|
||
| struct EnforcedBatchParameters { |
There was a problem hiding this comment.
Would this add +1 SSTORE cost for normal commit batch and finalize bundle txs?
There was a problem hiding this comment.
my guess is about 4600 gas.
| // explicit set enforce batch enable | ||
| parameters.enforcedModeEnabled = true; | ||
| // reset `lastCommittedBatchIndex` | ||
| parameters.lastCommittedBatchIndex = uint64(lastFinalizedBatchIndex); |
There was a problem hiding this comment.
I think we've discussed this before but I forgot the conclusion; doesn't this make "fast L2 finality" impossible? @jonastheis
In the future with the infallible chain derivation, we could just have a permissionless fallback for batch commitment and finalization (but not need to revert unfinalized batches).
There was a problem hiding this comment.
Overall looks good, but this will have a lot of conflicts with other changes planned for this upgrade. Do you want to still submit them as separate PRs and then merge them into a single unified PR that we share with the auditors?
There was a problem hiding this comment.
yes, I will create a branch and all related PR will merged into this branch.
No description provided.