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.
| } | ||
| } | ||
|
|
||
| /// @notice Get the blob versioned hash of the batch header. |
src/L1/rollup/ScrollChain.sol
Outdated
| _; | ||
| } | ||
|
|
||
| modifier whenEnforcedBatchNotEnable() { |
There was a problem hiding this comment.
| modifier whenEnforcedBatchNotEnable() { | |
| modifier whenEnforcedBatchNotEnabled() { |
src/L1/rollup/ScrollChain.sol
Outdated
| } | ||
| } | ||
| // 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.
There was a problem hiding this comment.
@jonastheis do you think we might want to update this in the future? Seems safer to me to keep this updatable, at least for the 1st version.
There was a problem hiding this comment.
Yeah I think would be better if we (I assume Security council) can update it
src/L1/rollup/ScrollChain.sol
Outdated
| * 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.
src/L1/rollup/ScrollChain.sol
Outdated
| // 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.
With chain derivation we will need to change the mechanism anyway. So I think it is okay to revert here.
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.