Skip to content

Latest commit

 

History

History
58 lines (39 loc) · 2.9 KB

REP-0007.md

File metadata and controls

58 lines (39 loc) · 2.9 KB
Raw

REP-0007: Implement EIP-2718 (Typed Transaction Envelope)

Preamble

REP-0007
Title: Implement EIP-2718 (Typed Transaction Envelope)
Author: Ronin Core Team
Type: Standard Track
Status: Executed
Created: 2023-11-02

Abstract

TransactionType || TransactionPayload is a valid transaction and TransactionType || ReceiptPayload is a valid transaction receipt where TransactionType identifies the format of the transaction and *Payload is the transaction/receipt contents, which are defined in future REPs.

This REP essentially enables Ethereum's EIP-2718.

Rationale

By introducing an envelope transaction type, we can add new transaction types without worrying about backward compatibility with existing transactions. We just need to make sure that there is no numbering conflict between TransactionTypes.

Specification

The specification is the same as in EIP-2718.

Transactions

The transaction root in the block header MUST be the root hash of patriciaTrie(rlp(Index) => Transaction) where:

  • Index is the index in the block of this transaction
  • Transaction is either TransactionType || TransactionPayload or LegacyTransaction
  • TransactionType is a positive unsigned 8-bit number between 0 and 0x7f that represents the type of the transaction
  • TransactionPayload is an opaque byte array whose interpretation is dependent on the TransactionType and defined in future REPs
  • LegacyTransaction is rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])

All signatures for future transaction types SHOULD include the TransactionType as the first byte of the signed data. This makes it so we do not have to worry about signatures for one transaction type being used as signatures for a different transaction type.

Receipts

The receipt root in the block header MUST be the root hash of patriciaTrie(rlp(Index) => Receipt) where:

  • Index is the index in the block of the transaction this receipt is for
  • Receipt is either TransactionType || ReceiptPayload or LegacyReceipt
  • TransactionType is a positive unsigned 8-bit number between 0 and 0x7f that represents the type of the transaction
  • ReceiptPayload is an opaque byte array whose interpretation is dependent on the TransactionType and defined in future REPs
  • LegacyReceipt is rlp([status, cumulativeGasUsed, logsBloom, logs])

The TransactionType of the receipt MUST match the TransactionType of the transaction with a matching Index.

Security analysis

It is STRONGLY recommended to include the transaction type as the first byte of the signed payload. If you fail to do this, it is possible that your transaction may be signature compatible with transactions of another type which can introduce security vulnerabilities for users.

Reference

License

The content is licensed under CC0.