1.10 Transactions: Properties & Components

Transactions are signed messages that originate outside of the Ethereum blockchain. They are triggered by EOAs (that are managed or controlled by a private key). The trigger happens to be the digital signature, derived from the private key.

These transactions are transmitted by the Ethereum network and they trigger state changes on the blockchain. In fact, Ethereum is fundamentally a transaction based state machine, as only transactions are capable of triggering state changes.

Properties

1. Transactions are atomic: they run from the beginning to the end completely, it's either all or nothing.\

   So the side effects of the transactions are only reflected in the blockchain if they run to completion. If they don't, nothing that they do is reflected on the blockchain and it's as if the transaction never happened.\

   In other words: transactions cannot be divided or interrupted with some of the partial state being reflected on the blockchain and the rest of it not.\

   This contrasts withtraditional computing environments where a particular process or a particular control might be interrupted, gets context washed out and then something else (a different process or a thread) executes and then the original context is brought back. None of that happens within the context of Ethereum.

2. Transactions are serial: they're executed one after the other, sequentially without any overlapping. There is no parallelism when it comes to the execution of transactions.

3. Transaction inclusion. When a user submits a transaction, what is the warranty that it gets included within one of the blocks on the Ethereum blockchain?\

   This property is controlled by entities on the Ethereum blockchain known as miners. They run Ethereum nodes and decide which transactions are included within a block. This depends on multiple factors, the key ones being the congestion on the Ethereum network (or in other words, the other transactions that are competing for the same block space) and the Gas price that the user decides to use for the particular transaction.

4. Inclusion order. It refers to the specific order of the transactions included within a block.\

   Again, this chosen by the miners and, similarly to inclusion, is determined by factors of congestion and Gas price. The key takeaway of properties 3 and 4 is that there are entities known as miners on the blockchain who get to decide which transactions get included within a certain block and the specific order of the transactions within that block.

Components

Transactions contain seven components:

1. nonce: the name is an abbreviation for "a number used only once". It's a sequence number that, as part of the protocol, is incremented in a particular fashion (it changes for every transaction).\

   The application of the nonce is prevention of replay attacks (i.e. replaying the same transaction over and over again). In the case of an EOA, the nonce value is equal to the number of transactions sent from that account. In the case of a contract, it is equal to the number of other contracts created by this contract account.

2. gasPrice: the price for every Gas unit that the sender is willing to pay for a particular transaction. It's measured in wei/gas.\

   gasPrice is not fixed by the Ethereum protocol. The higher the Gas price that the the sender is willing to pay for this transaction, the faster the particular transaction gets included by the miner into a block in the blockchain. This price depends on the demand for the block space at the point in time when the transaction is submitted.\

   The reason for this is that there is a limited amount of space in the block, so there's only a limited number of transactions (as determined by the Gas used by each one of them) that can be included within this block.

3. gasLimit: the maximum number of Gas units that the sender is willing to pay for a particular transaction. This depends on the type of transaction that is being sent.\

   If it is a simple Ether transfer then it costs 21000 Gas units. But if it is a transaction that is targeting a particular contract (or a particular function of the contract) then the required amount of gas is higher. If sufficient Gas (in the form of Gas limit) is not set for the transaction (if it's less than what is required to), then it results in what is known as an out of Gas exception (OOG Error) and that transaction fails.\

   The way it works is that for any transaction that is being sent by a sender, there is an estimated Gas that needs to be sent as part of the transaction. If that estimated amount of Gas is not sent then it leads to the exception. If there is excess gas, then the remaining Gas is sent back to the sender.

4. recipient: the destination 20 byte Ethereum address for a transaction (i.e. the destination account that this transaction is targeting).\

   This could be an EOA address or a contract address, it depends on the target of that particular transaction. It could be any address on the Ethereum blockchain, and the protocol itself does not validate these recipient addresses in the transactions. So one can send a transaction to any address and that address might not even have a corresponding private key, nor the contract that the sender expects to have.\

   Thus, all such validation should be done at the user interface level. That validation is critical for security reasons (more on that in later chapters). Note that this recipient is really the target address. There is no "from address" that is a component of the transaction. The reason for this is that the "from address" can be derived from the ECDSA signature components $v$, $r$ and $s$: they can be used to derive the public key, which in turn can be used to derive said address.

5. value: the amount of Ether (in wei) that the sender is sending to the recipient address.\

   What happens with such funds depends on the recipient: if it happens to be in EOA, then the balance of that account will be increased by this value and the sender's balance correspondingly decreases. If it hapens to be a contract account, then what happens depends on any other data present as part of this transaction (i.e. the contract function being invoken with the transaction data).\

   If there is no data being sent as part of this transaction, and the destination happens to be a contract account, then the contracts' receive or fallback functions (if they were defined or if they are present; more on that in the upcoming chapters) are triggered and thus, what happens with the received Ether depends on their implementation.\

   If there is no fallback function, then the transaction results in an exception and the Ether, that is sent as part of the transaction, remains with the sender account.

6. data: payload of variable length and binary encoded (as per the format required by Ethereum) that is sent as part of this transaction.\

   This field is relevant when the recipient is a contract account. As mentioned previously, the data in that case contains the contract function that is being targeted by the transaction plus the specific arguments that are relevant for said function.

7. v, r & s: The ECDSA signature is 65 bytes in length and has three subcomponents: v, r and s.

   • r and s represent the signature components. They are 32 bytes in length each (adding up to 64 bytes).

   • The final subcomponent, v, is the recovery identifier. It's just one byte and its value can be either 27 or 28, or it can be twice the value of chain ID ($2\times\text{ID}_\text{chain}$) plus either 35 or 36. The chain ID is the identifier of the blockchain. In the case of the Ethereum mainnet chain, $\text{ID}=1$.

For a particular transaction, the Ether used to purchase Gas is credited to the beneficiary address that was specified in the block header (more details on this are found in the upcoming sections). Then there's also a concept of a Gas refund: the difference between the Gas limit and the Gas Used is refunded back to the sender of the transaction. This is done at the same Gas price as indicated in that transaction.