本文原文链接为 http://iang.org/papers/ricardian_contract.html ，作者 Ian Grigg，初译Fred，校对 Lochaiching。
ps. 本文首发于 2018.4.15，简书。后来简书提示本文仅作者可见，遂迁移至此。
The Ricardian Contract
Describing digital value for payment systems is not a trivial task. Simplistic methods of using numbers or country codes to describe currencies, and ticker tape symbols to issue bonds, shares, and other financial instruments soon run into shortcomings in their ability to handle dynamic and divergent demands. The seemingly arbitrary variations in the meanings of different instruments are best captured as contracts between issuers and holders. Thus, the digital issuance of instruments can be viewed as the issuance of contracts.
This paper proposes that the contract is the issue. A document form is described that encompasses the inherent contractual nature of the financial instrument yet copes with the requirements of being an integral part of a payment system.
Little work has been done on classification and description of value in the field of financial cryptography. This paper presents the Ricardian Contract, a method to identify and describe issues of financial instruments as contracts . It was originally developed by Ian Grigg and Gary Howland as part of the Ricardo payment system.
金融密码领域的价值分类和描述工作做得很少。本文介绍了李嘉图合约，这是一种识别和描述金融工具合约问题的方法 [ 1 ]。它最初由Ian Grigg和Gary Howland开发作为Ricardo支付系统的一部分。
**1.1. The Origins **
The original application was a bond trading system . For trading, a basic component is a transfer or payment system which receives and acts on transfer instructions to move instruments (cash, bonds) from one account to another. Each instruction therefore must identify the instrument.
A means was required to capture, identify, and describe the traded instruments. There are thousands of bonds, and potentially millions of other instruments that could be issued and traded, and each has unique characteristics that are not amenable to compression into databases. To such a system, cash is no different to bonds, and requires the same description.
最初的应用是债券交易系统 [ 2 ]。对于交易而言，基本组成部分是转账或支付系统，它接收并执行转账指令，将工具（现金，债券）从一个账户转移到另一个账户。因此每条指令都必须标识该工具。
1.2. The Problem
When someone issues a currency (or bond or share) over the Internet, what is it? What does the recipient have?
Few systems for issuance of value (payment systems) treat these questions adequately. They generally refer to existing external units of currency and tidy up loose edges in a user agreement. For example, Paypal, an issuer of dollars, relies on the familiarity of the US dollar to define much of its service offering. Gold issuers lean more heavily on their user agreements as the metal unit is not so familiar.
For trading, it is not sufficient to refer to well-known familiar references, as each instrument is different in finicky ways and these differences matter to traders. Even with currencies, however, the user has difficulty in determining the security and safety of one dollar with respect to another.
Classification by numbers or symbols is a starting point. Almost all systems of digital issuance identify their basic issue by allocating numbers or letters as currencies (for example, 840, "USD", "AUG" ). These systems runs into trouble quickly.
An issuer with many currencies or many issuers with the same nominal currency raises difficult questions. Can an issuer have two or more dollar units? For example, within ISO3166-1, there are three different US dollars: 840/USD (cash), 998/USS (same day), and 997/USN (next day). Similarly, how does one Digital Gold Currency ("DGC") differentiate his gold over that of another issuer, when all are known as "AUG"?
按数字或符号分类是一个起点。几乎所有的数字发行系统都通过分配数字或字母作为货币来识别他们的基本问题（例如，840，“USD”，“AUG” [ 3 ]）。这些系统很快就会遇到麻烦。
许多货币或许多发行人使用相同名义货币的发行人提出了难题。发行人可以有两个或更多的美元单位？例如，在ISO3166-1中，有三种不同的美元：840美元（现金），998 美元（当天）和997 美元（第二天）。同样，当所有人都称黄金为“AUG”时，数字黄金货币（DGC）如何将他的黄金与另一个发行人的黄金区分开来？
1.3. The Solution
As bonds are, at their essence, contracts between issuers and users, our problem reduces to one of issuing contracts. Whereas other issues have contracts, our issues are contracts.
Our innovation is to express an issued instrument as a contract, and to link that contract into every aspect of the payment system. By this process, a document of some broad utility (readable by user and program) is drafted and digitally signed by the issuer of the instrument. This document, the Ricardian Contract, forms the basis for understanding an issue and every transaction within that issue.
By extension, all issues of value, such as currencies, shares, derivatives, loyalty systems and vouchers, can benefit from this approach.
This paper is structured as follows. In Section 2, we discuss conventional approaches to identifying and describing issuance, and explore questions and doubts surrounding these approaches. Then, in Section 3, a design to express issuance as a contract is presented. Finally, in Section 4, concluding remarks are added.
此篇文章的结构如下。在第 2 节中，我们讨论了识别和描述发行的传统方法，并探讨了这些方法的问题和疑问。在第 3 节中，提出了一个设计来表达发行合约。最后，在第 4 节中，添加结束语。
2. Issues of Value as Contracts
2.1. A First Generation Scheme
Consider the case of the pioneering digital cash scheme, eCash, as originally fielded by DigiCash BV. The first valuable currency, issued by Mark Twain Bank of the USA, was identified with the number 4. Lore has it that the early system allocated a small sequential number to each currency. Test systems had already acquired 0,1,2,3 and thus 4 was the next. DigiCash's marketing assumptions then changed to assume one issue per country. In time, this scheme was adjusted to issue currencies numbered after international dialling codes (e.g., 49 for Germany, 61 for Australia). The shortfalls of this scheme became apparent, so a new design was created . One 32 bit number to describe the issue was used, on the pragmatic assumption that this would be large enough to cover foreseeable eventualities.
Yet the strains of one issuer, one currency were obvious almost immediately. A more advanced scheme could use a tuple of (issuer, currency) to describe a system whereby each issuer is empowered in some sense to issue multiple competing currencies . It is easy to generalise this system by adding additional elements to the tuple: (issuer, type, identifier) tuple . For example, a zero coupon bond issued by the Joint Universal and Nationwide Keiretsu that pays out in January of 2100 might have a tuple of (JUNK, zero, Jan_2100).
考虑 DigiCash BV 最初采用的开创性数字现金计划 eCash 的案例。美国马克吐温银行发行的第一个有价值的货币被确定为 4 号。知道早期的系统为每种货币分配了一个小的连续数字。测试系统已经获得了 0,1,2,3，因此接下来的是 4。DigiCash 的策略为假设每个国家都是一个发行编号。随着时间的推移，该计划进行了调整，以发行按国际拨号代码编号的货币（例如，德国 49，澳大利亚 61）。这种方案的不足之处变得明显，因此创建了一个新的设计 [ 4 ]。在实用的假设中，一个 32 位的数字将大到足以涵盖可预见的可能性。
发行越多，只有一种货币不够用的压力很快就显而易见。一个更先进的方案可以使用（发行者，货币）元组来建立一个新的系统，每个发行者在某种意义上被授权发行多种竞争货币 [ 5 ]。通过向元组添加附加元素来简化这个系统：元组（发行者，类型，标识符） [ 6 ]。例如，由 Joint Universal 和 Nationwide Keiretsu 在 2100 年 1 月发行的兑付零息债券形成一个元组为（JUNK，0，Jan_2100）。
2.2. The trouble with Numbers
Numbers as a space for identifying digital instruments are limiting, and having tuples as an extension is not really an answer.
Firstly, what do they describe? In the case of electronic cash systems, they can describe currencies and issuers. Is it one or both, and how do we generalise to other aspects? Secondly, what surety do we have that what is described is accurate? Whilst a lot can be achieved by simply relying on the reputation of the issuer, financial insiders know that the real value is expressed in the detail and the reliability of the claim. Thirdly, how are the numbers derived? Is a central registry required, or can any issuer of digital value acquire a number as per local requirements? Finally, is there a limit to the space? Integer numbers as expressed in packets are generally limited to some quantity of bits, such as 32. For practical software engineering, there need to be limits, but do these limits need to limit the business possibilities?
首先，他们描述了什么？在电子现金系统的情况下，它们可以描述货币和发行者。它是一个还是两个，我们如何概括其他方面？其次，我们用什么保证所描述的是准确的？虽然仅凭依赖发行人的声誉就可以实现很多目标，但财务内部人士知道，真正的价值体现在索赔的细节和可靠性上。第三，这些数字是如何得出的？是否需要一个中央注册机构，或者任何数字价值发行机构能否根据当地要求获取一个数字？最后，空间是否有限制？以数据包表示的整数通常限于一些 bit，例如 32。对于现实中的软件工程，需要有限制，但是这些限制需要限制业务的可能性吗?
2.3. The Challenge of Success
Any successful system will be used in ways that make it appear to be broken. As software engineers, we need to present our inventions with the humility of toolmakers for future generations of builders, not as bureaucrats planning the zoning of the digital commerce space.
What happens when we have gone through the early adopters, dominated the moms and pops, and competition is fiercely turning onto our elderly retired set? Imagine mints in the pockets of billions of idle game-playing senior citizens. Or, imagine a world with an issuer of digital loyalty points on every parking meter, or where students must pay for tuition with shares of future earnings. Already we have seen popular musicians selling bonds backed by their music , and proposals for software bug fixes financed by securitized issues to anonymous users .
当我们早期的采用者主宰了妈妈和流行音乐的内容，这种激烈地竞争转向到了我们的退休老人组时，会发生什么？想象一下这个世界：数以亿计的闲暇游戏老人的口袋里的钱财，或者在每个停车计时器上都有一个数字忠诚点，又或者学生必须支付未来收入份额的学费。我们已经看到了流行歌手向粉丝销售某些金融债券 [ 7 ]，并提出了通过证券化问题为匿名用户提供资金软件缺陷修复的建议 [ 8 ]。
2.4. The Zero Coupon Bond
Consider the zero coupon bond, an instrument that pays a face value of a currency on a given date. The zero is perhaps the simplest general financial instrument in common use, and it formed the benchmark for our design.
To describe the face value, the currency of the face value, and the expiry date of this bond, we would add additional elements to the above tuple. But this is only a beginning. In his description of Eurobonds, Noel Clarke expects dozens or hundreds of fields . If we examine just one of these characteristics, for example Event-Related Put Options, we find that a bond needs to describe what happens in the event of:
a hostile or friendly takeover of the issuer,
a takeover by the issuer of another party,
a repurchase program by the issuer of its own shares, or
a distribution of assets above a certain percentage of the issue's net worth.
These items bind tightly to the instrument in question, but they represent difficulties to the software architect. We can make a number of observations.
Firstly, each event is not simple. Today, one may be able to shoehorn the notion of "a hostile or friendly takeover" into a single name-value pair, but this would not survive the evolving scene of regulation and litigation that applies to such events.
Secondly, there is no reason to believe that the above list is complete.
Thirdly, not only is it going to be hard to design a single field of any sort to cope with these, they are mostly going to be full of legal text.
Consider a data layout point of view. To describe the document that forms the basis of a bond we will need a tree-structured database of tuples, as a minimum. More, that layout is only going to work for one instrument, or one extremely tight, nearly fungible set of instruments.
为了描述面值，面值的货币和该债券的到期日期，我们会在上面的元组中添加额外的元素。但这只是一个开始。Noel Clarke 在描述欧洲债券时预计有数十个或数百个领域 [ 9 ]。如果我们只考察其中一个特征，例如与事件相关的看跌期权，我们会发现债券需要描述在以下情况下会发生什么情况：
首先，每个事件都不简单。今天，人们可能会将 “恶性或良性收购” 的概念强加于单一的名称——价值对，但这无法适用于此类事件不断演变的法规和诉讼场景。
2.5. Cash is King
Currencies, or cash, might be that tight set. After all, a dollar is a dollar is a dollar. Can we describe money with some simple set of tuples? Even for cash, we argue that a layout of tuples is not sufficient.
Take the case of a digital dollar issued by a bank. The digital dollars would be derivatives, often backed by deposits in the same amount. This may be sufficient for marketing purposes but it would not survive a serious financial analysis.
Compare such derivative dollars to those issued by the US Federal Reserve Board. The Fed has yet to deny acceptance of its notes if presented with same, if only as a claim on another bunch of the same instrument, or for taxation liabilities. Radical interpretations aside, the Fed has never filed for bankruptcy and remains a pretty solid bet.
The same cannot be said of just any bank issuer of derivative dollars. Its digital dollars would be backed by deposits with ... the very same institution. Such a bank can close its doors at any time, and, given the history of the banking sector in the 20th Century, an analyst should take this risk seriously. Further, in the USA at least, the FDIC has already ruled that funds so held on a user's PC are considered to be uninsured deposits .
This is not to suggest that any given bank is about to close doors, but to ask what happens when an issuer does indeed default on its promise?
Any holder of any asset will carry a risk. A holder of electronic dollars will carry the risk that the issuer fails, and the holder of another issuer's dollars carries a similar, comparable, but distinct risk. Each of those risks result in a cost, which should be subtracted from the face value of the dollar to calculate a comparative value. In this risk distinction lies the inescapable fact that any given dollar is not of constant value, even when measured against some well-known dollar such as that issued by the Federal Reserve.
相比之下，美国联邦储备委员会(Federal Reserve Board)发布的这类衍生品美元的价格是如此之高。如果它是相同的，只是作为对另一种相同工具的债权，或者是税收负债，美联储还没有拒绝接受它的票据。撇开激进的解释不谈，美联储从未申请破产，而且仍是一个相当可靠的赌注。
任何衍生品美元的银行发行人也不能这样说。它的数字美元将得到与......相同机构的存款支持。鉴于 20 世纪银行业的历史，这样的银行可以随时关门，分析师应该认真对待这种风险。此外，至少在美国，FDIC 已经判定这样持有用户 PC 上的资金被认为是没有保险的存款 [ 10 ]。
2.6. The Fine Print of the Contract
If there is no such thing as a single dollar, what is left? Clearly, we must describe each and every dollar for what it is. This would seem to be a task of fine print and detail, and, indeed, every distinct issued currency is a distinct contract between the issuer and the holder.
A contract can encapsulate the detail. Consider the original sovereign currency contracts, in which the issuer promised to pay the bearer in ounces of precious metal. That is four datum in the contract already: which sovereign, "pay to bearer," what to pay, and how much of it.
So it is with every bond, every currency, and any financial instrument of any complexity In fact, within the digital domain, the question of how to treat a financial instrument reduces in great part to how to treat a contract.
Or, an issue is a contract. Issues within other payment systems have contracts but only as adjunct documents such as user agreements. Often, their role and importance is subject to battles; Marketing wants them hidden, while Legal asks for them to be thrust in the user's face at all times.
Once we accept that the issue is a contract, the task becomes simple: create a contract that can be linked into the payment system as the centerpiece. That is the subject of the next section.
3. A Digital Contracts System for Issuance
Almost all aspects of Ricardian Contracts are best seen by examining examples, and this section only briefly covers the salient details, before discussing the ramifications. Examples can be found http://atwebfunds.org/ricardo/contracts/ .
李嘉图合约几乎所有内容都可以通过检验例子来展示，本节仅简要介绍明显的细节，然后再讨论分支。例子可以在 http://webfunds.org/ricardo/contracts/ 找到 。
A Ricardian Contract can be defined as a single document that is a) a contract offered by an issuer to holders, b) for a valuable right held by holders, and managed by the issuer, c) easily readable by people (like a contract on paper), d) readable by programs (parsable like a database), e) digitally signed, f) carries the keys and server information, and g) allied with a unique and secure identifier.
In the simplest possible terms, a Ricardian Contract is a document defining a type of value for issuance over the Internet . It identifies the Issuer, being the signatory, and any terms and clauses the Issuer sees fit to add in to make the document stand as a contract.
The same document has to be both readable by people and parsable by programs. The Ricardian Contract is formatted as a text file that can be easily read (displayed or printed), and programs can convert it into internal forms for searching for name-value pairs. It includes a special section for each type of contract, such as bond, share, currency, etc. Further sections within describe, in program-parsable terms, usage of decimal points, titles, and symbols.
As legal signatory, the Issuer signs the document in the OpenPGP cleartext form with his contract signing key . He includes the full chain of OpenPGP keys within the document to permit programs to directly verify and authenticate.
To uniquely identify the contract, any user can calculate a canonical message digest over the clearsigned document. This message digest is included in all records of transactions, and provides a secure (unforgeable) link from the document to the accounting of the issue.
E.g. e3b445c2a6d82df81ef46b54d386da23ce8f3775 is the full message digest for Systemics Inc's issue of prepaid services dollars. Commonly called a hash, the message digest is a cryptographic technique to create a relatively small number that is one to one with the document. That is, for each document, there is only one hash, and the hash refers uniquely to that document. The algorithm is the well-known standard, SHA1.
用最简单的术语来说，李嘉图合约是一种定义了通过互联网发行的价值类型的文件 [ 11 ]。它标识发行人、签署人以及发行人认为适合添加的任何条款和条款，从而让该文件成为合约。
相同的文档必须能够被人读取，并可以被程序解析。李嘉图合约被格式化为可轻松阅读（显示或打印）的文本文件，程序可将其转换为用于搜索名称 - 值对的内部表格。它包括每种类型合约的特殊部分，例如债券，股票，货币等。其他部分用程序可解析的术语描述小数点、标题和符号的用法。
作为法定签字人，发行人用其合约签署密钥以 OpenPGP 明文形式签署文件 [ 12 ]。他在文档中包含了完整的 OpenPGP 密钥链，以允许程序直接验证和认证。
例如， e3b445c2a6d82df81ef46b54d386da23ce8f3775 是 Systemics Inc 预付费服务美元的完整信息摘要。通常称为哈希，这种消息摘要是一种加密技术，用于创建一个相对较小的、与文档一对一的数字。也就是说，对于每个文档，只有一个哈希，并且该哈希只指向该文档。该算法SHA1是众所周知的标准。
3.2. Some Observations
The following observations highlight how strong the result is.
Hash Limits Frog-Boiling. A gradual change in contract by the stronger party over time is known as frog-boiling. The stronger party is generally the issuer, and can be expected to change the contract if there is a benefit. This is a frequent attack. One result of the use of the hash identifier is that neither party can change the contract arbitrarily or surreptitiously.
To see this is true, we need to examine the records that refer to the hash. An application can sign all important records (e.g., payments, tokens, receipts, balances), and these signed records include the hash of a Ricardian Contract. The hash within the record cannot be changed without losing its ability to pass a test of signature validity. Likewise, the contract cannot be changed without losing its relationship to records already signed and delivered. In other words, every record, held by every user, incorporates an unalterable copy of that hash. Any change to the contract creates a new hash, and that new hash is not the one which the users have or value.
This crystallises the contract for both parties, stopping the stronger party from modifying the contract subtly at some later stage. To some extent, this redresses the imbalance of power between provider and customer in the offering of a form contract. The lesser party has no option to negotiate, but neither has the greater party the option to claim a distinct contract at a later time. The limitation comes at some cost as it can be a nuisance for the support team of that financial instrument.
The Ricardian PKI Delivers Clarity. Ricardian Contracts carry their own Public Key Infrastructure ("PKI") with them. The Issuer's top level public key is included in the contract, and it signs his contract-signing key, also included. The contract-signing key signs the contract itself.
This achieves several things. Firstly, client software can check the entire digital signature chain in one automated sequence.
Secondly, there is no need for a complex multi-party PKI. All the keys are present, and there is no need to go looking for them on the net. This eliminates substitution attacks, whereby a key that might pass some checks could be inserted in some key lookup phase. It also reduces costs dramatically.
Thirdly, the canonical hash of the contract also represents a signature on the contract. It is recorded in all relevant records, and thus entangles the contract with those activities . Once the contract has been in play for a while, it establishes its provenance through presence and reliance by the user public. This provides far more persuasive evidence than the issuer's signature itself; once the issuer and the public have spent time and money relying on the contract, via the hash, it is hard for the issuer to renege on the nature of the contract or his signature.
The result is a PKI that delivers strong end-to-end reliability, based on a single document. This is simply not present in other designs for PKIs . This reliability pays off in the dispute resolution phase, where, we suggest, the Ricardian Contract can stand alone on its merits and requires no complex descriptions of PKI, digital signatures, or references to uncertain third parties to bolster its provenance. By including the keys, we can draw a couple of simple lines within the contract, asserting "this key signs that key, and that latter signs the contract. The first key is the top-level key of the individual that signed this contract. That's the whole story, mi'lud."
Validating the Issuer's Key. All good crypto protocols divide into two parts, the first of which says to the second, "trust this key completely."
The top-level key of the Issuer ultimately authenticates the contract. The keys and other information in the contract also permit a protocol such as SOX to bootstrap a strongly secured connection to the server .
How then to verify that this ultimate key is really the Issuer's? This is not difficult. The business process of digital issuance involves a great deal of relationship-building between Issuers and Users. Many different interactions involve chances to establish trust. For example, from his web site, the Issuer can publish the contract, keys and hashes, and have other sites mirror them. The value so issued will be distributed via payments that include the hash. An already trusted party usually delivers these payments. The payments validly identify the contract, and derive their own validity, via the hash.
Contrast this to assumptions in the x.509 PKI behind SSL/HTTPS browsing (the following is highly debatable, but is presented for comparison only). In that PKI, it was originally claimed that a user would present her credit card to sites with which she had no prior relationship and no way for her to establish the provenance of the site's key. Thus, a trusted third party, the Certificate Authority, was put in place to confirm the key.
Payments, trading and matters of finance are fundamentally relationship-rich. The nature of money and finance is that participants always conduct their own due diligence, they prefer to listen to peers they already trust, and do not readily accept the word of an independent party. Thus, there is no place for a central third party to stand in and authenticate players. Before the user desires to place any value on a given payment, she has almost certainly been made aware of the contract via other means.
Presumption of Possession. The use of the hash as an identifier is a compromise as it is unintelligible to humans . Yet this very compromise delivers an unexpected benefit: Use of the issue leads to a presumption that the user has the contract. To use an issue of value, such as a currency, the user must have the hash in the applicable records. That is, if the user receives a payment, that payment record will include the hash. As the hash is not descriptive, this implies that the user has the contract in order to interpret the issue.
To see that this is true, imagine having a record with the hash but without having the contract. The first thing the user will need is a database of parameters telling her what the hash refers to. Unlike a payment in 10 of "GBP", a payment of 1000 in "972097bb..." is not intelligible.
Yet how could software predict what the user needs to know about the hash? Very quickly it becomes apparent that the software is better off storing the source of the information - the full contract itself - as it removes an unlimited degree of complexity in storing intermediate or secondary information.
Software can still function with only the hash. However, it would be entirely blind to the semantics of the instrument. Such a cavalier approach might be acceptable for communications and storage, but for user software, it is equivalent to a traumatic failure. To cope with this, the client-side software takes especial care to acquire and keep contracts. Hence, we can state the presumption with some degree of confidence: in a functioning system, the user has available the full Ricardian Contract (albeit under software control).
This is only a small step for the client software, but is a giant leap forward for the relationship between the issuer and the holder. Specifically, having a strong presumption that the user has the full contract available will simplify many legal aspects about the issuer's responsibilities. (We suggest and thus acknowledge the legal ramifications of the term presumption, but neither space nor expertise permits more in this paper.)
李嘉图 PKI 提供清晰。 李嘉图合约带有自己的公钥基础设施（“PKI”）。发行人的顶级公钥包含在合约中，也包含签署了合约签名密钥。合约签字秘钥需要自己签署。
第三，合约的规范哈希也代表合约上的签名。它记录在所有相关记录中，从而使合约与这些活动相关联 [ 13 ]。一旦合约生效了一段时间，它就通过用户公众的存在和依赖来确定其来源。这比发行人的签名本身提供了更有说服力的证据; 一旦发行人和公众因为合约花费了时间和金钱，发行人很难通过哈希违背合约的性质或签名。
其结果是基于单个文档的 PKI 提供了强大的端到端可靠性，这在PKI的其他设计中根本不存在 [ 14 ]。这种可靠性在争议解决的阶段得到了回报，我们认为，李嘉图合约可以独立于其优点，不需要对 PKI、数字签名或对不确定第三方的引用进行复杂的描述以支持其来源。通过把秘钥包括在内，我们可以在合约中画出几条简单线条，断言：“这把秘钥签署着另一把秘钥，而后者签署合约，第一个秘钥是签署本合约的个人的最高秘钥。这就是故事的全部内容。"
发行人的最高级别密钥的最终验证合约中，密钥和其他信息也允许像 SOX 这样的协议将一个强安全连接发送到服务器[ 15 ]。
与 SSL / HTTPS 浏览背后的 x.509 PKI 假设相比（以下内容具有很大的争议性，但仅供比较），在该 PKI 中，它最初声称用户会将自己的信用卡出示给她之前没有任何关系的站点，并且无法确定该站点密钥的出处。因此，一个受信任的第三方，即证书颁发机构来确认密钥。
占有的推定。 哈希作为标识符的使用是一种妥协，因为人类无法理解 [ 16 ]。然而，这种妥协带来了意想不到的好处： 使用该问题会导致用户拥有合约的推定。 要使用价值发行物（如货币），用户必须在可应用的记录中包含哈希。也就是说，如果用户收到付款，该付款记录将包含哈希。由于哈希不是描述性的，这意味着用户拥有合约来解释问题。
为了证明这是真的，假设有一个没有合约的哈希记录，用户首先需要的是一个参数数据库，告诉她哈希是什么。与 10 英镑的“GBP”付款不同，“972097bb ...”中的 1000 付款不易理解。
3.3. The Four Corners of the Page
The Ricardian Contract delivers a rich source of primary, complete information. The full story is right there in textual form, in parsable parameters, and in the signature chain. Thus, within a dispute, a hostile legal attack has less room to manoeuvre, and can only confirm the facts as laid out in the contract.
Our intent is that the contract is the beginning and the end of the discussion; we call this principle the rule of one contract. The legal fraternity refers to "the contract being bounded by the four corners of the page." By showing how we have carefully laid out a readable document, with a verifiable digital signature, and an unforgeable identifier linking to every record, we can more readily ask the judiciary to accept that the single document which is being presented is indeed the valid contract agreed to by the parties.
我们的意图是，合约是讨论的开始和结束; 我们把这个原则称为一个合约的规则。法律是指“合约以页面的四个角落为界 ”。通过展示我们认真制定的一个可读文档，带有可验证的数字签名以及与每条记录链接的不可伪造的标识符，我们可以更容易要求司法部门接受所提交的单个文件确实是由各方同意的有效合约。
The contract is the keystone of issuance . Our innovation is to express all the salient details of an issuance as an unforgeable contract, unforgeably linked into every action within a payment system. In this way, financial innovation can develop along the lines it always has done - by means of innovation within contracts. By translating the institution of the contract into the digital domain, we build upon centuries' and even millenia' worth of experience in documenting, sharing and disputing the meaning of agreements between parties.
合约是发行的基石 [ 17 ]。我们的创新是将发行的所有重要细节表达为不可伪造的合约，不可避免地与支付系统内的每一个行动联系起来。通过这种方式，金融创新可以沿着它始终完成的路线发展——通过合约之内的创新。通过将合约制度转化为数字化领域，我们建立了几个世纪甚至千年的记录，分享和争论各方之间协议意义的经验。
4.1. The Challenge of Complexity
To capture complexity, we can put documents such as contracts into electronic form and sign them using digital signature technologies such as OpenPGP. The result is a reasonable analogue of the paper and ink contracts that most people and businesses are familiar with, bolstered with cryptographic integrity.
With the hash as the identifier, software can now uniquely identify a given financial arrangement and can confirm a strong chain of signatures. The hash strongly implies the user has the contract available at all times, and it cannot be changed without being noticed.
The Ricardian Contract delivers one huge benefit to the issuer - clarity in many legal and customer support questions. The user benefits from lower overall costs, and better presentation of information, within a more consistent framework.
为了捕捉复杂性，我们可以将合约等文档转换为电子格式，并使用 OpenPGP 等数字签名技术对其签名。其结果是大多数人和企业都熟悉的纸张和墨水合约的合理模拟，并具有密码完整性。
4.2. Lessons Learnt
The form has been in successful use since 1996. Since that time, it has delivered about 20 financial instruments without failure.
Disputes. The Ricardian Contract has appeared in two distinct forums of dispute resolution to resolve claims . Anecdotally, each claim was resolved directly and efficiently, and without undue fuss, simply by referring to the applicable Ricardian Contract.
Automation. Relatively little has needed to be automated. In practice, fields have been inserted and standardised so that programs can extract decimalisation (dollars versus cents), labels for units (USD versus $), and titles for the issuer and the issue. In contrast to expectations, there has been no demand to parse every field.
Cost. The cost of the concept has compared favourably with that incurred with other payment systems. The preparation of the contract text carries some costs, but no more so than a user agreement. OpenPGP infrastructure requirements (keys and signing) add some minor costs to issuers but they are easily offset by the benefits of risk reduction from contract distribution. Custom signing editors have helped to reduce those costs.
该表格自 1996 年以来一直在成功使用。至今，它已交付约20种金融工具而没有失败。
争议： 李嘉图合约出现在两个不同的争议解决论坛上以解决索赔 [ 18 ]。有趣的是，每一项索赔都是直接而有效地解决的，不需要太多的争执，只需参考适用的李嘉图合约即可。
成本： 这个概念的成本与其他支付系统的成本来说相对有利。合约文本的准备会带来一些成本，但不会超过用户协议。OpenPGP 基础设施要求（密钥和签名）为发行人增加了一些小的成本，但很容易被合约分配降低风险的好处所抵消。定制签名编辑有助于降低这些成本 [ 19 ]。
4.3. Challenges for the Future
Layering. Layering of contracts is an impending need. Many businesses can take a standard and defined set of terms and draw on them directly. Other contracts result from earlier contracts and need to reference them.
XML. Initial efforts suggested that XML would break the rule of one contract, but it seems that we will need something better than the archaic INI format . One recent proposal, the XML Voucher, stops short of presenting itself as a contract .
Law of Contract. The treatment of the Ricardian Contract as a contract may raise more legal questions than it answers. For example, is this form indeed a contract? How do distinct jurisidictions view the concept (common law, civil law, UCC, Koranic code)? Is this a negotiated or a form contract? When did the user accept the contract? How strong, or rebuttable, is the presumption that the user has the contract?
Smart Contracts. By unifying all information in a program-readable file, there is the enhanced potential of smart contracts . We have not gone further in this direction than methods to handle decimals. This is partly for lack of demand, and partly because it is not clear how a court would treat a computer program presented as a contract.
XML: 最初的努力表明，XML 将打破一个合约的规则，但似乎我们需要比陈旧的 INI 格式更好的东西 [ 20 ]。最近的一个提案，即 XML 凭证，并没有将自己作为一份合同呈现出来 [ 21 ]。
智能合约: 通过将所有信息统一到一个可编程的文件中，智能合约的潜力得到增强 [ 22 ]。在这方面，我们并没有比处理小数的方法更有进步。部分原因在于缺乏需求，或者是法院如何对待作为合约提交的计算机程序尚不清楚。
* Originally introduced in Ian Grigg, "Financial Cryptography in 7 Layers," 4th Conference on Financial Cryptography, Anguilla, 2000, Springer-Verlag LNCS 1962. All papers are at http://iang.org/papers/ *
* Ian Grigg, "Digital Trading," Virtual Finance Report, November 1997. *
* Country and Currency Codes, ISO3166-1. *
* Bryce Wilcox, open design review, DigiCash's developer list, firstname.lastname@example.org, August 1997. *
* Ibid, Rachel Willmer, 14 August 1997. *
* Robert Hettinga, " What's a Digital Bearer Bond?" e$ rants , 19th November, 1995 *
* Alex Tajirian, " David Bowie Bonds," *
* Ian Grigg and C. Petro, "Using Electronic Markets Achieve Efficient Task Distribution," 1st Conference on Financial Cryptography , Anguilla, 1997, Springer-Verlag LNCS 1318. *
* Noel Clarke, Guide to Eurobonds, The Economist Intelligence Unit, 1993. *
* FDIC General Counsel's Opinion No. 8; Stored Value Cards, Federal Register, August 2, 1996. Also see the (readable) Press Release entitled FDIC will Continue to rely on General Counsel Opinion rather than issue rules on Stored-Value Cards, 24 June 97. *
* Ian Grigg, Guide to Ricardian Contracts, WebFunds project. *
* Jon Callas, et al, "OpenPGP Message Format," Internet Draft, RFC2440bis (-10 draft). *
* Petros Maniatis, Mary Baker "Secure History Preservation through Timeline Entanglement" , 11th USENIX Security Symposium, San Francisco, USA. August 2002. *
* Jane K. Winn, " Couriers without Luggage" 49 South Carolina Law Review 739 (1998) *
* Gary Howland, "Development of an Open and Flexible Payment System" 1996. *
* Bryce Wilcox, "Names: Decentralized, Secure, Human-Meaningful: Choose Two", 2003 *
* Metaphor by Martin (Hasan) Bramwell. See "The Contract is the Keystone of Issuance," Financial Cryptography blog, 19th September 2003. *
* DigiGold v. Systemics, before the Supreme Court of Anguilla (2001), and thereafter referred to the American Arbitration Association (2002). *
* Edwin Woudt, ContractSignWizard, WebFunds project. *
* Erwin van der Koogh, "Ricardian Contracts in XML," (presented at) Edinburgh Financial Cryptography Engineering (EFCE-2), 2001. *
* Ko Fujimura and Masayuki Terada, XML Voucher: Generic Voucher Language, Internet Draft. *
 Nick Szabo, " The Idea of Smart Contracts," 1997.
本文原文链接为 http://iang.org/papers/ricardian_contract.html ，作者 Ian Grigg，初译Fred，校对 Lochaiching。
ps. 本文首发于 2018.4.15，简书。后来简书提示本文仅作者可见，遂迁移至此。https://www.jianshu.com/p/3b45c92e86af