The first question is about smart contracts. “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?” 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.