译文/Translated：
这是在几方面进行的思想实验，实验的对象能够把区块链宪法，如EOS提案，变成一个完整的李嘉图合约。其实这没有听上去那么难，而且可以带来一些令人惊讶的好处。
先简单介绍一下李嘉图合约，这个合约以散文形式完成，换言之，这是一个包含着计算机参数标记的法律合约。按重要性来看，它首先是一个可以被人类读取的文件，然后才是能够被机器读取的文本。
人类之所以被摆在第一位是因为他们（我们？）才是麻烦的部分。合同之所以是合同是因为它们必须有意图，这就意味着人类不仅要知道它，还要理解它，这样它才能成为一个法律协议被任何一个（人工）法庭视为法律合同。明确这个意图非常重要，所以人们会用一个个人和法庭都认可的仪式来表明这个过程——签名。
要把人类这些事情数字化是非常困难的事情，但是要让电脑理解一份文件却非常容易—只要在其中插入一些标记—就够了。在你阅读这篇文章的时候，牢记这个顺序：人类第一、计算机第二。
第一部分—李嘉图结构
我们来试一试吧！我们拿一段散文形式的宪法，然后往里面加入标记。比如说，我从《宪法版本示例》中拿出一个条款，这个条款是否适用于EOS我们先不考虑。
条款3-货币
社区在此创立了名为EXAMPLE的货币，拥有此项货币即被视为对社区有贡献的成员。最初十亿个EXAMPLE被分发出去之后，持有的EXAMPLE数量每年增幅不得超过5%。
这个条款的作者（@dantheman）希望别人都能使用这个例子，甚至他暗示可以把EXAMPLE换成我的币、你的币、Bob的币或者某人的币。这确实有点麻烦，但是也确实非常必要让这句话能适用于不同的语境——这里，我们就讲到了全文的要点：我们希望能够保持一个适当的合约的准确性，但我们还希望电脑能够利用上述模板完成一些编辑和呈现的功能，替我们生成终版让我们能够在区块链的不同语境下使用。
更重要的是，我们希望能够让人类（和电脑）能够轻易地解释结果。
合约这块大饼
要做出这块合约大饼来吃，我们还要给变量加一些标记和参数，我们已经看到币的名称就是这样的参数，我们可以给币加入初始发行量值，首次发行之后的增发率，这些很大程度上都取决于合约发布时的背景：
Article 3 – Currency
COINNAME = IangBux
INFLATION = 5%
INITIALISSUE = 1,000,000,000
社区在此创立了名为COINNAME的货币，拥有此项货币即被视为对社区有贡献的成员。最初INNITIALISSUE个COINNAME被分发出去之后，持有的COINNAME数量每年增幅不得超过INFLATION。
使用图形合约编辑器的话，我们就可以处理上一节这种枯燥的文本，让它变成上面这种散文形式的合约。
高亮部分显示的是被替换的部分，你可以让鼠标在这里停一下感受一番。或者，我们还可以通过颜色和高亮来追踪变量，程序设计师在IDE（集成开发环境）就是这样做的。
这就有趣多了！
但现在，有必要意识到另外一件事。我们也不想要太多的趣味性。我们这么做的原因是有些人搞了太多图形、技巧、工具包、FLASH、弹出窗口、特惠包、和其它各种没用的东西，结果反而导致这个系统的主要使用者—用户—寸步难行。正如爱因斯坦说的，这个系统要越简单越好，但也要把握好度。
要让合约成功，就声明变量！
上面的讨论中，我们已经把参数从散文格式中分离出来了。有趣的是，不管是对法律写作还是对于编程这都是双赢的结果。对于法律行业来说，这是所谓的合约模板，这个合约模板能够在多个合约方中修改使用，这就极大地节约了法律费用。你可以在Common Accord中找到更多相关模板。
对于你们程序员来说，事先声明变量迫使程序设计师清楚和明确地说明任务目的是什么，让编译器帮你们遵循该目的，比如，编译器可以通过确认所有的参数都被正确地分配出去了实现这单。对于这两方面来说，这都让该产品能够被其他专业人员阅读，减少维护的难度和成本。
更加高级的标记
然而，上面说的这个实施起来存在一点难度——如果我们实际上只是想写一些缩写，比如COINNAME或者ARTICLE这样的话，那怎么办呢？当我们想用加粗（或者大写）的形式提醒增发—因为你懂的央行和律师的原因—那又会发生什么呢！？
因此，我们一般会建议在散文格式中加入一个简单的标记。这里给一个例子说明如何运用一个类似JSON的格式设定参数，运用hybrid来赋值。
Article 3 – Currency
{
“COINNAME”: “IangBux”,
“INFLATION”: “5%”,
“INITIALISSUE”: “1,000,000,000”
“SYMBOL”: “$”
“DECIMALS”: “2”
}
社区在此创立了名为{COINNAME}的货币，拥有此项货币即被视为对社区有贡献的成员。最初{INNITIALISSUE}个{COINNAME}被分发出去之后，持有的{COINNAME}数量每年增幅不得超过{INFLATION}。
这是原始文本，但下面还需要写一些东西。现在，你需要的解析器也就非常简单了。
1. 扫描并提取所有的JSON部分，设置内部变量。换言之，每一个花括号标志着一个JSON区块，每一个单独的打开和关闭都是正常的。
2. 剩下来的是保留待替换参数的散文格式，这里就需要检查成对出现的花括号，花括号在这里是安全因为散文形式的法律条约不会用到它们（我这么希望！）所以它们可以用在简单的解析上。
3. 任意添加颜色或者简单的格式强调这在发生的简单的智能活动。
这很简单，但不会像前面那个那样过分简单，JSON在参数方面很好，但是可读性就不好；散文格式设置参数是灾难，但是可读性却很好。
越简单越好，但把握好度
把散文格式和参数混合在hybrid格式中，这样就能产生简单、计算机可识别、人类好阅读的合约，这样这些合约就可以在不同的情况下调整使用。我们最初的目标并没有因此改变——相比最初的散文格式，合约对人类来说的可读性并没有变差；如果还剩下一些读不懂的地方，那很可能是原来的文本就有问题，但是律师应该要帮我们用平淡的语言写出合约（拜托了！）
当然，我们想用几种格式都可以。以前我用过INI格式。你可以用LaTex或者XML，只不过本文我不会跟你讲这些麻烦的东西而已！这里我只是希望你能记住，a)这么做的目的首先、最重要、并且必须保持的是，文本必须能够让人类读懂，尤其是对于编程和技术不是那么了解的人来说更是如此 b）越简单越好，但把握好度;-)
在清晰了怎么做的基本思路之后，下一篇文章会关于为什么我们必须坚定地把文档和数字交易捆绑在一起，然后我才会继续讨论区块链宪法。
最后：延伸阅读，李嘉图合约的原始论文。Clack et al的论文Smart Contract Templates: foundations, design landscape and research directions提供了现在的思路。我看到的最新的关于条款编辑器的文章是在Common Accord。关于智能合约和区块链合约的客观评价在The Sum of all Chains，还可以参考这个视频，但这些就是比较漫长的探索了。
原文/Original：
Intro
This is a thought experiment in several parts in what it would take to turn a blockchain Constitution like the EOS proposal into a full Ricardian Contract. Which isn’t as difficult as it sounds, and could lead to some surprising benefits.
For the quick intro, a Ricardian contract is a prose or legal contract that includes computer-parsable markup. In that order: it is first and foremost a human-readable document, and only secondly is it a machine readable document.
The humans come first because they (we?) are the hard cases. For a contract to be a contract, there must be intent, which means the humans not only have to know about it, they have to understand it, so as to be able to legally enter into agreement in a manner that will be accepted by any (human-staffed) court as a legal contract. Establishing that exact intent is so important that we often turn it into a ceremony that is as well known to people as it is to courts – signing.
All this human stuff turns out to be a very hard problem to do digitally, whereas making a computer understand a document is easy – just shove some markup in there. Remember that ordering – humans first, computers second – as you’re reading through this odd construction.
Part 1 – A Ricardian Layout
Let’s try it then! Let’s take a prose constitution, and shove some markup in it. By way of an example, here is a clause from an example version of a Constitution that might or might not be useful for EOS:
ARTICLE 3 – Currency
The Community hereby creates a currency known as EXAMPLE, possession of which is evidence of a contribution to the community. The quantity of EXAMPLE shall increase no more than 5% per year after the first 1 billion EXAMPLE are distributed.
Note how the author of this clause (@dantheman) expects others to use this example, even to the extent of a hint to change EXAMPLE into MyCoin or YourCoin or BobCoin or somesuch. It’s a bit laborious but necessary to make this clause adaptable for different contexts – and this is where we get to the nub of the argument: we want to keep the precision of a proper contract, but we’d like the computer to do some of the editing & presentation work of taking the above template and turning it into a finalised contract for us, when we use it in the specific context of the blockchain.
And we want to enable the humans (and the computer) to easily interpret the results, as well.
Contract Cake
In order to get our contract cake and eat it too, let’s add some markup and some parameters to those parts to that may be different from context to context. We already saw that the name of the coin is one such parameter, to which we can add the initial total issue amount, and the rate of inflation rate after the initial issue is done; all of these depend heavily on the context in which the contract is being issued:
Article 3 – Currency
COINNAME = IangBux
INFLATION = 5%
INITIALISSUE = 1,000,000,000The Community hereby creates a currency known as COINNAME, possession of which is evidence of a contribution to the community. The quantity of COINNAME shall increase no more than INFLATION per year after the first INITIALISSUE of COINNAME are distributed.
With a graphical contracts editor, we can process the above dry document to display the prose contract derived from the above.
You can imagine a hover-over on those colour-highlighted parts that reveal the original name that has been substituted. Or, we could have a mode to track the variables by colours and highlighting, as within a programmer’s IDE (integrated development environment):
Hours of fun!
Now, it’s important to realise something here. We don’t want too much fun. The reason for this is that those that have too much fun with graphics and tricks and toolkits and FLASH and popups and special offers and other abominations make it harder and harder for those who are the primary users of this system – the users. As Einstein put it, this system needs to be made as simple as possible, but no simpler!
Declare your variables, for the contract win!
In the above, we have separated out the parameters from the prose. Interestingly, this is a winning idea in both legal writing and in computer coding. For the legal profession, this is known as contract templating, which allows one contract template to be used across many contracting parties – a great saving in legal fees. You can find more on templating over at Common Accord.
For you coders, declaring your variables in advance forces the programmer to be clear and precise about what is intended. And allows the compiler to help you to follow that intent, e.g., by identifying that all parameters are correctly assigned. For both disciplines, it makes the product easier to read by other professionals, which makes it easier and cheaper to maintain.
A slightly more advanced Markup
The above however is a little hard to code – what happens if we actually want to write in an acronym such as COINNAME or ARTICLE ? What happens when we want a bolded (upper case) warning about inflation, because,you know, central banks & lawyers!?
For this reason we would typically advise a simple markup within the prose. Here’s an example that uses a JSON-like format to set the parameters, and a hybrid to allocate the values.
Article 3 – Currency
{
“COINNAME”: “IangBux”,
“INFLATION”: “5%”,
“INITIALISSUE”: “1,000,000,000”
“SYMBOL”: “$”
“DECIMALS”: “2”
}The Community hereby creates a currency known as {COINNAME}, possession of which is evidence of a contribution to the community. The quantity of {COINNAME} shall increase no more than {INFLATION} per year after the first {INITIALISSUE} of {COINNAME} are distributed.
That is the raw text, with some extra bits needed below. Now, your parser for this is quite simple:
- scan through and pull out all the JSON parts to set some internal variables. In short, JSON blocks are signalled by a curly braces, each opening and closing alone on a line alone, as normal.
- What is left is prose, which needs to be checked for pairs of curly braces, holding parameters to be substituted. Curly braces are safe in this context because a prose legal contract wouldn’t need to use them (I hope!) so they are available for simple parsing.
- Feel free to add some colour or mild formatting to accentuate the slightly smart activity that is going on.
This is simple, but not too simple like the earlier arrangements. JSON is good for parameters but lousy at readable text; prose is hopeless for parameters, but claims great readability.
As simple as possible, but no simpler
Mixing prose & params together in a hybrid creates a simple, computer-readable and human-readable contract that can now be varied and used in different contexts. Our primary goal is still intact – the contract remains no more difficult for a human to read than the original prose; any unreadability that is left over is probably due to the original text, but lawyers have to help us there with plain language contracts (please!).
We could of course use any number of formats. I’ve used INI format in the past. You could use LaTeX or XML, but I won’t be so rude as to inflict those abominations on you in this post! The point here to remember is (a) the purpose of this is first, foremost and always to make the text readable by humans, especially those who don’t spend their life deep in code and technics, and (b) keep it as simple as possible, but no simpler 😉
Having laid down the basic idea of how, my next post will be a brief discussion on why getting the document nailed down matters in the hard-core digital transaction sense, before returning to the Constitution.
End notes: for further reading, see the original paper Ricardian contract. The Clack et al paper Smart Contract Templates: foundations, design landscape and research directions presents current thinking. The most advanced thinking on a clause editor I have seen is at Common Accord. For smart contracts and objectification of blockchain contracts see The Sum of all Chains and in video but that takes us chasing Alice down the rabbithole.
原文链接/Original URL:
https://steemit.com/eos/@iang/towards-a-ricardian-constitution
