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
The OP Stack is designed such that there is a single batcher key in the L1 SystemConfig contract. This EOA is controlled by the op-batcher, which is responsible for publishing the data to L1. A batch is only considered canonical if it is from the batcher key and to the batch inbox contract.
This design is simple but is not super flexible. Since it must be an EOA, batches cannot be submitted using a smart contract wallet. It is also not possible to arbitrarily program batch validity rules. If we modified the batch inbox to be a smart contract, a canonical batch could be decided by an event emitted by the smart contract.
Using a smart contract event to determine batch validity would allow developers to permissionlessly innovate on leader election mechanisms. It could be possible to build a simple round robin scheme to enable a more decentralized sequencer, where different sequencers can be allowed to submit the next set of batches. It would also be possible to build an attestation network that can hook into the batch validity rules where a batch is only considered canonical if enough of the attesters signed off on the batch.
In practice an event definition would need to be defined that would signal to the op-node that the transaction includes a valid batch. As long the configured batch inbox emitted this event, then the op-node would know to interpret the batch as valid and attempt to process it further. This was explored in ethereum-optimism/ecosystem-contributions#63
The text was updated successfully, but these errors were encountered:
The OP Stack is designed such that there is a single batcher key in the L1
SystemConfig
contract. This EOA is controlled by the op-batcher, which is responsible for publishing the data to L1. A batch is only considered canonical if it is from the batcher key and to the batch inbox contract.This design is simple but is not super flexible. Since it must be an EOA, batches cannot be submitted using a smart contract wallet. It is also not possible to arbitrarily program batch validity rules. If we modified the batch inbox to be a smart contract, a canonical batch could be decided by an event emitted by the smart contract.
Using a smart contract event to determine batch validity would allow developers to permissionlessly innovate on leader election mechanisms. It could be possible to build a simple round robin scheme to enable a more decentralized sequencer, where different sequencers can be allowed to submit the next set of batches. It would also be possible to build an attestation network that can hook into the batch validity rules where a batch is only considered canonical if enough of the attesters signed off on the batch.
In practice an event definition would need to be defined that would signal to the
op-node
that the transaction includes a valid batch. As long the configured batch inbox emitted this event, then theop-node
would know to interpret the batch as valid and attempt to process it further. This was explored in ethereum-optimism/ecosystem-contributions#63The text was updated successfully, but these errors were encountered: