Corda 核心概念 – Contracts

概要

  • 一个有效的 transaction 必须要被它的所有 input 和 output states中的 contract 接受
  • Contracts 需要使用 JVM 编程语言编写(java 或者 kotlin)
  • Contract 的执行是一定要有一个确定性结果的,并且它对于一个 transaction 的接受是仅仅基于 transaction 的内容

Transaction verification

一个 transaction 仅仅当被所有要求的签名方提供了签名之后才会被认为是有效的。但是,除了获得到所有人的签名之后,还必须要满足合约有效(contractually valid)才会被最终认为有效。

合约有效(Contractual validity)的定义包含以下几点:

  • 每个 state 都指向了一个合约(contract)
  • 一个合约(contract) 将一个 transaction 作为输入,并且介于合约的规则来声明一个 transaction 是否被人为是有效的
  • 一个 transaction 会在每个 input state 和每个 output state 都认为它是有效的情况下,才会被认为是有效的

我们可以用下图来描述这个关系:

Contract code 可以用任何的 JVM 语言编写,并且具有该语言的所有能力,包括:

  • 检查 inputs,outputs,commands 的数量,时间,和/或者 附件
  • 检查这些组件中的任何一个的内容
  • 循环一个结构,给变量赋值,调用方法,帮助函数等等
  • 将一些类似的 states 分组来验证(比如对于所有的现金 state 的组合定义一个规则)

一个 transaction 如果不是合约有效(contractually valid)的话,是不会被视为一个对账本的有效更新,也就不可能被提交至账本。通过这种方式,合约会通过定义规则来不断地更新 states 的状态,并且每次更新必须要获得所有相关的签名。

The contract sandbox

Transaction verification 必须是一个确定性的结果 – 一个 contract 必须或者总是接受,或者总是拒绝一个给定的 transaction。比如 transaction 是否有效不能够取决于你在什么时间做的 verify 或者是基于某一方具有的信息量的多少来决定是有效的还是无效的。这是一个很重要的条件来确保网络上的相关节点能够在这个对账本的更新的操作达成共识(consensus)。

为了实现这一点,contract 来判断 transaction 是否有效是在一个具有确定性结果的 sandbox 中进行的。这个 sandbox 有一个白名单(whitelist)能够用来防止引入一些会造成不确定性的外部库。这些库包括提供当前日期的,产生随机数的,提供访问系统文件的或者访问网络的。本质上来讲,当确认一个 transaction 的时候,contract 唯一具有的信息应该都是来自于 transaction 自身的信息,不应该引入除 transaction 意外的任何信息。

Contract 的限制(limitation)

因为 contract 没有办法访问到外语的信息,它只能检查 transaction 自身的有效性,比如它不能够检查确认当前这个 transaction 是不是已经同其他相关方达成了共识取得了其他方的确认。

所以在各方提供最终的签名确认之前,各方应该对transaction 的内容进行检查来确定他们是否同意这个对账本的更新,即使这个 transaction 是合约有效(conceptual valid)的。任何一方是不会因为 transaction 是 contractually valid 就能够去提供签名。比如他们可能不愿意去提供一个巨额的借款,或者可能不会同意购买一个资产花费的钱的金额,虽然这些能够正常地通过 contract code 的验证,即 contractually valid,但是还是不会去接收这个 transaction 的。

Oracles

有的时候 transaction validity 需要取决于一些外部的信息,比如兑换汇率。这种情况下就需要使用 oracle 了。

Legal pros

每一个合约也会引用一个 legal prose 文档,这个文档中定义了合约中规定的内容,legal prose 也会被传统的法律系统所接受。这个文档会在发生法律纠纷的时候被用来进行判定依据。