Ethereum Yellow Paper Mathematics Deciphered | Part 2: Transaction

This part of the series ventures into section 4 of the Yellow Paper, to describe transactions.

Be sure to check out Part 0, if you haven't yet to get conventions right.

Transaction

As said in previous part, transactions are what that drive the ethereum state machine from one state to another. Consider a transaction, , as tuple containing multiple fields for the paper. It is equivalently represented as a cryptographically signed instruction - which is basically encoding all of its fields together and signing it with a private key.

These are cryptographically signed instructions are signed by the sender which can only be an EOA, not a contract. This may seem confusing to Solidity developers. Since a contract can also call other contract & be a sender (msg.sender) in context of the called contract - right? Well, yes but the originator of the transaction (tx.origin) i.e. the entity which initialized the the transaction in the first place is always an EOA. A transaction can either result in a message call to some existing contract or creation of a new contract.

Types

As of London version of the protocol there are 3 transaction types (see EIP2718 and EIP2930):

0 (legacy): The legacy transactions, before the introduction of the new transaction types.
1 (EIP2930): These transactions specify additional fields in the transaction tuple (see below).
2 (EIP-1559):

Transaction Anatomy

Common Fields

All transactions regardless of type/action have a number of common fields:

(): EIP-2718 transaction type.
(): Nonce of sender i.e. no. of transactions sent by sender
(): Gas price of this transaction i.e wei per unit of gas paid for this transaction
(): Max amount of gas this transaction can use. Paid up-front by sender
(): Address of receiver. If null (), it is a contract creation transaction.
(): Amount of wei to be sent to receiver or in case of contract creation, a value to newly created contract.
, (): Values that correspond to signature of the transaction and used to verify, cryptographically, the sender of the transaction.

Type-1 & Type-2 Tx

A type-1 and type-2 transactions (i.e. or ) has some additional fields:

(): List of access entries to warm-up. Each list item is a tuple . Tuple has two items - and account address and a list of storage keys, i.e. .

Notice the subscript in is bold lowercase - meaning it's a sequence not some scalar value according to convention. You an specify these access lists using ethers, for example, while interacting with a contract.

(): Chain id. Must be equal to network chain id, .
(): Y-parity of the transaction. Used to compute the value of the signature. See this.

Type-2 Tx

The gas price in transaction type-2 () is specified differently than type-1 and type-0. By EIP-1559, these transactions explicitly limit the priority fee that is paid for the transaction. This is done by two fields in type-2 tx:

(): Scaler value representing max amount of wei to be paid per unit of gas for execution of transaction.
(): Scaler value representing max amount of wei paid to miner (block's fee recipient) as incentive to include the transaction in block.

Type-1 & Type-0 Tx

In contrast to max fee amounts per gas in type-2 transactions, type-0 and type-1 transactions simply specify gas price as single value:

(): Scaler value representing amount of wei per unit gas to be paid to miner for all computation costs for execution of this transaction.

Type-0 (Legacy) Tx

The legacy () do not have (i.e. ). However, and are combined into a single value :

(): A scalar value that encodes () and, if present, the (). So,

See EIP-155.

Contract Creation Tx

If the transaction is a contract creation transaction, it also contains:

(): The byte array specifying initialization process of contract. You might know it as the creation bytecode fragment of the contract bytecode.

Keep in mind that in contract creation transactions is set to null i.e.

fragment of the bytecode returns the , aka runtime bytecode, fragment of the bytecode to EVM, after which part is discarded and is what lives on chain & executed in response to calls. The is always concatenated with the in a contract creation transaction to be sent.

Message Call Tx

Now, if transaction is a message call transaction instead of contract creation, it has:

(): A byte array that is input data to the called contract.

Let me disambiguate something for folks who've used ethereum libraries like ethers or web3.js. While creating a custom transaction object using these, and ( + ) is generally specified at same key - data. Library interprets the data as or ( + ) depending on to key in transaction object. If to is null it's ( + ), i.e. contract creation, otherwise , a message call.

The paper defines the transaction collapse function, as:

where,

The basically covers all possible values of a value received by concatenating the components of tuple and components depend on what transaction type is and if it's a contract creation transaction or message call.

Remember from Part 0: Conventions that function serializes the transaction tuple through RLP encoding into a sequence of bytes.

There are only certain possible values each constituent of can take which is laid out in the paper as:

where is a set of all natural numbers less that . Same as,

The case with is a bit difference because (as you might've guessed) depends on whether transaction is contract creation or message call. In case of former () it is simply RLP empty byte sequence, otherwise normal 20-byte public address:

The Withdrawal

The Withdrawal refers to tuple containing information for withdrawal of staked Ether of consensus layer validators. has following fields:

(): Incrementing unique identifier/index for this withdrawal.
(): Validator index the withdrawal corresponds to.
(): The recipient address that will get withdrawn Ether.
(): Amount in wei to be denominated.

is serialized using function:

All constituents of assume values:

And this concludes this part! Next up is the section about Block stay tuned!