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
| @@ -44,6 +44,8 @@ blob data. | |||
|
|
|||
| Modify the L1 derivation stage of the pipeline (`calldata_source` and `blob_data_source`) to fetch receipts for each L1 block they process, and skip any transaction where the `status` field of the receipt is 0 (reverted transactions). | |||
|
|
|||
| To support existing chains opting into this feature, we also make it possible for chains to update their inbox address, by adding an owner-only `setBatchInbox` method to the `SystemConfig.sol` contract. Chains can then use the existing mechanisms for updating the `SystemConfig` to change their batch inbox address to that of a smart contract. | |||
There was a problem hiding this comment.
This will also need to take into account passing the information into the L2 system, so there will likely need to be an UpdateType and the L1 attributes tx calldata will need to include the batch inbox address. Its not ideal to keep bloating the size of the L1 attributes tx but its a clear way to continue to add config and would result in a larger diff to the proof system if we didn't include it in the calldata
There was a problem hiding this comment.
@tynes adding batchInbox to SystemConfig and making it settable + ingestable via an Update event feels natural, but I'm curious as to the alternative of just updating the config.json and then updating the FaultDisputeGame's prestateHash (which is done for every hardfork already). What are the pros and cons of both approaches?
I guess another one I'm curious about is what if we don't even add a SetBatchInbox() function, and just do a SystemConfig contract upgrade to change the value. What happens in such a case, would that upgrade get automatically picked up by the derivation pipeline the same way an UpdateType event would?
| - TEE-sequencer: L1 enforces that the rollup sequencer runs in a TEE, which enforces additional sequencing policies: | ||
| - Unichain wants to use a TEE for Flashblocks and verifiable priority ordering. Currently the derivation pipeline cannot check the TEE attestation, so the current implementation is no better than a trusted sequencer. This proposed change would provide an avenue to fix that. It will also be needed for the UVN. | ||
| - The Celo sequencer will run a TEE that first posts its transaction batches to a fast BFT consensus (run by Espresso Network) and only posts batches to the L1 that were already confirmed by this BFT consensus. This allows users and protocols (exchanges, bridges, etc) to obtain rollup soft confirmations (pre-L1 finality) from the fast BFT consensus that are more secure than confirmations coming from a regular centralized sequencer. Other OP stack chains are interested in adding this protective layer as well. | ||
| - L1 directly verifies that the sequenced batches have been confirmed by an external layer (e.g. Espresso) instead of relying on a TEE. |
There was a problem hiding this comment.
What does "confirmed" mean here? Are you talking about EspressoDA here or something else? Because one thing we are currently looking at for EigenDA is to verify a certificate of availability in the batcher inbox.
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.