Composing Contracts without Special Provisions — using Blockchain History
One feature I sorely miss in most existing blockchains is the ability to verify the history of the blockchain from within its contract language. Why so? Because this feature when present enables easy composition of contracts, without the contracts being composed having to offer a dedicated API to facilitate such composition, such as the awkward “allowances” of ERC20 contracts.
Indeed, thanks to access to blockchain history, it is possible to compose not just contracts that weren’t designed to be composed, but even contracts involving other parties who are not directly involved in the larger composition — whether you don’t want to involve them, or they refuse to make your life easy. It is even possible to compose contracts in a private way where no one needs know the details of the composed contract except its direct participants.
Let’s assume that someone wrote some cool contract to manage interesting assets, say cute lizards that scale, Cryptoscalies, and someone else wrote another cool contract so your Cryptoscalies can wear T-shirts. Now let’s assume I want to sign a sponsorship contract with you, whereby I will pay you so that your famous lizard Scaly Cardassian shall wear a “Vote for Borg” T-shirt for the next month. One issue, though: neither the Cryptoscalies contract, nor the T-shirt contract, have any provision that can facilitate any such arrangement. Some other obligations may even prevent you from relinquishing control of your Cryptoscalies, even temporarily, to a contract we might otherwise have written to implement the arrangement. How can we implement this sponsorship contract still?
With access to the history, we can write a contract with the following terms: “if an event is posted before the start of the month whereby your lizard dons the T-shirt, and no event is posted thereafter and until the end of the month, that causes the T-shirt to be removed or covered — then I shall pay you the convened sponsorship reward, which until then is escrowed in this composition contract.” I can imagine other conditions in a sponsorship contract, but let’s focus on how we would resolve any potential dispute on whether or not you did fulfill this part of our deal.
As long as we both agree on the outcome, we can simply sign a common settlement that assigns the escrowed funds to the deserving party. But what if we disagree? What if I somehow refuse to pay you though you did your part? Or, what if you demand payment even though you didn’t? How will the matter be resolved? How can a fair judge, automatically implemented by a “smart contract” on the blockchain consensus, adjudicate between our conflicting claims? Is there a way to resolve the issue without having to trust, pay and wait for a third party who’d act as arbiter?
All you have to do is prove to the consensus that you posted the T-shirt donning event before the beginning of the month, and didn’t post any contrary event until after the end of the month. Let’s assume that the blockchain gives access from each block to the entire event history as a Merkle trie, and gives direct access to a few hours worth of previous blocks from its contract scripting language. Then, to prove that your lizard did wear the T-shirt, you can tell the judge to look at a given recent block, and exhibit as evidence a Merkle proof that some transaction was posted that indeed represents the lizard wearing the T-shirt — with this evidence, you have a case, without it, you are thrown out of court. Now, proving that you did do something is easy, but you cannot so easily convince the judge that you did not post a contrary transaction whereby the lizard removes the T-shirt: for that, the judge would have to look back at each and every transaction between the donning of the T-shirt and the expiration date of the contract — and that definitely will not scale. What you can do, though, is challenge me to show any such transaction, if it exists as I claim it does. If I can show that indeed your lizard removed the T-shirt, by similarly exhibiting a recent block and a Merkle proof of inclusion from it, then you failed your contract and the judge will adjudicate in my favor. However, if I cannot provide such a counter-argument within my deadline, then the judge will adjudicate in your favor.
Using a field of mathematics known as Game Semantics, any formula quantified over the history of the blockchain can be transformed into such a “verification game,” and thereby be used in a contract. This enables the composition of arbitrary activities that were not otherwise designed to be composed.
Furthermore, these kinds of contracts can be kept private: the terms can be hidden from the public by only publishing a salted hash of these terms when initially signing the contract and escrowing collateral funds on the blockchain. Only in case of a dispute will the terms of the contracts have to be revealed. Actually, only one single clause of the contract has to be revealed, even though the contract can be very large and contain many clauses. The claimants can choose the simplest clause to argue, for instance the presence of brown M&Ms in a contractually required bowl. Or they can pick whichever clause will maximize the damages they will be awarded, if the damages may vary with the clause.
To go one step further towards privacy, even the arguments themselves can be obscured using recursive zkSNARKs: all that bystanders would then see would be you and I sending O(1) proofs that remain impossible to decode by anyone not privy to our agreement. Yet all these bystanders, as well as the “judge” made of the “smart contract” and the blockchain consensus, will be able to check which one of us won this trial fairly and was adjudicated the escrowed funds. Actually, even the outcome of the trial can itself be kept private, using techniques pioneered by ZCash or MimbleWimble. All the public will then see is that some dispute happened, which was resolved according to objective justice, though no one but the parties involved will know either the topic of the dispute, or its conclusion.
And to achieve this composition of contracts, all we need from a blockchain is the ability to verify historical events — and of course, for suitable events to be emitted that we can reason about. To this end, we need the blockchain’s contract scripting language to give us access to recent block hash and we need each hash to commit to a trie of all past events. Interestingly, Ethereum only does the former. We can still achieve the latter, but to that end, some contract must maintain this trie and be called regularly to update it, and that’s a major hassle. If instead block miners maintained the trie, their cost at each block would only be logarithmic in the depth of the trie — just a few tens of hashes to carry — because nodes don’t need to remember the entire history to update these hashes, just the spine of the trie. As for remembering history, users will each be responsible for remembering the fragments of it that they care about.
Of course, the applications of this technology are not limited just to dressing cute lizards in T-shirts. They can be used to compose arbitrary contracts and create elaborate decentralized applications.
At Alacris.io, we are using the above technique among many others to build an operating system for decentralized applications. The applications we will enable will include atomic swaps between arbitrary financial products, elaborate financial contracts, scaling solutions based on side-chains, and much more. And we are hoping to convince blockchain implementers to actively support this history verification feature that will let us to compose decentralized applications in ways easier not harder than what Ethereum currently allows.