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.