EIP-8430 splits the transaction type out of [EIP-8130]( EIP-8130: Keystore Accounts ) into its own EIP, with no Keystore dependency. EIP-8130 keeps the Keystore.
- The transaction type is useful on its own. It works for today’s EOAs with native secp256k1 authentication, so it can ship first and the Keystore can follow later.
- The Keystore is useful without this transaction type: through ERC-4337, direct contract calls, or other native transports such as frame transactions (EIP-8141).
I think there is one replay-identity closure issue at the account_changes extension boundary.
replay_id is intended to identify the logical nonce-free transaction and deliberately excludes sender_auth / payer_auth because authorization bytes can vary without changing that logical transaction. But it currently commits raw account_changes.
EIP-8130’s 0x03 config-change entry contains its own auth blob. So once that extension is used, representation-level authorization material re-enters replay_id through account_changes. Two otherwise identical logical transactions can then acquire different replay identities solely because the embedded config-change authorization has a different valid encoding/signature.
I think the extension boundary needs a normative replay projection: each typed account_changes entry should define the fields that carry logical transaction identity, excluding evidence/authentication material that may vary without changing the authorized state transition. Otherwise the invariant used to exclude the outer auth blobs is not preserved across extensions.
@chugarchugarr on replay_id: for a 0x03 entry could the projection be the batch digest its auth already signs (account, channel, sequence, changes) instead of the raw entry? then a re-signed batch keeps the same replay_id. unsequenced batches can still repeat within an epoch though
@chunter-cb 8430 has its own nonce manager at 0x8130…aa01, and 8250 has another one for 8141 at 0x…8250. on a chain with both, key k is two separate lanes for the same account, and eth_getTransactionCount with nonceKey only reads the 8430 one. would it make sense to share one manager and one rpc read?
Yes. For 0x03, I think the projection should be the 8130 batch digest, not the raw entry.
That keeps replay_id stable when the same batch is re-signed, because auth proves the batch but is not part of the batch’s semantic identity. And you’re right about the unsequenced case: this does not make an unsequenced batch single-use. The same batch can still be carried by a distinct 8430 transaction and remains governed by 8130’s epoch rules.
So the boundary is clean: the projection answers “is this the same logical change?”; 8130’s channel/sequence/epoch rules answer “is this change authorized to apply now, and may it apply again?” I don’t think replay_id should add any stronger authority semantics than that.
1. Validity. We can treat an invalid config change as an invalid transaction (if the sequences is used or the epoch is incorrect). The tradeoff is that front-running becomes possible in public mempools, since anyone can relay the signed batch first and invalidate the pending transaction (a work around could be to sign it as self only submit?).
2. Replay identity. One other option is for each account-change type to specify what goes into replay_id. For example, config change (0x03) would leave out its auth data, so re-signing the same batch keeps the same replay_id.
3. Nonce managers Good call out Daniil. I’m open to sharing one as long as it gives us the same capability (and same timelines)
@chunter on 3, a single key is just the 1-key case of 8250’s manager: nonce_keys = [k] with the same seq, slot keccak256(sender || k), so an 8430 tx could read and bump that slot directly. two things to line up: #12352 makes the first byte of the key its type (0x00 general, 0x01 binary), so 8430 keys would follow that too. and if 8430 ships before 8141, would deploying the 8250 manager on its own together with 8430 work for you?