Add design doc for smart batching feature #229
Conversation
|
|
||
| ### Resource Usage | ||
|
|
||
| The derivation pipeline already fetches transaction receipts in several places (e.g. attributes |
There was a problem hiding this comment.
I believe this may mean that L1 execution will have to happen in the proof system, to recreate the execution in the L1 inbox to create the receipt. We may be able to get around it by unwrapping the receipts from the receipts root in the header if we have a trusted L1 blockhash, but would want to check with @Inphi @ajsutton @clabby to understand the tradeoffs here
There was a problem hiding this comment.
We may be able to get around it by unwrapping the receipts from the receipts root in the header if we have a trusted L1 blockhash
This was how I imagined it would work. Is there not already something like this in the proof system, since the derivation pipeline already depends on receipts (e.g. for attributes derivation)?
| rollup-specific and opt-in. | ||
|
|
||
| ### Single Point of Failure and Multi Client Considerations | ||
|
|
There was a problem hiding this comment.
op-node is a single point of failure. What is the worst case that can happen because of that? Changes to code that are a single source of failure mean that bugs introduced become consensus, unless there is an explicit runbook with social layer buy in around rolling back the chain in case of a bug
There was a problem hiding this comment.
Added some brief discussion on this
| address can be configured to the address of a contract, the contract cannot stop batches from being ingested by the derivation pipeline, because **the derivation pipeline does not check revert status of transactions**. Thus, even if the contract reverts, the reverting transactions can still end up included in an L1 block, and the derivation pipeline will still parse and execute their calldata or | ||
| blob data. | ||
|
|
||
| ## Proposed Solution |
There was a problem hiding this comment.
Right now its not possible to reconfigure the batch inbox and existing chains generally send to an address with no know private key. Any thoughts on how to handle this?
- Enable ability to modify batch inbox address dynamically
- Only allow new chains to use this feature?
There was a problem hiding this comment.
Hmm so your saying it's not currently possible to do a chain upgrade to change the inbox address? If not we would definitely want to add this ability
There was a problem hiding this comment.
It is not currently possible for a chain to change its batch inbox. It is hardcoded as part of the chains genesis config
There was a problem hiding this comment.
Gotcha, I'll work on adding this, thanks
Description
Design document for a feature we call "smart batching", i.e. allowing the batch inbox to be a smart contract for customizable batching or sequencing logic.
Tests
No tests, design doc only.