In the last post I outlined what it took to create a document that was both human readable and machine readable, good enough for a legal contract, and also good enough to support an accounting model like cryptocurrency. Now that we have that contract that both the computer and the human can read, and agree upon, it remains to communicate it.
Most prose contracts are written, emailed, argued about & redlined & mangled, eventually to be signed and then confined to the bottom of a drawer. To be forgotten, which is perhaps an odd way to treat something so central to the nature of business and agreement.
Not so a digital contract! As we have injected into the contract the key parameters that make this contract special, we can now actually use the contract in a transactional way: to communicate what a payment, trade or other transaction is.
To do this we have to use a hashing trick from cryptography. We take the hash (“cryptographic message digest”) of the above document and embed it in all the transactions that refer to that contract. This means that the transactions ‘know’ about the contract in some sense.
For example, if the transaction were a payment from Alice to Bob of say dollars, then the contract would describe the dollars. To see how this works, consider this payment where Alice pays Bob:
{Alice, Bob, 100, dollars}
This record might maybe describe a transaction in some contexts, but it isn’t really good enough in a complicated, global world - I might send you Hong Kong dollars, and you might be expecting Singapore dollars. Oops! Also, that number that’s in the record - is that 100 referring to 100 dollars or 1.00 dollars being 100 cents or a 100 satoshi-dollars which might be about 0.000001 dollars each?
The computer can’t really tell, and if the computer, as your digital angel, can’t know then you can’t know. Oh, yes, databases and all that but they are just honeytraps for insider frauds and viruses and other horrors. If databases could do payments for everyone, blockchain wouldn’t have been invented.
Let’s now see how we do this in a Ricardian fashion. I pay you:
{Alice, Bob, 10000, ABC1234IANG66DOLLAR911911HASH}
is actually less intelligible than the above. Which is an advantage because now your client software has to fix its and your information misery.
What happens is this. Your client software, your digital angel, has to take that horrible hash thing ABC1234IANG66DOLLAR911911HASH and go look up a document that matches the hash.
Because it’s a hash, there is only one document, and that document self-proves itself as being the document of the hash - take that, you insider scummers! And, assuming that the document is a contract as described in the last post, then we have some simple parameters that can be extracted out of it. With these parameters being easily recoverable using our above markup and parameter techniques, your digital angel can now tell you:
Bob, you’ve been paid $100.00 in IangBux by Alice. We know this currency and we liked it before. This takes your balance to $120.00 and your savings plan is on track!
All the context of the contract is now at the hands of the client software, instantly and without confusion.
This becomes much clearer in any large scale world. An ISDA Swaps contract can run to 300 pages long, and can fill drawers and consume hours of time - digitisation allows those drawers to be emptied, but also gives us instant and permanent access to everything in the contract of repetitive value! Permanency is a big win too - if you know anyone who is older than 70, ask them what the contract of their favourite currency was - chances are they will talk wistfully about the gold window and how the bank promised to pay the bearer 1 pound of sterling silver and other such other stories. Unfortunately for the Bank of England and the Federal Reserve, they didn’t have cryptography available to them in those days, and couldn’t lock their contracts down with hashes. Inevitably, without such discipline, the contract slipped away, and we’re left with legend.
What is the contract today for the US dollar? If it was in Ricardian form, you would know, precisely. As it is not, the “contract” is little more than a marketing slogan that is changed as and when the Federal Reserve needs another brand makeover.
Brands are useful, and the state can get away with just the one brand. But in the open contractual space of blockchain, we need contractual certainty for digital issuances, not least because there are so many issuances - ERC-20s! ICOs! and those are the polite terms - that these days it is hard to tell what any of them mean. And by using the approach mentioned earlier we gain some much-appreciated precision: prose for legals, parameters for variability, and hashes to lock the precision into an accounting system.
(Soft note - this concept of {prose, params and code} is further explored in Sum of all Chains but it's too much for one post.)
If the contract were a constitution for a chain, this would bring the benefit that the blockchain’s code could extract the parameters directly. A chain could follow its inflation rate, simply by reading what the users had agreed in the constitution. Then the code would follow suit by looking up the constitution and extracting out the number directly - no more hard coding, no more duplication, no more cumbersome alignment of code with prose.
The hash of the Constitution could also appear in key instructions and would therefore signify - by custom - that the initiator of that transaction is agreeing to the constitution. For example, if the CREATE-NEW-ACCOUNT instruction included the hash, this enters that account to the Constitution, which in turn defines the Community: all who have accounts are all under the same Constitution and are all in the Community.
In sum, using the Ricardian form brings specific advantages to a community blockchain:
