The Ethereum Virtual Machine: A Technical Introduction for the Non-Technical
State, Events and Nodes explained with analogies
Imagine that you’re at a convenience store purchasing a bar of chocolate.
Before you go into the store, your friend asks you these questions:
- How much do you have right now?
- How many bars of chocolate do you have?
You tell your friend you have $10 in your wallet and 0 bars of chocolate.
Now, you go into the store and pick up a bar of chocolate that costs $3 and do the following actions:
- You hand the cashier a $5 bill
- The cashier gives you back a $2 bill and a bar of chocolate.
Now, your friend asks you the same questions. But you’re getting rather annoyed at his questions so let’s imagine that you had a magical smart contract, something like a chatbot, that could answer your friend’s questions on your behalf. Let’s call this contract, Person.
In order for your friend to ‘talk’ to the Personsmart contract, they need to query a node. Think of a node as a computer that is connected to many other computers. Together, this network of nodes forms the blockchain network. So if your friend would like to answer the same questions, they would talk to the Person contract by querying the node using these functions :
checkWalletBalance() → returns $7checkChocolateBalance() → returns 1
What this actually does is to ask the node for the current state of the walletBalanceand chocolateBalancevariables stored in the contract.
# States that are stored in the Person contract
uint walletBalance
uint chocolateBalanceSometime later, your friend wants to ask these questions instead:
- How much did you have before you entered the store?
- How many bars of chocolate did you have before you entered the store?
Unfortunately, because you are a really efficient person, you don’t bother remembering things in the past that are no longer relevant. You don’t have poor memory, you just live in the present. This is an optimisation that both you and Persondo. In this case, the walletBalanceand chocolateBalancestates are updated and the old state is forgotten. Your friend can’t get his answer through querying the same type of node, which only stores the present state of the blockchain. The node they were previously using is called a full node.
Enter, the concept of an archive node. It’s not that your magical contract can now remember the past, it’s that this special type of node that your contract interacts with can remember all the past states of your contract. Think of an archive node as a special type of computer that stores all the historical states of every contract on the blockchain.
So great! Your friend can now query the archive node and ask it for the states before you entered the store using the same functions:
checkWalletBalance(before entering store) → returns $10checkChocolateBalance(before entering store) -> returns 0
Now, let’s do a mini-test. Do you think your magical person contract could remember the price of the chocolate? How about the amount of change you got back from the cashier? Does your friend need to query an archive or full node to answer these questions?
In theory, they could use an archive node for that.
checkWalletBalance(before entering store) → returns $10checkWalletBalance(after leaving store) → returns $7- Take the difference as the price of the chocolate — $3
As for the change you got, they would ask you if you remember how much you gave to the cashier. Unfortunately, neither you nor your magical contract can remember it. It wasn’t a defined state to be stored in the contract and who remembers the breakdown of the bills in their wallet?
At this point, your friend has an idea to go back to the store and ask the cashier. This would be like querying another Cashiersmart contract. But all this sounds like a lot of work doesn’t it? And what if you purchased multiple items in one transaction, how would you know the breakdown of the items you purchased in order to derive the price of the items bought and the resulting change?
Luckily for us, whenever you purchase something from a store you get a receipt. What if you got a receipt back which tells you how much you paid, how much change you got back, and the number of chocolates purchased? Thankfully, the blockchain has something similar to receipts. They’re called events.
# Defining the structure of the receipt
event Receipt(uint amountPaid, uint changeReceived, uint numOfChocolates)# Prints out a receipt whenever a purchase is made
function purchase() {
...
emit Receipt(amountPaid, changeReceived, numOfChocolates)
Events were invented as a way to log historical events on the blockchain without having to store all the data in the contract which would greatly increase its computation requirements.
Perfect! So now your friend can easily get the answers to their questions as long as they have the receipt. But it’s not always that simple. Some receipts don’t tell you how much you paid and how much change you gave, some don’t tell you the breakdown of purchases and some stores don’t even give receipts! Unfortunately, because there is no way to enforce a standard on the blockchain, this situation happens in smart contracts as well. Emitted events don’t always give you all the data you need and some contracts may not even emit events at all. I leave it to you to explore these edge-cases on your own.
When I first got interested in blockchain, I could either only find textbook-like definitions, or overly technical explanations. This made it difficult to wrap my head around the concepts and to develop the intuition for what is and isn’t possible to derive with the given resources. I hope that this made it much simpler to understand and that you had an enjoyable read.
Other easy resources for learning about blockchain:
