Skip to content

Add design doc for smart batching feature #229

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jbearer wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Add design doc for smart batching feature #229

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
562a82d
Add design doc for smart batching feature
jbearer Mar 25, 2025
99d165b
Add single point of failure discussion
jbearer Mar 25, 2025
2139117
Add upgrade mechanism for inbox address
jbearer Apr 2, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions protocol/smart-batching.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Copy Markdown
Contributor

@tynes tynes Apr 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown

@samlaf samlaf Apr 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?


### Compatibility

The change is backwards compatible. If the inbox address is not a contract, transactions to it will never revert. Thus the only action necessary to opt in is to deploy a contract and upgrade to change the batch inbox address.
Expand Down