Composing Contracts without Special Provisions — using Blockchain History

One feature I sorely miss in most existing blockchains is the ability to query 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 they don’t want to be involved, or you don’t want to involve them). It is even possible to compose contracts in a private way where no one needs to 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. And 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 contracts you signed even have provisions that prevent you from relinquishing control of your cryptoscalies even temporarily to a contract we might write to implement the arrangement. How can we still implement this sponsorship contract?

With access to the history, we can write a contract to the tune of “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 consensually establishing whether or not you did do this part of our deal, in case there is a dispute about it.

As long as we both agree on the outcome, we can cheaply 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 your and my conflicting claims?

All you have to do is prove to the consensus that you posted the T-shirt donning event on time, 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 don 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 donning the T-shirt. Now, 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. 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; but if I

cannot provide such a counter-argument within my deadline, then the judge will adjudicate in your favor.

Using the 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, this kind of contracts can be kept private: the terms can be hidden from the public by only publishing a salted hash of those 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 (e.g. presence of brown M&Ms in the requested bowl), or whichever clause will maximize the damages they will be awarded, if the damages may vary.

To go one step further towards privacy, even the arguments themselves can be obscured using recursive zkSNARKs: all that bystanders would see would then 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 blockchain consensus, will be able to check which of you or I won this trial fairly and was adjudicated the escrowed funds. Actually, even the outcome of the trial can itself be kept private, using the same techniques as ZCash or MimbleWimble. All the public will then see is that some dispute happened, that was resolved according to objective justice, though no one but us will know either the topic of the dispute or the 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 they don’t need to remember the entire history to update these hashes, just the spine of the trie.

Now, the applications of this technology are not limited just to dressing cute lizards in T-shirts…

At Alacris.io , we are using contracts in the above style to build atomic swaps between arbitrary financial products, elaborate financial contracts, scaling solutions based on side-chains, and more. And we look forward to Blockchains that will enable us to write these contracts in ways easier not harder than what Ethereum currently allows.