【翻译|Ian Grigg】On the intersection of Ricardian and Smart Contracts

Ian Grigg 《在李嘉图合约和智能合约的交汇处》

以下内容的作者为Ian Grigg, 翻译者为Lochaiching。转载必须保留以上声明。仅授权原文转载。原文链接:http://iang.org/papers/intersection_ricardian_smart.html


作者:Ian Grigg


Bitcoin’s inclusion of the smart contract form invented by Nick Szabo has thrust this design into the forefront [Szabo]. An alternate design, the Ricardian Contract designed by the present author [Grigg], is currently used by a few innovatory systems such as OpenTransactions, OpenBazaar, Askemos and CommonAccord [WebFunds].

比特币包含由 Nick Szabo 发明的智能合约形式,这一设计被推向了目前行业中的最前沿 [ Szabo ]。而另一种设计,由本文作者[ Grigg ]设计的李嘉图合约 ,目前被一些创新系统使用,如 OpenTransactions、OpenBazaar、Askemos 和 CommonAccord [ WebFunds ]。

Mark Miller sees these as two halves of a split contract, but a more popular view is to see it as an either/or choice [AMIX]. So let’s try that out: which should you choose? Smart or Ricardian? Let’s find out.

Mark Miller 认为这是把合约拆分为两半,但更多人的观点是倾向于将其视为一种选择 [ AMIX ]。所以让我们试试看:你应该选择哪个?智能的还是李嘉图的?让我们来看看下面的分析先吧!

The original Ricardian Contract captures the legal contract behind an issuance, which is generally a simple payment system moving money from and even what will be one account to another. It is a document that includes all the good stuff people need to know, and a little technical stuff the program needs to know as well. On the whole, the Riccy looks like a contract, by design. It’s intended to be familiar to people, not machines.

最初的李嘉图合约主要抓住了发行背后的法律合同,这通常是一个简单的支付系统,也就是从一个账户转账到另一个账户。这是一份文档,其中包含了使用者需要了解的所有内容,以及程序需要了解的一些技术内容。总的来说,根据设计上看,Riccy 看起来像一份合约。它存在的目的是为了让人类熟悉内容,而不是机器去熟悉。

Figure 1. A “prose” contract.

In terms of defining differences, the Ricardian Contract works well to describe and differentiate shares, bonds, derivatives, more or less anything that means something to a human. Indeed, a Ricardian Contract is conceptually unlimited in the richness of semantics, and OpenTransactions, OpenBazaar, CommonAccord and Askemos among others are extending it in ways beyond the original context of issuance.

在定义差异方面,李嘉图合约很好地描述和区分股票、债券、衍生品,以及或多或少对人类有意义的东西。实际上,李嘉图合约在概念上的语义是非常丰富的,OpenTransactions、OpenBazaar、CommonAccord 和 Askemos等等正在以超出原始发行背景的方式扩展它的范围和领域。

Compare and contrast to Bitcoin and we can see that there is no writing at all — Bitcoin delivers what might be seen as a null contract, one with zero semantics. In contrast, it introduces the smart contract which is a design to capture the flow of actions and events (e.g., delivery of payments) within the performance of a contract.

和比特币相比,我们可以看到根本没有人去写什么内容去推广它 — 比特币提供了可能被视为没有语义且无合约的存在。相比之下,它引入了智能合约,这是一种在履行合约过程中抓取 actions 和 events(例如,交付转移)的设计。

An example will help. Imagine a crowdfunding supported by a smart contract: A potential project could mount a smart contract in a chain. Crowders can pay contributions to the smart contract. When the smart contract reaches its stated close time, it has a binary decision, a choice of two options. If, in one case, the threshold of value has been reached by total contributions, it pays the entire amount to a project account. If, in the alternate, the threshold has not been reached, the smart contract returns (pays out) each contribution back to the source crowder’s account.

下面的例子应该会对理解有所帮助。想象一下智能合约支持的众筹:一个潜在的项目可以在其中一个链上建立智能合约。 Crowders 可以为智能合约支付费用。当智能合约达到其规定的结束时间时,它有两个选项可以选择。假设在一种情况下,筹集的总资金达到了阈值范围(即众筹成功),则它将全部金额支付给项目的账户。在另外一种情况下,尚未达到阈值范围(即众筹失败),智能合约则会筹集的资金返回到每一个资金筹集来源的账户中。

These flows and events can be captured within the smart contract idea, and could substantially free up the infrastructure needed to cope with this design. Pre-tech, we would have had to employ bank accounts, escrow agents, clerks and cheques, envelopes and paper to manage all this. Even post-web we’d need a small army of programmers and interfaces into payment systems and websites. The hope of smart contracts is to outsource all that to a specialist developer who can insert the entire code into the mediating agent (blockchain or at least merkle tree server) for flexibility and scalability.

这些流程和事件可以在智能合约概念中抓取,并且可以完全发布应对此设计所需的基础架构。在技术前期,我们不得不雇用银行账户、托管代理、文员、支票、信封和纸张来管理所有这些。即便是网络发布后,我们也需要一大批程序员把接口接到支付系统和网站。智能合约的希望是将所有这些外包给专业开发人员,后者要将全部代码插入到中介代理(区块链或至少是 merkle tree 服务器)中,以实现灵活性和可扩展性。

Smart contracts then can capture unlimited richness in flows of actions and events; computer scientists might prefer to recognise this as a state machine with money.

然后,智能合约可以抓取无限丰富的 actions 和 events 的数据流; 计算机科学家可能更愿意将其视为有钱的状态机。

Figure 3. Legal semantics versus operational performance.

But what is not captured is the semantics: what is the project? What will it do? How do we know that the contributions are going to our project to design the $100 solar widget to reverse global warming? Or the pension fund for a drug kingpin? How do we even know it is a crowd funding? What do we do when our money doesn’t come back or our project deliverables fail?

但语义没有被抓取到,比如这个项目是什么?它会做什么?我们怎么知道我们的项目是为了扭转全球变暖而设计 100 美元的太阳能小部件,还是主销药物的养老基金?我们怎么知道这是众筹资金?当我们的资金没有下落或可交付成果的项目失败时,我们该怎么办?

A simple solution could be to point the smart contract at a URL. But the URL can be intercepted, and the contents of a web page can be changed, or even disappear. Within the webpage there can be a confusing array of claims and counter-claims, and mingling of projects. This arrangement does not reliably capture semantics except in the accidental circumstance that lawyers audited the approach up front — accidental because no crowd funding project would survive the billing process, and no crowder would contribute to such a tedious webpage.

目前能想到的一个简单的解决方案是将智能合约指向一个 URL。这个 URL 可以被拦截,并且可以更改网页的内容,甚至消失。在网页内可能存在一系列令人困惑的索赔和反索赔,以及混合多种元素的项目。这种设计不能完全抓取到字面的意思,除非在意外情况下,比如律师事先审计了这种方法 — 或者另外一种情况,因为没有群众资助项目能够在计费过程中存活下来,并且没有人会想为一个单调乏味的网页做出贡献。

In contrast, a Ricardian Contract captures the meaning of the flows in a way that is secured to your actions within the contract. Yet, it says little about how the flows carry forth in any particular cycle, indeed, because it is mostly words created in advance of the action, it fails to capture any flows at all. Historically, Ricardian Contracts were used to support your basic 3 party payment systems: Alice pays Bob through Ivan the Issuer, and note that even that was assumed, not specified in the contract.

相比之下,李嘉图合约以一种确保合约内行为的方式定义变化的含义。然而,它几乎没有说明流程在任何特定周期中如何发生,实际上,因为它主要是在行动之前创建的词语,它根本无法捕获任何流动。从历史上看,李嘉图合约用于支持您基于三方的支付系统:Alice 通过 Ivan 向发行人支付 Bob,并注意即使是假设,也未在合同中指明。

The smart contract and the Ricardian Contract are therefore doing different parts of the same process. Performance and semantics are approximately orthogonal, so we should be able to construct a graph of two axes, see figure 3 above.


There is a place in human interactions for both, and probably both would be useful in a wider system. Where the challenge lies today is how to combine these approaches so that the technology can better help humans to mediate more complicated agreements with success and a desire to engage again.


In a very stylised sense, we can also see something of the same sense of differing richnesses in classical finance systems, figure 4 below. On the vertical axis we see how many different contracts are in use, and how complicated each can be. For example a typical forex system handles about 20 base currencies, and an OTC derivative can run to 300 pages. And on the horizontal axis we can see complexity in the performance of the deal. The stock exchange involves conceptually 4 payments, 2 inwards and 2 outwards. Mortgages involve hundreds of payments over their lifetime, and securitization lumps all those into a basket that slices off dividends to holders of the basket. Performance of these things is very complicated [Evidence].

在一个非常风格化的意义上,我们也可以看到古典金融系统中具有不同丰富感的东西,如下图4所示。在纵轴上,我们看到有多少不同的合同在使用,每个合同有多复杂。例如,典型的外汇交易系统处理大约 20 种基本货币,场外交易衍生品可以运行 300 页。在横轴上,我们可以看到交易表现的复杂性。证券交易所涉及概念上的 4 笔付款,2 笔向内付款和 2 笔向外付款。抵押贷款涉及到他们一生中的数百笔付款,而证券化将所有这些付诸东西,将所有这些都归咎于向篮子持有人分红。这些东西的表现非常复杂 [ 证据 ]。

The national currency, as a paper banknote within its country, sits at the origin, position 1,1, in that there is only one permitted, and it has only one simple hand to hand action.


Figure 4. Semantically distinct instruments versus operationally complex performances.

What’s going on here? A big part of this confusion is an overloading of the term contract. In the Ricardian case, the thing in question is a document. In the smart case, it is a machine to organise and control the arrival of events and initiation of actions.


As it turns out, in law, neither is precisely the contract. More formally, the contract is the agreement between the parties. A document might represent a good stab at recording this agreement, but it can be augmented by side documents, so while there is often a document called “the contract,” this is actually quite hopeful. We might better understand it as “the best and hopefully dominating recording of the agreement.”


How do we resolve the difference between the document and the agreement? We go to court, and the court will decide what is the contract after analysis of all the evidence. A court is the power, and simply put, it is free to strike down clauses, add clauses, or indeed send people to jail.


Hence, a Ricardian Contract isn’t the contract but merely our best efforts at creating a single document that dominates the contract as found by the court. ¡Ojala!


Meanwhile, the smart contract is really the machine to perform the contract. As a smart contract is written before it all starts, it is presumably part of the wider agreement, so the court will likely find the source code as much a part of the contract as any other document. Although, whether the court can read the source code is another matter.


How did society organise all this before the technologies of cryptocurrencies muddied the waters? Well, the court would read the written document looking for indications of performance. It would expect the parties to have done some or all of the stated actions as per the writing, and ask for evidence of these actions.


As smart contracts seek to capture the intent into code, and evidence any actions through it, they therefore relieve humans of much of the drudgery of doing that which they already agreed to do, are intending to do, and may need to prove to the court that which has been done. Where we’re left with is that the smart contract isn’t entirely fulsome, as it fails to carry the richer framework of words. Likewise, the Ricardian Contract is a clumsy vehicle in which to insert difficult code. In this contest, it isn’t even a draw, the two devices are fighting to pull together: Both are trying to improve our agreements at different points and in different ways, within the overall framework of a contract in law.

由于智能合约试图将意图在代码中体现,并通过它来证明任何 action,因此它们可以减轻人们在做他们已经同意做的,打算做的事情上的大部分苦差事,并且可能需要向法庭证明已完成的事情。我们留下的地方是智能合约并不完全令人满意,因为它无法传承更丰富的词汇框架。同样,李嘉图合约是一种笨拙的工具,可以插入困难的代码。在这场比赛中,这甚至都不是平局,这两个设备正在争取共同努力:两者都试图在法律合同的总体框架内以不同的方式和不同的方式改进我们的协议。

In practical terms we can now look at the original Ricardo system as a system with infinite semantic ability but capable of handling by assumption only one form of action — perhaps the Alice to Bob payment [Ricardo]. Whereas Bitcoin can handle a multitude of smart-enabled transaction forms but in only one semantically trivial unit: assumed to be the bitcoin[Bitcoin]. Those axes in the figures cross at 1 !

实际上,我们现在可以将原始的里卡多系统视为一个具有无限语义能力的系统,但能够通过假设只采用一种形式的行动来处理 — 也许是 Alice to Bob 支付 [ Ricardo ]。而比特币可以处理多种智能交易形式,但只有一个语义上的简单单位:假设是比特币 [ 比特币 ]。图中的那些轴交叉为 1!

Figure 5. Ricardo versus Bitcoin.

The task is to encompass both elements into one contract [Path]. Today, we’ve moved forward.

任务是将两个元素包含在一个合同中 [ Path ]。今天,我们向前迈进了一步。

· OpenTransactions added server-side smart contracts to its technology permitting many more transaction types [OT].

· Askemos clients run agreed smart contracts and insert events and state into a merkle tree as they happen [Askemos].

· A newer system, OpenBazaar composes Ricardian Contracts into trade cycles of invoice, acceptance, payment etc, thus also handing many conceptually complicated transaction types [OB]. In concert, CommonAccord places small smart contracts with Ricardians and then composes these pairs into larger agreements.

· Ethereum is taking the approach called Natural Specification Format in its smart contract programming language Solidity [Ethereum]. In-code documentation is augmented by marking comments with /// which can then be parsed and analysed to describe what the contract does and to keep the user informed during contract performance.

· OpenTransactions 将服务器端智能合约添加到其技术中,允许更多的交易类型 [ OT ]。

· Askemos 客户运行商定的智能合约,并将事件和状态插入到 merkle 树中 [ Askemos ]。

· 较新的系统,OpenBazaar 将 Ricardian Contracts 组成发票、验收、付款等交易周期,因此也处理了许多概念上复杂的交易类型 [ OB ]。在演唱会上, CommonAccord 与 Ricardians 签订了小型智能合约,然后将这些合同组成更大的协议。

· 以太坊在其智能合约编程语言 Solidity [ Ethereum ]中采用了称为自然规范格式的方法。通过使用///标记注释来增强代码内文档,然后可以对其进行解析和分析,以描述合同的作用并在合同履行期间让用户知情。

Meanwhile, on the Bitcoin front, exasperation with the one unit led to many altCoins which were essentially base copies of the code with some params changed.

与此同时,在比特币方面,对一个单位的恼怒导致了许多 altCoins,它们基本上是代码的基础副本,其中一些参数更改了。

Figure 6. Evolution.

This latter approach by the Bitcoin community led to unfortunate consequences, which can now be interpreted in the context of semantic poverty. As more and more altCoins piled in with inadequate expressions of meaning, the field became noisy. When a booming investment field becomes noise-rich and semantically poor, there is plenty of scope and space for charlatans to siphon off funds of the ignorant investor. altCoins inevitably drift to noiseCoins, and more and more of them ended up looking like one-way contributions to the memory of the late great Charles Ponzi.

比特币社区的后一种方法导致了不幸的后果,现在可以在语义缺乏的背景下进行解释。随着越来越多的 altCoins 表达不充分的意义,该领域变得嘈杂。当蓬勃发展的投资领域变得富有噪音且语义贫乏时,骗子们有足够的空间和空间来吸走无知投资者的资金。altCoins 不可避免地漂移到噪音中,而且越来越多的人看起来像是对已故伟大的查尔斯庞齐的记忆的单向贡献。

Figure 7. altCoins evolve to anti-semantics.

In contrast, we could also speculate that simple payment flow systems have not managed to garner enough of the total transaction flow, and thus have enjoyed limited success. If they can expand to handle more richness in performance of contracts, success may be easier.


We can now see that the real challenge between smart contracts and Ricardian Contracts or legal documents is not to choose, but to incorporate. The Bitcoin world will benefit from adding the semantic richness of legal documentation into its service. There are approximately three fronts along which this is taking place:


Firstly, from within, as direct issuances. Sidechains [Back] can add issuances with approximately these changes, being (a) create a new genesis transaction for an issuance, as distinct to the genesis transaction for a new blockchain — an innovation discussed in Mark Friedenbach and Jorge Timón’s paper on multi-instrument chains [FreiMarkets]; (b) tie the Ricardian contract into the issuance genesis transaction, © identify the chain and the issuance by means of hashes over the combined genesis, and (d), change the transaction record to incorporate the two new identifiers, issue + chain, when w expressing a movement of value from one key to another. See also The Sum of All Chains — Let’s Converge! for a relevant framework [SOAC].

首先,从内部直接发行。Sidechains [ Back ] 可以添加近似这些变化的发行,是(a)为发行创建一个新的创世纪交易,与新区块链的创世交易截然不同 — 这是 Mark Friedenbach 和 JorgeTimón 关于多仪器的论文中讨论的一项创新链 [ FreiMarkets ]; (b)将李嘉图合约与发行成因交易联系起来,(c)通过合并起源的哈希识别链和发行,以及(d),更改交易记录以包含两个新标识符,发行+链当表达从一个键到另一个键的值的移动时。另见所有链的总和 — 让我们聚合吧!有关的框架可以点击 [ SOAC ]。

Secondly from without: the Ethereum, Ripple, or more contractually minded reworkings such as Hyperledger or Eris can more easily add in the integration of the two forms.

其次来自没有:以太坊,Ripple 或更多合约意识的重写工作,如 Hyperledger 或 Eris 可以更容易地加入两种形式的整合。

Thirdly, projects such as Askemos, CommonAccord and OpenBazaar are using the hybrid text & code form of contracts to compose new constructs such as reusable contracts and trade patterns [CA].

第三,诸如 Askemos,CommonAccord 和 OpenBazaar 等项目正在使用合约的混合文本和代码形式来组成新的构造,例如可重用合同和交易模式 [ CA ]。

Figure 8. Coupling code snippets to clauses and composing upwards.

Likewise, my and other simple 3-party payment systems should follow the lead of the innovators mentioned above and consider merging the smart contract ideas in to achieve better performance flexibility. How this is done is well beyond the scope of this note, and methods remain hotly debated.


This article received useful comments from Preston Byrne, Florian Glatz, James Hazard, Stephen Palley, Roger Willis and Jörg F. Wittenberger (alphabetical order).

本文收到了 Preston Byrne、Florian Glatz、James Hazard、Stephen Palley、Roger Willis 和 JörgF.Wittenberger(按字母顺序排列)有价值的评论。


[wip] A working draft of this article was located in google docs. This version July 2016 has tiny editorial improvements: citations, a permanent home.

[Szabo] Nick Szabo, “Smart Contracts,” http://szabo.best.vwh.net/smart.contracts.html 1994

[Grigg] Ian Grigg, “The Ricardian Contract,” http://iang.org/papers/ricardian_contract.html 2004

[WebFunds] WebFunds, “Implementations of Ricardian Contracts,” http://webfunds.org/guide/ricardian_implementations.html

[AMIX] John Walker, “Understanding AMIX,” The Autodesk File 4th edition, ed. John Walker, 1994

[Evidence] Ian Grigg “A small amount of Evidence. (In which, the end of banking and the rise of markets is suggested.)” http://financialcryptography.com/mt/archives/001299.html 2010

[Ricardo] Ian Grigg, “Financial Cryptography in 7 Layers,” http://iang.org/papers/fc7.html in Financial Cryptography 2000, Yair Frankel, Ed. 2002 Springer http://www.springer.com/us/book/9783540427001

[Bitcoin] Satoshi Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” https://bitcoin.org/bitcoin.pdf 2009

[Path] Mark S. Miller and Marc Stiegler, “The Digital Path,” http://www.erights.org/talks/pisa/paper/#human in Markets, Information and Communication: Austrian Perspectives on the Internet Economy, Jack Birner and Pierre Garrouste, Eds, 2003 Routledge https://books.google.com/books?id=x-FQrKrjgcYC&hl=en

[OT] Chris Odom, “Open-Transactions: Secure Contracts between Untrusted Parties,” 2015, http://www.opentransactions.org/open-transactions.pdf and Chris Odom, “Sample Currency Contract,” http://opentransactions.org/wiki/index.php/Sample_Currency_Contract 2013

[Askemos] Jörg F. Wittenberger, “Askemos — a distributed settlement,” 2002, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=

[OB] Washington Sanchez “Ricardian Contracts in Open Bazaar,” 2014, https://gist.github.com/drwasho/a5380544c170bdbbbad8

[Ethereum] Lefteris Karapetsas and Gavin Woods, “Ethereum Natural Specification Format,” 2014, https://github.com/ethereum/wiki/wiki/Ethereum-Natural-Specification-Format

[Back] Adam Back et al, “Enabling Innovation with Pegged Sidechains,” 2014 https://blockstream.com/sidechains.pdf

[FreiMarkets] Mark Friedenbach, Jorge Timóna, “Freimarkets: extending bitcoin protocol with user-specified bearer instruments, peer-to-peer exchange, off-chain accounting, auctions, derivatives and transitive transactions,” 2013 http://freico.in/docs/freimarkets-v0.0.1.pdf

[SOAC] Ian Grigg “Sum of all Chains — Let’s Converge,” CoinScrum / Proof of Work’s Tools for the Future, 2015 http://financialcryptography.com/mt/archives/001556.html

[CA] James Hazard, CommonAccord, http://www.commonaccord.org/

【Female on the earth】【 BD | FA | Marketing Building | Blockchain】【 Cantonese, Mandarin, English | Hebrew learner】