Can the Bitcoin blockchain eliminate the need for Trusted Computing in Smart Contracts?

Question

Let me preface this by saying that I'm a novice, but this is my rough understanding of how Bitcoin's blockchain works. (This is largely based on blog posts like this one.) If person A wants to transfer a certain amount of Bitcoin to person B, he signs a message authorizing the transfer using his private key. A minor can examine the message, and using a program that performs a certain mathematical operation, can verify that person A really did sign the message. But there's the issue of, how do we know that the miner really did do the computational work needed to verify the signature? This is solved by something called a "proof-of-work" protocol, by which the miner can demonstrate that he did the verification computation.

I was reminded of all this when hearing about the notion of "external state contracts", a type of Smart Contract described briefly at the 35 minute mark of this video and in more detail in this Bitcoin wiki article. In an external state contract, certain disputes about objective features of the world can be resolved automatically, instead of trusting a third-party human arbitrator to decide fairly. For instance, contract could specify that in the event of a dispute about a sports bet, a computer program (with source code specified in the contract) would be automatically run that consults a sports database, determines who won the bet, and the bitcoin is automatically transferred accordingly. But the Bitcoin wiki article describes an issue with this: how do you determine that the computer program that's supposed to resolve the dispute has actually been run, and if so whether the output of the program is being reported fairly by the computer that ran it? The article suggests using one or more "Trusted Computers" known as oracles, which both parties trust to run the code properly and not misrepresent the output.

But it occurs to me that the issue with external state contracts is analogous to the issue I described above that's solved with the blockchain. So why can't you solve it the same way in this case? That is to say, just as proof-of-work protocols can be used to demonstrate that a miner ran the code that determines whether a signature is authentic, why can't you make miners run dispute-resolution code for external state contracts, and then determine whether they really ran the code using proof-of-work protocols? That would eliminate the need for a Trusted Computer.

Is there any significant difference between the two cases that would make this unworkable? Has this been done already?

Any help would be greatly appreciated.

Thank You in Advance.

Answer 1

...how do you determine that the computer program that's supposed to resolve the dispute has actually been run, and if so whether the output of the program is being reported fairly by the computer that ran it? ...

But it occurs to me that the issue with external state contracts is analogous to the issue I described above that's solved with the blockchain. So why can't you solve it the same way in this case?

If I understand you correctly, the question you're asking is: Why can't you extend the blockchain trust/coordination system to handle the problem of resolving disputes about the validity of a computation's output (or validity of an observation, like "who won this game?"). After all, if the blockchain gets everyone to agree on a transaction record, why not on arbitrary claims about the world?

The answer, in short, is that the blockchain restricts the "claims" that it "proves" to ones that, by construction, it can provide (strong) evidence for. And those claims rely on special cryptographic properties that don't (as far as we know) generalize to arbitrary claims about the world.

More concretely, what the blockchain is claiming (and getting network coordination on) is something like, "These transactions happened in this order." And it proves it by saying, "Transaction T30 must have been seen by someone who had already seen transactions T29, T28 ..., and spent 9000 units of work (say, computations of SHA-256) on it." Which in turn is proven by how SHA-256 has a known computation difficulty, and the proof-of-work for Transaction T30 was generated uniquely from the previous transactions.

That's a very different problem than proving that a certain (family of) computation(s) has a certain result. For that problem (as Nate Eldredge mentions), you will want to use Zero-Knowledge Proofs, an active area of research. But those a) only apply to "pure functions", not arbitrary questions about the Real World, and b) require a certain asymmetry between computation and verification -- i.e., it must be a lot easier to verify them than to do the computation, or else you've saved nothing: just do the computation yourself instead of trusting others' reports!

And it's ever further off from the problem of "proving" real-world observations. So yeah, the best we have cryptographically is to designate an address as trusted on certain matters, and then check the validity of their signatures.

In terms of verifying real-world claims, the best we have is to check all the implications of that claim, which is just old-fashioned fact-checking. For the ballgame example, that would be checking things like "What do the newspapers report about the game? What do the league records say? Who played next in the tournament?" Which is fine in practice -- like resolving things at the bookie. But it doesn't provide a cryptographic proof, which would have to be robust against attackers e.g. falsifying news reports and such.

Okay, I've rambled enough now. Did I answer your question?

Answer 2

I'm afraid your first paragraph is not accurate.

The proof-of-work that a miner presents doesn't certify "I have verified the signatures." Verifying a signature is a cheap computational task, and every client on the network can (and does) verify for itself that every signature in the block chain is valid. They don't have to rely on a miner to verify the signatures for them. Indeed, if all we needed to do was verify that every transaction was properly authorized, we wouldn't need miners at all.

Mining solves a different problem, called the "double spend problem": there could be two different transactions, both properly authorized, that are in conflict because they attempt to spend the same coins. The community needs to be able to reach a consensus as to which of the two should be accepted. The choice can be made arbitrarily, but then in order to keep the community committed to that choice, the protocol requires proof of work to certify that this transaction is accepted. If the community (or someone within it) later wanted to go back and change its mind about which transaction to accept, they would have to redo all the work that had been done in the meantime, which is intended to be prohibitively expensive. The computational work that's done is useless in and of itself; the proof of work certifies nothing except that some work was done.

What you are describing later sounds to me more like a zero-knowledge proof.

Answer 3

The problem with using blockchain to verify external world transactions is that the protocol requires that everyone is able to verify that any given block is valid.

So, at any given time, any miner can get back to the block #2, and verify that all the transactions were valid in that block. That is obviously only possible when the transactions don't reference an external input. Because if txs reference external input, the input might've been changed in the meantime, and you can't do that any more.

Why is it important to check the validity of the blocks? Because that's what blockchain is - the longest series of blocks since the first one. Your bitcoin client, when it wants to figure out which blockchain is the proper one, downloads all the blockchains that people claim are "the one", then weeds out the ones containing improper blocks, and then chooses the one that is the longest.

That's why there are no blockchain-based currencies that support external inputs and people use oracles for that. That's why Ethereum has all cool contract mechanisms but those contracts can't reference external outputs :)

You might find some of the answers in Orisi.org/distributed oracles whitepaper.