Add EIP-8130 OP Stack design docs - #378
Conversation
|
|
||
| - `op-reth` must implement the new transaction type, intrinsic gas accounting, validation flow, | ||
| state transition logic, precompile behavior, receipt fields, and protocol-injected logs. | ||
| - `op-node`, sequencer transaction ingestion, and batch submission paths must support the new typed |
There was a problem hiding this comment.
op-node
would this be kona-only or also op-node cc @geoknee? Should be light changes on the CL either way iiuc.
There was a problem hiding this comment.
Yes I think this should call out both CL implementations.
| wallet integration flows | ||
| 6. ship in a named OP Stack hardfork after testnet coverage and async review | ||
|
|
||
| The devnet checklist should include: |
There was a problem hiding this comment.
Can (most of) these be written as acceptance tests to catch bugs in CI prior to full devnets?
| Implementation ownership should be made explicit before approval: | ||
|
|
||
| - `op-reth` implementation and consensus tests | ||
| - `op-node`, sequencer ingestion, and batcher compatibility |
There was a problem hiding this comment.
similar to the above: we should clarify what CLs are in scope (op-node, kona, or both)
| and RPC/receipt shapes before activation. | ||
| - Create positive and negative consensus vectors for every transaction path. | ||
| - Run devnets with the final `op-reth` implementation. | ||
| - Complete multiple audit cycles across spec, `op-reth`, contracts, and wallet flows. |
There was a problem hiding this comment.
Complete multiple audit cycles across...
op-reth
Highlighting this for discussion. Do we want op-reth changes to be in scope this time?
There was a problem hiding this comment.
Base has a fork of op-reth, we discussed we may be able to include op-reth in the audit itself given minimal changes. Will continue tracking this
| ### Activation, Derivation, and System Transactions | ||
|
|
||
| 8130 should activate in a named OP Stack hardfork. The fork name and activation schedule are TBD. | ||
| Before activation, the new transaction type must be rejected. After activation, it should be |
There was a problem hiding this comment.
Calling out some prior art, very similar to how we dealt with EIP-7702 transactions in the Isthmus fork https://github.com/ethereum-optimism/optimism/blob/09ef0299a1a9a9d81553291942fb9e169cbbdfb6/op-e2e/actions/proofs/isthmus_setcode_tx_test.go#L148.
| and receipt `phaseStatuses` | ||
| - mempool policy limits for transaction shape, owner changes, payer authorization, and validation | ||
| cost | ||
| - auto-delegation to the default account implementation and explicit delegation override behavior |
There was a problem hiding this comment.
Is the idea that we default delegate to a particular pre-deploy and thereby enable a default sig scheme that the chain maintainer can update over time?
There was a problem hiding this comment.
The wallet validation logic and the wallet code itself is decoupled. Verifiers supply validation logic and wallets add/configure those via the account configuration contract.
The default code would be very simple and just have executeBatch and receiver hooks. Its not expected to be upgraded often, but I agree this should just be a chain owned precompile. The interface the wallet implements should be a minimal agreed standard.
| - The change spans consensus logic, node policy, RPC, tooling, and wallet infrastructure, so | ||
| rollout coordination is non-trivial. | ||
| - Initial deployments may need tighter verifier and nonceless-mode limits than the upstream EIP | ||
| theoretically permits. |
There was a problem hiding this comment.
I have discussed designs where we are able to use EIP 8130 to achieve backwards compatible signatures by writing a verifier which authorizes an EIP 8130 transaction with equivalent semantic meaning as the original transaction format. That does mean; however, that it does not use the passed hash at all and does most via TX_CONTEXT.
Is this usage intended/encouraged?
There was a problem hiding this comment.
Though 8130 technically does allow for any logic to go into a verifier the 8130 spec will require chains to not allow these custom verifiers on the AA txn path for validation (if they do its considered "out of spec"). The goal is for wallets to have a highly portable set of validation methods that they are sure are available everywhere.
We believe the number of validation methods will be small (k1, p256, webauth, ...) and should just be agreed upon via the EIP itself or a companion ERC that gets updated (how consensus works here is still up for debate but if there is a good reason to add a validation method, it shouldnt be difficult to get support as adding a new one just means permissionless deployment + a mempool rule change.)
| The following decisions should be resolved, or explicitly accepted as TBD, before this proposal is | ||
| ready for approval: | ||
|
|
||
| - fork name and activation schedule |
There was a problem hiding this comment.
I think we wouldn't commit to this here; we tend to run a "turn up and go" approach to forks/upgrades. So when the work is done/merged, we can switch on some feature toggles such that it activates with the next upgrade that has an open scope for features.
So predicting that from where we stand now comes down to estimating how long it takes to do the work (plus tests and auxiliary tasks like governance posts, documentation, threat modelling etc) and get it merged.
There was a problem hiding this comment.
More information on the process end to end is here https://github.com/ethereum-optimism/pm/blob/main/src/sdlc.md.
| - final RPC extension shapes, including accepted-verifier discovery, 2D nonce queries, and receipt | ||
| extensions | ||
| - final `op-reth` implementation scope and required consensus test coverage | ||
| - audit owners, audit scope, and signoff criteria for each audit cycle |
There was a problem hiding this comment.
|
|
||
| ## Risks & Uncertainties | ||
|
|
||
| - 8130 is still draft and may continue to change upstream. |
There was a problem hiding this comment.
When might we be able to consider 8130 "frozen"?
There was a problem hiding this comment.
Goal is as soon as possible but working on getting feedback from external teams.
EIP will move out of draft once we have agreed upon the spec.
| The OP Stack implementation should include the core 8130 feature set: | ||
|
|
||
| - the new AA transaction type | ||
| - the Account Configuration system contract |
There was a problem hiding this comment.
It has a solidity version for non 8130 chains.
It can be implemented as a precompile on 8130 chains though, these both share the same interface.
We could keep it as solidity as well, and the protocol just reads/updates storage slots directly
| by the execution client after activation. `op-node` and the batcher still need compatibility work so | ||
| that the new transaction type is accepted, propagated, included, and decoded correctly throughout the | ||
| stack. |
There was a problem hiding this comment.
Again just calling out some prior art to guide the implementation ethereum-optimism/optimism#14197
| 8130 allows nodes to maintain a verifier allowlist, and the OP Stack should help define a canonical | ||
| verifier set as part of the standard. This verifier set should be agreed upon by the client and |
There was a problem hiding this comment.
Any thoughts on how that canonical verifier set should be maintained or expressed? I would suggest hardcoding it into the node software as a default and allowing it to be overridden by command line flags.
There was a problem hiding this comment.
Just to clarify my understanding also that the allowlist is essentially a sequencer policy, not baked into the protocol? This would allow it to be extended without the need for hardforks.
There was a problem hiding this comment.
Here's another place where the standard allowlist could be expressed https://specs.optimism.io/protocol/configurability.html?highlight=standard#op-stack-configurability.
There was a problem hiding this comment.
It is not baked into the protocol correct.
It would look like a mempool rule which would just default to what we define in the EIP.
K1, P256, Webauth, Delegate is likely first 4 (will decide this for EIP finalization).
Extending this list will either be with modifications to the EIP itself or by a companion ERC.
| - address aliasing behavior for delegated accounts | ||
| - bridge convenience methods and any EOA-only checks | ||
| - assumptions about `tx.origin`, `msg.sender`, and code presence | ||
| - tooling that currently treats "has code" and "is a contract" as equivalent |
There was a problem hiding this comment.
Prior art here ethereum-optimism/optimism#14506
|
|
||
| 1. ratify the adoption design and complete a companion FMA | ||
| 2. choose constants and fixed addresses in coordination with the upstream EIP | ||
| 3. prototype the feature in `op-reth` |
There was a problem hiding this comment.
We would typically want to merge this to our develop branch incrementally, but behind a feature flag (https://github.com/ethereum-optimism/design-docs/blob/main/protocol/decoupled-features.md). This allows us freedom to activate the feature in e2e tests, and to easily schedule it into a hardfork when ready.
| New OP Stack feature development, including the next Karst hardfork, is expected to happen on | ||
| `op-reth` only. `op-geth` remains supported for security patches and critical bug fixes through May | ||
| 31, 2026, after which support ends. Because 8130 targets new hardfork functionality, the adoption |
| - fork name and activation schedule | ||
| - fixed addresses for the Account Configuration contract, precompiles, verifier set, and default | ||
| account implementation | ||
| - exact canonical verifier bytecode and deployment process |
There was a problem hiding this comment.
I am wondering if this could follow our new L2CM (L2 Contracts Manager) process which will go live soon #351
|
I had a question about the relation between 8130 and EIP 8141. If I understand correctly, the two EIPs attempt to save the same problem, but there is a concern with 8141 that it would allow users to DoS the sequencer and cause unbounded unpaid EVM compute. 8130 solves this via an allowlist of verifier contracts. Aligning with L1 is a desirable thing in general. Often there are L2 specific concerns which justify a divergence; but I wonder what a minimal diff might look like? Namely, EIP-8141 plus an allowlist of verifier contracts. Is such a thing feasible? What would the tradeoffs be? |
8141 is under development, and spec is changing but can answer this as it is now: 8130 accounts can work in 8141 system as well (but account needs to be upgraded to just call account config). There are quite a few differences but 8130 is designed to be more performant and more opinionated where as 8141 leans in to being fully generic and let's follow up specifications try to define logic. Note that 8141 is not generic enough to enable what 8130 provides however (it does not allow approval delegation to external contracts). |
| Adopting 8130 on the OP Stack requires coordinated work across the protocol and the surrounding | ||
| stack: | ||
|
|
||
| - `op-reth` must implement the new transaction type, intrinsic gas accounting, validation flow, |
There was a problem hiding this comment.
Should the design explicitly call out a separate mempool? Validation and mempool are different layers: validation defines admissibility, while the pool handles pending storage, ordering, replacement, eviction, and DoS limits.
| - fixed addresses for the Account Configuration contract, Nonce Manager, Transaction Context, | ||
| initial verifier set, and default account implementation must be standardized for chains | ||
| that opt into the feature. These addresses are TBD until the upstream spec is final. | ||
| - SDKs, wallets, explorers, and indexers must be updated to understand the new transaction type, |
There was a problem hiding this comment.
It may be worth explicitly requiring op-up support/tests for this tx type.
| - Secp256k1 | ||
| - P256 | ||
| - P256 WebAuthn / passkey | ||
| - Delegate, enabling a sub-account model |
There was a problem hiding this comment.
Suggest adopting a Tempo-style access key model instead of full-authority delegation. A delegated/sub-account key should support scoped permissions, e.g. spend limits, allowed targets/selectors/assets, validity windows, and revocation semantics. Full delegation makes compromise of the delegate key equivalent to compromise of the primary account, which seems too strong for the intended sub-account/session-key use case.
There was a problem hiding this comment.
The delegate key type is actually meant to power the sub account model as outlined in this blog post - https://blog.base.dev/subaccounts . So its meant to be that a parent key has full control over its sub accounts, not to be used as a session key on some parent account.
There was a problem hiding this comment.
We are exploring account key policies for session key model here:
https://github.com/ethereum/EIPs/pull/11648/changes
Key is added and can restrict calls to certain policy contracts (similar to https://github.com/base/account-policies) which will perform any sort of extra validity, spend limits, allowed access rules checks but executed within the EVM. If compliant with the policy the contract can call the wallet to execute the calls. Note this leaves it up to wallet designers to build their policy system.
Let me know what you think on this + delegate system and if there are any other use cases we might be missing or any other thoughts on the design!
5 participants
Summary
Test plan