 First question is about smart contracts. Ali asks, how are operations conducted without having middlemen? Who does them? Can you give us some real-world examples? Which application is best for it? When a smart contract is executed, it is a software program. Every single participant in the smart contracts platform... let's take, for example, Ethereum, just because I know Ethereum a bit better than some of the other... smart contract platforms, but the same kind of logic applies to all of them. Every single smart contract execution starts with a transaction. Someone makes a transaction, and that transaction has a contract as its recipient and tells 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. Everyone who is participating in the Ethereum network, running an Ethereum node, running a business, the nodes themselves, the Ethereum nodes, the clients, the 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 they pass as input to the smart contract that transaction inside what is known as a virtual machine. A virtual machine is basically a simulated computer. In Ethereum, that is the Ethereum virtual machine, or EVM. That simulated computer takes the transaction that was the input to the smart contract, it takes the contract code that is recorded on the blockchain, and it runs that as a software program with that input. Now, if all goes well, that transaction should run successfully and produce some change in the state of the system. Meaning that a variable is updated, maybe a payment is sent, maybe some money is deposited, maybe something changes ownership, maybe 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. Now, if you imagine thousands of computers all running the same software, they are not running it at the same time, there might be some slight differences in time, they are each running it locally on their own machine, and they are each using as input the same transaction, the same blockchain. Now, given all of that, they should all arrive at the same conclusion, they should all run the program identically, and produce the exact same results. Those results are what is recorded on the blockchain, those state transitions. So, on the blockchain in a smart contract platform, we record the transaction, as well as all of the results of the transaction, which may include events and changes to the state of the blockchain. Everybody can validate that they got the same result as everybody else, and when they download a new confirmed block from the Ethereum network, they can validate that block by running all of the transactions and smart contracts, and seeing if they agree with the results that the miner has included in there. If they don't agree, then they will consider that block invalid and reject it. Therefore, just like in other blockchains, like in Bitcoin, everybody validates. Everybody who is participating as a node on the network validates every transaction. In the case of Ethereum, to validate a transaction, that may mean, in most cases, means running the smart contracts and arriving at the same results as anybody else. There are no middlemen that are running this. This is done in a decentralized way. Now, all of that refers 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 of that information has to be part of the consensus rules. It has to be the same for everybody who is trying to run that contract, so that they can all validate it the same. That means the smart contracts are very limited in how much information they can access. Meaning that they can't access information about the real world. They can't say, what is the temperature today in Pensacola? That is not on the Ethereum blockchain. They can't say, what is the price of Ether today? As a result, there are external services that sometimes supplement smart contracts. These are called oracles, which leads us straight into the next question by DDA. How can we make sure that an oracle feeding information to a smart contract is not corrupt? That is a great question, DDA. In fact, that is the biggest challenge with the technology of oracles. You have this compromise situation whereby smart contracts can only act authoritatively and within the consensus rules on the information that is already stored in the Ethereum blockchain, and the transaction they just received. They can't validate the truth of anything that is in the transaction. They can't validate what is happening in the real world. For that, we sometimes use external services called oracles. The problem with that is, if you trust that oracle, it has enormous power. For example, an insurance company has a clause that says, if it rains more than 30 inches in this particular region, that will trigger a claim on an insurance over a property to cover rain damage. That smart contract has to constantly check how many inches of rain have fallen in a specific area. You can use an oracle for that. You can use an oracle that publishes every minute or hour the cumulative amount of rain for the past 24 hours, and if it exceeds a certain threshold, then you could trigger an insurance payout. Here is the problem. Now you have centralized a lot of the control and power into this oracle. Where is this oracle running? In most cases, it is running outside of the Ethereum network, or if part of it is running inside as a smart contract, certainly the information about how much rain fell in the last 24 hours is coming from outside. That source has to be trusted. There are a couple of ways to get around this problem. One of the ways is to use a certain type of oracle, where instead of asking one source for the data, like how much it rained in a specific area, you have a decentralized mechanism whereby the oracle collects information from thousands of sources, and they must all agree. Effectively, you are running consensus rules on an external blockchain, a side-chain, or another blockchain that is used in order to arrive at a common truth. At that point, if everybody out of 1,000 people who are running rain sensors in Pensacola, Florida, and they all report within the range of 28 to 30 inches of rain, then you can say, okay, that information is more decentralized than we can trust it. Why does this matter? Part of the reason it matters is because smart contracts execute automatically. When they execute automatically, they also execute in a way that cannot be reversed. Imagine a situation whereby you have an insurance contract and it is going to pay out. If you hack the oracle and make it report the wrong amount of rain, exaggerating the amount of rain, and you trigger the insurance company to pay out all of these claims, then you can effectively defraud the insurance company. Therefore, smart contracts only operate on whatever information they have. If you put garbage in, you get garbage out. One of the challenges with interacting with the real world is how do you know that information is correct, and how much trust are you putting into a single provider? If you centralize trust, then that creates an enormous incentive for people to compromise that system, because they could receive billions of dollars presumably in insurance payouts. Arguably, no one is going to do that anytime soon. No one is going to write a smart contract that will automatically pay out billions in the case of an event coming from an oracle. This is where the real world of smart contracts, where the rubber hits the road, if you like, because it is exactly these challenges that mean that we are very far away from many of the alternative uses of the blockchain that people discuss today, simply because you can't put that much dependence on a fully automated system, especially if it has a centralized part of trust.