[EVM: Zero to Hero] Connecting you to the blockchain
Explaining what powers the worlds most valuable blockchains
Welcome to Article 5 of EVM: Zero to Hero. This series helps you learn about technical web3 concepts in a simple and fun way.
In case you missed it, here’s what we covered the last article on smart contracts:
The key properties of a smart contract
The anatomy of smart contracts
How people access smart contracts through dApps
Smart contracts are the programs that run on EVM compatible blockchains, and we’ve covered them extensively over the past few articles.
However, we’ve only briefly touched on transactions, which trigger state changes on the blockchain by interacting with smart contracts. In other words, if you want to take some action on the blockchain, you have to use a transaction!
To the blockchain, a transaction is simply a set of key:value pairs uniquely identified by a hash such as 0xdc37af3d991a817000c3d7abd0cf6085f7a6d1f4b0441c6373456e8046c4dd20. These hashes encode a ton of information, and we’re going to figure out how they work in this article. Let’s first understand how transactions fit in the EVM Blockchain Big PictureTM.
The Transaction Life Cycle
This image from the previous article is a high level illustration of what happens when a user interacts with a smart contract. It’s time to go one level deeper.
When a user decides to take action on-chain, they use their wallet to create a transaction and broadcast it to blockchain nodes
A blockchain node processes the transaction by verifying its validity. More on validity in the next sections
If the transaction is valid, the node adds the transaction to a new block. This block is broadcasted to the rest of the nodes. The rest of the nodes then decide for themselves if the block is valid (decentralized systems in action)!
Once consensus is achieved, the block (and therefore the transaction) is considered finalized
As a fun exercise, try to reconcile this process with how we described the inner workings of the EVM in the first article of this series.
Two Major Types of Transactions
There are two major types of transactions.
Native Transfers are the simplest type of EVM transaction. They move the native currency of the blockchain from one account to another. On the Ethereum blockchain, the native currency is $ETH, but each EVM compatible blockchain has its own native currency.
Contract Executions interact with smart contract functions. They include data about which function of the smart contract to call. This is the type of transaction you’re most familiar with if you’ve been reading this series.
There’s a third type of transaction called contract creation which enables developers to deploy new smart contracts on the blockchain. It's much less common than the two listed above, and not worth covering in depth.
The Anatomy
Great! Since we’ve covered how transactions fit within the big picture and their different types, we can start exploring what a transaction actually looks like.
A transaction has a list of fields that dictate what action it will take on the blockchain. We’ll cover each of these fields in detail below.
Recipient
The recipient field represents the target account address of the transaction.
For an Native Transfer, the recipient can either be an EOA or a Smart Contract. Remember, it’s possible for smart contracts to hold cryptocurrency too!
For Contract Executions, the recipient must be a Smart Contract address.
Data
The data field is for contract executions. More specifically, the data field is an encoded representation of which smart contract function to call and the values of the function’s parameters. Since Native Transfers don’t use a smart contract, the data field is null.
For example, take this example smart contract function from the last article:
function newGame(address playerX, address playerO) public
If someone wanted to create a new game, the function call would look like newGame(“0x28AcC19A2154C51c43c0819d50a875c7c90c94B8”, “0x30783E1d34B45AE73A57Db9d27EE5bE8246C3177”)
.
This function call is then encoded into a blockchain-friendly format and set as the value of the data field.
Value
The value field defines how much of the native currency is transferred from the sender to the recipient address. This works for both simple Native Transfers and Contract Executions, but is required for Native Transfers.
In the case of contract executions, it’s possible for a smart contract to require payment. For example, our TicTacToe game could require 1 ETH to create a new game.
Nonce
A nonce is a unique transaction identifier, set by your account. Nodes automatically reject any transaction with the same nonce as one that’s already been sent by your account.
The nonce field is a way to prevent replay attacks. A replay attack happens when a malicious entity submits your transaction multiple times to the blockchain, which can result in you spending more money than you originally intended.
Gas-related fields
The concept of gas is an entirely different topic that we’ll cover in the next article. At a high level, you can think of gas as a transaction fee that covers the cost of taking actions on the blockchain.
🚀 Pop Quiz 🚀
Here are two transactions that recently occurred on the Ethereum Blockchain: one and two.
Comment below which type of transactions these are (and why!) for a chance to win $20 in ETH.
Rapid Fire Q&A
Transactions are complex! Here are a few commonly asked questions.
Who can initiate transactions?
EOAs are the only account types that can initiate transactions. From a previous article:
The EVM only supports transactions that have been signed with a private key. Since smart contracts don’t have private keys, they can’t create transactions! Therefore, only EOAs can create transactions that in turn call smart contracts.
How do blockchain nodes verify the transaction sender is who they say they are?
Transactions must be signed with an EOA’s private key. This way, blockchain nodes can easily verify that the signature of the transaction matches the transaction’s contents. For more info, check out our previous explanation on cryptography here.
What happens if a contract execution fails halfway?
Transactions are “all or nothing.” In technical speak, they’re atomic:
An atomic transaction is an indivisible and irreducible series of operations such that either all occurs, or nothing occurs.
If a smart contract function fails halfway, the entire transaction is considered invalid. Smart contract functions can fail for a variety of reasons, from the sender not paying enough transaction fees to simply a bug in the smart contract code.
Recap
Enjoyed this article? The next in this series is article is out now!
Wowza! That was a lot of information. You now know the technical concept behind how users interact with the blockchain!
In today’s article, we covered:
The transaction life cycle in the EVM
The different types of transactions
The variety of fields that make up a transaction
We hope you learned something new today. As always, feel free to reach out on Twitter or email me at shekar@ramaswamy.org with any questions or comments.
Next up, we’ll be wrapping up this EVM series with the infamous concept of gas. In the meantime, please let us know what content you want to see from Coinsights in the future!