docs(tip-0001): add tempo transaction spec#3808
Conversation
legion2002
requested review from
0xKitsune,
dankrad and
danrobinson
as code owners
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bfd2b21e9a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| nonce, | ||
| valid_before, | ||
| valid_after, | ||
| 0x80, // fee_token encoded as EMPTY (skipped) | ||
| 0x00 // placeholder byte for fee_payer_signature |
There was a problem hiding this comment.
The sender hash example omits post-valid_after fields except fee-token/signature placeholders, but the real signing path (TempoTransaction::encode_for_signing -> rlp_encode_fields) also signs aa_authorization_list and optional key_authorization (crates/primitives/src/transaction/tempo_transaction.rs, around lines 739-749 and 477-483). Wallets or SDKs implementing this example will compute a different hash for transactions using those features, causing otherwise valid user signatures to be rejected.
Useful? React with 👍 / 👎.
| valid_before, | ||
| valid_after, | ||
| fee_token, // fee_token ALWAYS included | ||
| sender_address, // 20-byte sender address | ||
| key_authorization, |
There was a problem hiding this comment.
The fee-payer hash pseudocode jumps from sender_address to key_authorization and never includes aa_authorization_list, but the implementation hashes the authorization list as part of the same field encoder (rlp_encode_fields in crates/primitives/src/transaction/tempo_transaction.rs, lines 477-483). Any sponsor service following this snippet will produce invalid fee-payer signatures whenever aa_authorization_list is non-empty.
Useful? React with 👍 / 👎.
| key_id, | ||
| expiry?, // Optional trailing field (omitted or 0x80 if None) | ||
| limits?, // Optional trailing field (omitted or 0x80 if None) | ||
| signature // PrimitiveSignature bytes |
There was a problem hiding this comment.
This RLP layout lists signature immediately after limits?, but the current KeyAuthorization format includes allowed_calls? before the signature (see KeyAuthorization docs and encoding in crates/primitives/src/transaction/key_authorization.rs). Implementers that manually encode this structure from the TIP will produce mismatched key-authorization digests/signatures once call scopes are used.
Useful? React with 👍 / 👎.
|
This PR has been marked stale due to 7 days of inactivity. |
|
|
||
| **Assessment:** While this transaction type introduces additional pre-execution validation costs, all costs are bounded to reasonable limits. The mempool complexity issues around cross-transaction dependencies already exist in Ethereum due to EIP-7702 and accounts with code, so the incremental cost from this transaction type is acceptable given these existing constraints. | ||
|
|
||
| ## T2 -> T3 Migration |
There was a problem hiding this comment.
unsure if we still need this section since we're at T4 now
There was a problem hiding this comment.
yup, can update in the docs too
2 participants
Adds TIP-0001 by copying the existing Tempo Transactions spec into the repo as a retroactive TIP.
Tempo Transactions shipped at genesis and are already live on mainnet, so this PR makes the existing spec discoverable alongside the rest of the TIP set. It also points readers to the related follow-on transaction TIPs: TIP-1007, TIP-1009, TIP-1011, and TIP-1020.