What actually happens in a smart contract? How to they execute on the Ethereum blockchain.

Published: 2019-01-12


Q: How are smart contract operations conducted without having middlemen? Who does them? Can you please give us some real- world examples? Which application is best for it?

A: When a smart contract is executed, it is a software program validated by every single participant in the smart contract platform. Let's take Ethereum as an example, just because I know Ethereum a bit better than some of the other platforms. But the same kind of logic applies to all of them. Every smart contract execution starts with a transaction. Someone will make a transaction which has a contract as the recipient. They will tell that contract to do something. Basically, it is the input to a program.

Smart contracts are just software, after all. What happens then? Who runs the smart contracts? The simple answer is: everyone runs the smart contract. Every node participating in the Ethereum network. Everyone running a business should be running an Ethereum node themselves. The Ethereum nodes, the clients on computers that are running as part of the Ethereum network, will receive that transaction. In order to validate that transaction, they execute the smart contract... and pass that transaction as an input to the smart contract, inside what is known as a virtual machine. A virtual machine is basically a simulated computer.

In Ethereum, it is the Ethereum Virtual Machine (EVM). The EVM takes the transaction as the input to the smart contract code recorded on the blockchain, and runs it as a software program with that input. If all goes well, that transaction should validate successfully... and produce some change in the state of the system. A variable is updated. Maybe a payment is sent, some money is deposited, or it changes ownership. Part of the memory or data store of the contract itself is updated with new values. These state changes are then recorded on the blockchain.

Imagine thousands of these nodes all running the same software, though there might be some slight differences in time. These are run on their own local machine, using the transaction from the same blockchain as the input. Given all of that, they should arrive at the same conclusion. They should all run the program identically and produce the exact same results. Those results, state transitions, are recorded on the blockchain. In a smart contract platform we record transactions, as well as the results of transactions, on the blockchain. The results include events and changes to the state of the blockchain. Everybody can validate they computed the same results as every other node. When they downloads a new block from the Ethereum network, they validate that block... by running all of the transactions through the smart contracts and checking if they agree with the results... that the miner has included in there. If they don't agree on the results, then they will consider that block invalid and reject it.

Therefore, just like in other blockchains such as Bitcoin, every node validates. Everybody participating as a node on the network validates every transaction. In the case of Ethereum, validating transactions in most cases means running the smart contracts... and hopefully arriving at the same results as everybody else. There are no middlemen running this. This is done in a decentralized way. All of that relates to the execution of a smart contract that uses information from within the blockchain. When it is running in the EVM, it has a very limited set of information it can act on. That is because all the information must be part of the consensus rules. It must be the same for every node trying to run that contract, so they all validate it the same way.

Smart contracts are very limited in how much information they can access. They can't access information about the real world. They can't say what the temperature is in Pensacola, or what the price of ether is, because that information is not validated on the Ethereum blockchain. As a result, there are some external services which will try to supplement smart contracts. These are called oracles.

This leads us straight into the next question. "How can we make sure that oracles feeding information to a smart contract are not corrupt?" That is great question. In fact, that is the biggest challenge with oracles. You have this compromised situation, whereby smart contracts can only act -- independently and within the consensus rules -- on information that is already stored in a transaction... they received from the Ethereum blockchain. They can't validate the truth of any other miscellaneous data in the transaction. They can't validate what is happening in the real world. For that, we would use external services called oracles.

But the problem is, if you trust that oracle, then it could have enormous power. For example, let's say that you had an insurance contract with a clause that says, 'If it rains more than 30 inches in this particular region, that will trigger a claim on the insurance over property.' To cover rain damage. That smart contract must constantly check how many inches of rain have fallen in a specific area. You can use an oracle for that, publishing the cumulative amount of rain for the past twenty-four hours. If it exceeds a certain threshold, then you could trigger an insurance payout.

Here's the problem: you have centralized a lot of control and power into this oracle. Where is this oracle running? Outside of the Ethereum network, to collect rain data. Part of it is running inside the Ethereum network as a smart contract, but the information about... how much rain fell in the last twenty-four hours is coming from outside the network's consensus rules. That source must be trusted. There may be a couple of ways to get around this problem of trusting the oracle, as much as possible. You could use an oracle that collects information from thousands of sources, instead of asking one source, and they must all agree.

Effectively, you are running a separate set of consensus rules, perhaps on an external blockchain... a sidechain or another blockchain, that is used to arrive at a common truth about something in the real world. If a thousand people had rain sensors in Pensacola, Florida, and all report within a range of 28-30 inches, then you can probably say that information collection is more decentralized and we can trust it. Why does this matter? It matters because smart contracts execute automatically, in a way that can't be reversed. Imagine having an insurance contract that will pay you if it executes with a particular input. If you hack the oracle and make it report an exaggerated amount of rain, you will trigger the contract to pay... all of these claims and effectively defraud the insurance company. Smart contracts only operate on whatever information they have or are given. If you put garbage in, you get garbage out.

That is a challenge for interacting with the real world: how do you know that information is correct? How much trust are you putting into a single provider? If you centralized trust, that could create an enormous incentive for people to compromise that system. They could receive whatever amount is in the payout, up to billions of dollars. No one will put that much money in such a contract anytime soon. No one will write a contract that automatically pays billions of dollars based on information from an oracle. This is where the rubber of the real world of smart contracts hits the road, if you like. These challenges mean that we are very far away from many of the alternative uses of blockchains... that people discuss today. You can't simply put that much dependence on a fully automated system, especially if it has a centralized point of trust.


Filed Under: Ethereum