Fundamentals: Transactions

Sent $ETH? LP'ed into an AMM? Deployed a new contract? Everything you do on the World Computer leaves an on-chain record. Ever wonder what's inside your transactions?

A field-by-field guide to the atomic unit of Ethereum computing

(2/18) @ethereum is the World Computer: a globally shared utility that exists between a network of 1000s of computers

Users interact with Ethereum through a wallet (like @MetaMask), which creates and sends txns to the network. Once accepted, the txns are written into a block.

(3/18) Perquisite - hashing, (applying a hash function)

Hash function: a piece of code used to transform any amount of data into a compact, uniform value. The input can be of arbitrary length but the output is always the same length.

(Good) hash functions are non-reversible.Unroll available on Thread Reader

(4/18) An @ethereum transaction is made of up 3 parts:

- metadata, including to/from, $ETH amount, gas details and signature data
- cache, a list of accounts and keys the transaction expects to use
- data, the payload of the transaction (smart contract code or API call)

(5/18) Metadata - information about the transaction

The attached images show all the metadata fields. We will discuss the non-obvious ones in the tweets below.

(6/18) chainId - introduced by EIP-155 to protect against an $ETC replay attack

type - there are two types: a new contract (0x0) and all others (0x2). EIP-2718 introduced a wrapper (0x2) that allows for many more types without affecting the core @ethereum specs

(7/18) nonce - number of transactions sent from a given address. Once imprinted on a block, the wallet's nonce is increased. Protects against replay attacks

to - address (wallet or smart contract) the transaction is being sent to

(8/18) value - amount of $ETH being transferred. Note - this is ONLY for $ETH (no other token)

gas - units of gas used by the transaction

maxFeePerGas - maximum amount (WEI per gas) the user who created the transaction is willing to pay. Inclusive of base fee and priority fee

(9/18) maxPriorityFeePerGas - maximum amount (WEI per gas) above the base fee the user who created the transaction is willing to pay. This fee will be paid directly to the miner/validator as a tip to incentive inclusion.

gasPrice - cost per unit of gas paid by this transaction

(10/18) (r, s, v) - three values that form the signature of the user who created the transaction. They can be used to verify that the user authorized the transaction before it was executed in the EVM

For more information, see: Elliptic Curve Digital Signature Algorithm (ECDSA)

(11/18) Cache - contains the accessList, a list of addresses and keys the transaction anticipates using. The transaction will still be able to use resources off this list, but at a higher cost.

(12/18) The accessList was added by EIP-2929, allowing clients to fetch/cache data to be used during the transaction.

Today, the discount for using addresses & keys in the accessList is ~10%. However, this will increase in the future as @ethereum moves to support light clients.

(13/18) Data - the data payload being delivered by the transaction. This can be used in 3 ways:

- $ETH transfer - empty

- smart contract API call - name of function and parameters

- new smart contract - code of the smart contract

(14/18) Data in the input field is recorded in binary, but can be translated back to a human readable form.

(15/18) The input field exists on-chain, but is not part of the EVM state. It simply provides data for the contract to use during the transaction, it is not tracked by @ethereum nor used in consensus.

The EVM can only use data supplied in that transaction; it cannot look back.

(16/18) This property becomes useful for applications that want to write historical data to the @ethereum blockchain (eg for manual retrieval later) but don't care about having direct EVM access.

Rollups are the first category of applications to truly leverage this idea.

(17/18) We will cover rollups another time. For now, rollups rely on the fact that writing data into the input field is cheaper than writing directly into the @ethereum state.

This allows rollups to execute much more efficiently while still posting a record of all txns on-chain.

(18/18) And there you have it! That's an @ethereum transaction!

Like what you read? Help me spread the word by retweeting the thread (linked below).

Follow me for more explainers and as much alpha as I can possibly serve.

Unroll available on Thread Reader

Fundamentals: Transactions

Sent $ETH? LP'ed into an AMM? Deployed a new contract? Everything you do on the World Computer leaves an on-chain record. Ever wonder what's inside your transactions?

A field-by-field guide to the atomic unit of Ethereum computing

(2/18) @ethereum is the World Computer: a globally shared utility that exists between a network of 1000s of computers

Users interact with Ethereum through a wallet (like @MetaMask), which creates and sends txns to the network. Once accepted, the txns are written into a block.

(3/18) Perquisite - hashing, (applying a hash function)

Hash function: a piece of code used to transform any amount of data into a compact, uniform value. The input can be of arbitrary length but the output is always the same length.

(Good) hash functions are non-reversible.Unroll available on Thread Reader

(4/18) An @ethereum transaction is made of up 3 parts:

- metadata, including to/from, $ETH amount, gas details and signature data
- cache, a list of accounts and keys the transaction expects to use
- data, the payload of the transaction (smart contract code or API call)

(5/18) Metadata - information about the transaction

The attached images show all the metadata fields. We will discuss the non-obvious ones in the tweets below.

(6/18) chainId - introduced by EIP-155 to protect against an $ETC replay attack

type - there are two types: a new contract (0x0) and all others (0x2). EIP-2718 introduced a wrapper (0x2) that allows for many more types without affecting the core @ethereum specs

(7/18) nonce - number of transactions sent from a given address. Once imprinted on a block, the wallet's nonce is increased. Protects against replay attacks

to - address (wallet or smart contract) the transaction is being sent to

(8/18) value - amount of $ETH being transferred. Note - this is ONLY for $ETH (no other token)

gas - units of gas used by the transaction

maxFeePerGas - maximum amount (WEI per gas) the user who created the transaction is willing to pay. Inclusive of base fee and priority fee

(9/18) maxPriorityFeePerGas - maximum amount (WEI per gas) above the base fee the user who created the transaction is willing to pay. This fee will be paid directly to the miner/validator as a tip to incentive inclusion.

gasPrice - cost per unit of gas paid by this transaction

(10/18) (r, s, v) - three values that form the signature of the user who created the transaction. They can be used to verify that the user authorized the transaction before it was executed in the EVM

For more information, see: Elliptic Curve Digital Signature Algorithm (ECDSA)

(11/18) Cache - contains the accessList, a list of addresses and keys the transaction anticipates using. The transaction will still be able to use resources off this list, but at a higher cost.

(12/18) The accessList was added by EIP-2929, allowing clients to fetch/cache data to be used during the transaction.

Today, the discount for using addresses & keys in the accessList is ~10%. However, this will increase in the future as @ethereum moves to support light clients.

(13/18) Data - the data payload being delivered by the transaction. This can be used in 3 ways:

- $ETH transfer - empty

- smart contract API call - name of function and parameters

- new smart contract - code of the smart contract

(14/18) Data in the input field is recorded in binary, but can be translated back to a human readable form.

(15/18) The input field exists on-chain, but is not part of the EVM state. It simply provides data for the contract to use during the transaction, it is not tracked by @ethereum nor used in consensus.

The EVM can only use data supplied in that transaction; it cannot look back.

(16/18) This property becomes useful for applications that want to write historical data to the @ethereum blockchain (eg for manual retrieval later) but don't care about having direct EVM access.

Rollups are the first category of applications to truly leverage this idea.

(17/18) We will cover rollups another time. For now, rollups rely on the fact that writing data into the input field is cheaper than writing directly into the @ethereum state.

This allows rollups to execute much more efficiently while still posting a record of all txns on-chain.

(18/18) And there you have it! That's an @ethereum transaction!

Like what you read? Help me spread the word by retweeting the thread (linked below).

Follow me for more explainers and as much alpha as I can possibly serve.

Unroll available on Thread Reader