Transaction lifecycle on the Ethereum blockchain
Following the publication of my book, Building Ethereum Dapps, often friends and colleagues ask me to give them a quick explanation of how an Ethereum Dapp works. I have found the best way is to walk them through the lifecycle of a typical Dapp transaction, so they can also understand some details of the Ethereum network and blockchain.
Imagine you are casting a vote through a decentralized voting application built on Ethereum. Figure 1 summarizes what happens from the moment you click the Vote button to the moment you receive a confirmation the vote has been stored on the blockchain and it is ready to be counted.
Let’s go step by step through the diagram. If you do not get everything immediately, don’t worry: I am going to explain you various concepts in detail after walking you through the transaction lifecycle.
1. You browse on the voting application, which looks like a conventional HTML page, select your candidate and click Vote.
3. The voting transaction is validated by the “local” Ethereum node it has been submitted to. The validation involves checking various things: that the digital signature is consistent with the sender address and the transaction content; that the sender has enough ether to fund the full processing of the transaction; that the data submitted will not cause the castVote() function to fail. If the validation is successful, the current node broadcasts the transaction to all its peer nodes (which are the nodes it is connected to). In case of unsuccessful validation, the transaction is not broadcast further, and it simply dies away.
4. When validated successfully, the transaction flows through various “full nodes”, which repeat the validation process described in the previous step. A “full node” is a server (or even a desktop computer or a laptop) which runs one of the many existing Ethereum clients, such as Go Ethereum (also known as geth) or Parity, which talk seamlessly to each other through a common protocol called Wire. The transaction eventually reaches various “mining nodes”. A mining node is a special node, which does not simply validate incoming transactions, but actively processes them with the hope of getting a reward.
5. The mining node validates the transaction, as any full node would do, but then it also actively executes the logic associated with the Vote function, it changes the state of the Voting smart contract and it tries to persist the transaction list, together with a hash of the associated state changes, on a new block of the Ethereum blockchain. I say it “tries” to persist because after creating a new block listing all the validated incoming transactions, the mining node must also successfully execute the consensus algorithm. This is the algorithm under which each node of the network accepts a block as valid. Currently this is a cryptographic puzzle known as Proof of Work (PoW), which uses as an input the block just created. If the mining node finds the solution to this puzzle, it is entitled to append the new block to the blockchain and claim a reward for the work performed: it will get a certain amount of ether, the Ethereum cryptocurrency.
6. Once a mining node appends successfully a new block to the blockchain, it broadcasts it to its peer nodes. Each receiving node will validate the block. It will process the transactions included in the block and then it will check whether the root hash of the local transaction Patricia-Merkle trie and the root hash of the local Dapp state Patricia-Merkle trie match the corresponding transaction root hash and state tree root hash reported on the block. If this sounds unclear, don’t worry, I am going to explain what the Patricia-Merkle trie is in more detail shortly. The receiving node will also verify whether the hash of the previous block reported on the current block is correct. If the validation is successful, the node will broadcast the block to its peers and so forth.
7. Eventually, the block reaches the node the transaction was initially submitted to. When the voting transaction is executed during block validation, the smart contract will publish VoteConfirmation event. This will be received by the web UI of the voter, which is registered to listen to such event.
Are you still with me? I know, I know! During this walk-through you might have come across terms you have never heard before, such as cryptographic hash, blockchain, mining, consensus, Proof of Work (PoW), Merkle tree, Merkle-Patricia trie and you might want to learn more. I will clarify these concepts in my next article, Introduction to the Ethereum blockchain.
I hope you enjoyed this step-by-step walk through an Ethereum transaction. If you would like to learn more, please check out my book: Building Ethereum Dapps.
Building Ethereum ĐApps: Transaction life-cycle on the Ethereum blockchain | Manning
Manning's focus is on computing titles at professional levels. We care about the quality of our books. We work with our…
I am planning to write more on Ethereum and programming on Medium — Please ‘Follow’ me!