以下内容来自微信公共帐号“EOS技术爱好者”，搜索“EOSTechLover”即可订阅，翻译Gavin，校对Lochaiching。转载必须保留以上声明。仅授权原文转载。

本文原文链接为https://busy.org/@iang/towards-a-ricardian-constitution ，由本号“EOS技术爱好者”翻译。

"EOS技术爱好者"全程由EOShenzhen运营，喜欢我们请为我们投票（EOShenzhen的投票账号：eoshenzhenio）！

Towards A Ricardian Constitution

走进李嘉图合约

作者：Ian Grigg

翻译：Gavin

校对：Lochaiching

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.

这是一个在几个方面进行的思想实验，目的是将一个区块链的合约，如EOS提案变成一份完整的李嘉图合同。这并不像听起来那么难，而且可能会带来一些意想不到的好处。

For the quick intro, a Ricardian contract(http://iang.org/papers/ricardian_contract.html) 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.

先进行一下简单介绍，李嘉图合约（http://iang.org/papers/ricardian_contract.html ）是一种散文，或者说是一种包含计算机可标记标记的法律合约。按这顺序来看的话：它首先是一个人类可读的文档，其次是机器可读的文档。

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.

人类是放在第一位考虑的，因为他们（我们？）是困难的那一部分。对于合约之所以可以称为合约，它必须有目的，这意味着人不仅要知道它,还必须完全理解它，以便能够以一种被所有（human-staffed）法院看做是一个合法的合约的方式来达成协议。建立这种确切的意图是非常重要的，以至于我们经常把它变成一个众所周知的仪式，就像法院签署一样。

All this human stuff turns out to be a very hard problem to do digitally (https://blogs.perficient.com/2015/03/03/21-cfr-part-11-decoded-electronic-signature-general-requirements-2/ ), 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.

将所有这些人类的东西来实现数字化是一个非常困难的问题（https://blogs.perficient.com/2015/03/03/21-cfr-part-11-decoded-electronic-signature-general-requirements-2/ ），而让计算机理解文档却是很容易的——只要在其中插入一些标记就可以了。当你阅读这个不熟悉的合约时，记住这个排序——人类第一位，计算机第二位。

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(https://steemit.com/eos/@dantheman/what-could-a-blockchain-constitution-look-like )that might or might not be useful for EOS:

让我们尝试一下!我们来写一个散文公约（https://steemit.com/eos/@dantheman/what-could-a-blockchain-constitution-look-like ），并在其中加入一些标记。例如，这里有一个示例版本合约的一个条款，它可能对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.

大家注意，本条款的作者（@dantheman）希望其他人使用这个示例，甚至在很大程度上暗示可以将EXAMPLE更改为MyCoin或YourCoin或BobCoin或类似的东西。这有点费力，但很有必要通过这么修改来使这一条款适用于不同的上下文——这就是我们的核心论点：我们希望保持一个合适的合约的准确性，但当我们想让它用于特定的区块链上下文中，又希望让计算机做一些编辑和演示工作，就需要使用上述的模板将其转换为我们的最终合同。

And we want to enable the humans (and the computer) to easily interpret the results, as well.

我们也想让人类（和计算机）都能很容易地解释结果。

Contract Cake

合约蛋糕

ian走进合约1.png

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,000

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.

With a graphical contracts editor, we can process the above dry document to display the prose contract derived from the above.

使用图形合约编辑器，我们可以处理上述干文档以显示从上面得到的散文性质合约。

ian走进合约2.png

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):

你可以试着将鼠标悬停在那些已替换了原始名称的颜色高亮的部分上。或者，我们可以使用一种模式来按颜色跟踪变量并突出显示，就像在程序员的IDE（集成开发环境）中一样：

ian走进合约3.png

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!

现在，重要的是要意识到一些东西。我们不想要太多的乐趣。这样做的原因是，那些对图形、技巧、工具包、FLASH、弹出窗口、特殊优惠和其他令人厌恶的东西有太多乐趣的人，会使那些个系统的主要使用者——用户们使用起来变得更加困难。就像爱因斯坦说的，这个系统应该做到尽可能简洁，但不简单！

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(https://arxiv.org/abs/1608.00771), 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(https://CommonAccord.org).

在上面，我们已经把这些参数从散文中分离出来了。有趣的是，这在法律编写和计算机编码中都是一个成功的想法。对于法律行业来说，这就是所谓的合约模板(https://arxiv.org/abs/1608.00771 )，它允许一个合约模板在许多缔约方之间被使用——这是法律费用的巨大节省。你可以在Common Accord (https://CommonAccord.org )上找到更多的模板。

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!?

然而，上面的代码有点难以实现——如果我们真的想用COINNAME或ARTICLE等首字母缩略词写一下会发生什么？当我们想要一个关于增发的粗体（大写）警告时会发生什么，因为你知道中央银行和律师！？

For this reason we would typically advise a simple markup within the prose. Here’s an example that uses a JSON-like format(https://en.wikipedia.org/wiki/JSON ) to set the parameters, and a hybrid to allocate the values.

出于这个原因，我们通常会在散文中使用一个简单的标记。这是一个使用类似JSON的格式 (https://en.wikipedia.org/wiki/JSON ) 来设置参数的示例，以及一个混合使用来用于分配值。

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:

1.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.

2.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.

3.Feel free to add some colour or mild formatting to accentuate the slightly smart activity that is going on.

这是原始文本，下面需要一些额外的比特值。现在你的解析器非常简单：

1.扫描并取出所有的JSON部分来设置一些内部变量。简而言之，JSON区块是由一个花括号发出的，每个单独的打开和关闭都是正常的。

2.剩下的是散文，需要检查成对的花括号，保持要替换参数。在这种情况下，花括号是安全的，因为散文法律合约不需要使用它们（我希望如此），因此它们可以用于简单的解析。

3.请随意添加一些颜色或柔和的格式，以强调正在进行的轻微的智能活动。

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.

这很简单，但不像之前的预料那么简单。JSON对参数有好处，但可读性很差；散文对于参数来说是很不友好的，但是它的可读性很好。

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!).

将散文和参数混合在一起，创造了一个简单的、计算机可读的和人类可读的合约，现在可以在不同的上下文中进行变化和使用。我们并没有违背我们的主要目标——合约对于人类来说，阅读起来并不比原始的散文更困难；剩下的任何不可读性可能都是由于原始文本造成的，但是不要忘记律师们会用简单的语言合约来帮助我们（请！）。

ian走进合约4.png

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 ;-)

我们当然可以使用任意数量的格式。我过去使用过INI格式。你可以使用LaTeX或XML，但我不会那么粗鲁，不能在这篇帖子中给你带来这些麻烦的东西！这里要记住的几点是：（a）这首先是最重要的目的是让人们可以阅读文本，特别是那些不会在代码和技术上花费很多精力的人，以及（b）尽可能的简约，但不简单;-)

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(http://iang.org/papers/ricardian_contract.html ). The Clack et al paper Smart Contract Templates: foundations, design landscape and research directions(https://arxiv.org/abs/1608.00771 ) presents current thinking. The most advanced thinking on a clause editor I have seen is at Common Accord(https://CommonAccord.org ). For smart contracts and objectification of blockchain contracts see The Sum of all Chains(http://financialcryptography.com/mt/archives/001556.html ) and in video(http://financialcryptography.com/mt/archives/001556.html ) but that takes us chasing Alice down the rabbithole.