走向李嘉图合约（上）

可能是最靠谱不忽悠的区块链资讯平台

这是在几方面进行的思想实验，实验的对象能够把区块链宪法，如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”

}

社区在此创立了名为的货币，拥有此项货币即被视为对社区有贡献的成员。最初个被分发出去之后，持有的数量每年增幅不得超过。

这是原始文本，但下面还需要写一些东西。现在，你需要的解析器也就非常简单了。

1. 扫描并提取所有的JSON部分，设置内部变量。换言之，每一个花括号标志着一个JSON区块，每一个单独的打开和关闭都是正常的。

2. 剩下来的是保留待替换参数的散文格式，这里就需要检查成对出现的花括号，花括号在这里是安全因为散文形式的法律条约不会用到它们（我这么希望！）所以它们可以用在简单的解析上。

3. 任意添加颜色或者简单的格式强调这在发生的简单的智能活动。

这很简单，但不会像前面那个那样过分简单，JSON在参数方面很好，但是可读性就不好；散文格式设置参数是灾难，但是可读性却很好。

越简单越好，但把握好度

把散文格式和参数混合在hybrid格式中，这样就能产生简单、计算机可识别、人类好阅读的合约，这样这些合约就可以在不同的情况下调整使用。我们最初的目标并没有因此改变——相比最初的散文格式，合约对人类来说的可读性并没有变差；如果还剩下一些读不懂的地方，那很可能是原来的文本就有问题，但是律师应该要帮我们用平淡的语言写出合约（拜托了！）

当然，我们想用几种格式都可以。以前我用过INI格式。你可以用LaTex或者XML，只不过本文我不会跟你讲这些麻烦的东西而已！这里我只是希望你能记住，a)这么做的目的首先、最重要、并且必须保持的是，文本必须能够让人类读懂，尤其是对于编程和技术不是那么了解的人来说更是如此 b）越简单越好，但把握好度;-)

在清晰了怎么做的基本思路之后，下一篇文章会关于为什么我们必须坚定地把文档和数字交易捆绑在一起，然后我才会继续讨论区块链宪法。

来源：http://eos.wiki

EOS.Wiki是EOS主网超级节点.

EOS Wiki为社区提供最新的EOS双语资讯和技术文章.

请为EOS Wiki投票. EOS Wiki的账号为eosdotwikibp