译文/Translated：
上一篇文章中，我重点提出了创造人机可共同阅读文件所需要的条件，该文件满足法律合约的要求，且能完美支撑加密货币类的记账模型。而现在，我们拥有这类合约，人机都可读取并能基于此达成一致，但它仍有待商讨。
大多数论述合约都是文字写入，通过邮件沟通，双方就内容进行争论，用红线标注，并被撕毁重来，最终签字后便成了压箱底的存在，不再被多看一眼。遗忘，以这种方式对待对商业及协约类而言如此核心的东西或许并不太正常。
而数字合约却不会如此！由于我们在合约中输入了关键参数，让这份合约具有特定性，我们如今便能在交易中实际使用该合约：用以沟通支付、贸易和进行其他交易。
为此，我们需使用密码学中的散列技巧。我们取以上文件的哈希(Hash)（“加密信息摘要”），并将之嵌入所有涉及该合约的交易中。这意味着交易在某种程度上“了解”该合约。
例如，Alice有一笔美元支付给Bob，然后该合约将对这笔钱进行描绘。来看看这怎么运作，考虑到这笔钱是由Alice支付给Bob：
丨{Alice，Bob，100，美元}
该项记录或许会以文字形式描述这笔交易，但在复杂的全球市场中，这还不够——我向你支付港币，但你或许希望以新币支付。噢！同样，记录中的数字100指的是100美元或1.00美元（100美分）或100 Satoshi元，每个或约价值0.000001美元？
计算机无法真的告诉你答案，若作为数字天使的计算机都无法知晓，那么您也无从得知。哦，对，数据库和所有这些，它们只是内幕欺诈、病毒和其他恐怖的甜蜜陷阱。如果数据库能帮每个人完成支付，区块链根本就不会诞生。
现在我们来看看我们如何以Ricardian的方式完成这些。我向你支付：
丨{Alice, Bob, 10000, ABC1234IANG66DOLLAR911911HASH}
事实上比以上更难理解。这是一个优势，因为现在您的客户端软件必须对其本身以及您的信息匮乏进行修补。
事情会这样进行：您的客户端软件，您的数据天使必须拿着这一串哈希（Hash）ABC1234IANG66DOLLAR911911HASH，去寻找与之匹配的文件。
因为它是一个哈希，因此只有一个文件，并且该文件自证自己便是哈希的那份文件。假设该文件就是前文提到的合约，那么我们可以从它身上提取一些简单的参数。使用我们的上述标记和参数技术可以轻松恢复这些参数。现在您的数字天使可以告诉您：
Bob，Alice在langBux向您支付100.00美元。我们知道该货币，我们之前挺喜欢它。这让您的账户余额变为120.00美元，您的储蓄计划正按计划进行！
该合约的所有文字现在都在客户端的软件上，及时且不会导致任何困惑！
为何合约需要数字化
在大规模背景下，这会更加清晰易懂。ISDA Swaps合约可以执行300页之长，可以填满抽屉并耗费数小时的时间，而数字化则能清空这些抽屉，但同时让我们能及时且永久地访问重复值合同中的所有内容！永久性也是一个巨大的收获- 如果你认识一个年龄超过70岁的人，问问他们最喜欢的货币合约是什么- 他们有可能会对黄金窗口充满渴望，以及银行承诺向持票人支付1斯特林银和其他此类故事。可惜，英格兰银行和美联储当时没有可用的密码学，也无法用哈希来锁定他们的合约。没有这些，合约不可避免会悄然生变，而我们也只剩下这些故事可以听听。
今天，美元的合约是什么？若它采用Ricardian形式，您或许能清楚知道这一点。但事实并非如此，“合约”只不过是一个营销口号，当美联储需要另一个品牌改造时，这个口号会发生变化。
品牌很有用，仅一个品牌，国家便能摆脱困境。但在区块链开放的合约空间中，我们需要数字发行的合约确定性，特别是有太多发行的出现——ERC-20！ICO！还有那些礼节性的发行- 现在很难说明它们的含义。通过使用早前提到的方法，我们增加了一些颇受赞赏的精确性：法律论述、可变性的参数，以及用以锁定会计系统精确度的哈希。
（请注意：{论述、参数和代码}的概念在Sum of all Chains中有进一步探讨，但内容过多，难以一篇详尽。）
Ricardian章程
如果合约是一条链的章程，这将带来区块链代码可以直接提取参数的好处。只需阅读用户在结构中达成的协议，链就可以跟随其通货膨胀率变动。然后代码将查阅该章程，并直接提取数字，以此随其变动，没有更多的硬编码，没有更多的重复，没有更多繁琐的与论述一致的代码。
章程的哈希也可以出现在关键指令中，因此（通过惯例）表明该交易的发起人同意该章程。例如，哈希中加入创建新账户的指令，这便将账户输入到章程中，而后又反之定义了社区：所有拥有账户的人都归属于同一章程，并都在同一社区。
总的来说，使用Ricardian形式为社区区块链带来了特定的好处：
- 哈希机制意味着我们所谈及的文件必然是确定的，这便消除了大量的困惑：
- 在选择自身章程时，社区对章程的哈希进行投票，该哈希指向精确的文件
- 区块链中的交易锁进哈希，因此它们必然是正确且有用的文件
- 合约的论述意味着我们能使用所有法律的精细惯例，来表达我们欲达成的协议，并在需要时对其进行解释，这便去除了诸多的不确定性，并让商业更加清晰。
- 请注意，这并不会更改文件的创建方式，您可以雇佣律师草拟合约，或者您可以自行起草。
- 推荐直白简单的写作，但它已经完成了！
- 参数意味着我们不仅能够为读者标出重点，我们也能与计算机进行类似沟通。
- 姓名、初始数量及通胀现在都是我们合约中的参数，这让合约能轻易为其标注，供人类读者阅读，并将其放入程序，供计算机“读者”解读。
- 显示参数允许程序处理所有形式的符号和小数。
- 现在，替代链可以相对容易地构建不同的业务主张。这些参数标志着他们在启动链时必须改变的内容。
- 仅有一个文件是真实来源
- 不再有独立参数文件，无更多失调
- 不再需要硬编码！
原文/Original：
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.
Why the contract needs to be digitised
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.)
The Ricardian Constitution
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:
1.The hash mechanism means it is impossible to be uncertain about which document we are talking about, which removes large areas of confusion:
- In selecting its constitution, the community votes over a hash of that constitution, which points to the precise document
- The transactions on the blockchain lock into a hash, so they are bound to the correct and useful document
2.The prose of the contract means that we can use all the fine tradition of law to express our desired agreement, and to explain and interpret it when needed – which removes a lot of uncertainties and makes our business that much clearer.
- Note that this doesn’t change the way the document is created – you can use lawyers to draft your contract, or you can write it yourself.
- Plain writing is preferred however it is done!.
3.The parameters mean we can not only demarcate key points for the reader, we can communicate them to the computer too.
- The name, initial quantity & inflation are now parameters within our contract, which makes it easy to colour them for effect for the human reader, and feed them into the program for the computer ‘reader’.
- The display parameters allow the program to handle symbols and decimals of all forms.
- It is now relatively easy for alternative chains to build a different business proposition. The parameters signpost what they have to change when starting up their chain.
5.There’s only one document which is the source of truth
- No more separate parameter files, no more discoordination
- No more hard coding!
原文链接/Original URL:
