概要
- 一个有效的交易是一定有输入和输出状态的,可是怎么知道这个交易是否有呢?合约进行验证。
- 合约就是一段验证逻辑代码,这个代码是被JVM编程语言所编写的,比如Java或者Kotlin。
- 合约的执行的确切的。一个交易可被接收(有效的)是基于交易本身的内容的。
交易的验证
我们会想一个交易所涉及的所有参与者都进行了数字签名,那么这个交易是有效的。然而,事实并不是这样,只有合约是有效的这个交易必定有效。因为合约是一串验证逻辑(就是一串运作在JVM上的代码),它都验证通过,则交易必定有效。
合约的有效性定义如下:
- 每一个状态指向一个合约
- 合约是以交易作为输入的,而交易的有效性是基于合约的验证规则,而验证规则又是基于业务逻辑的
- 如果合约的每个输入状态和输出状态是有效的,则交易必定是有效的
我们可以捕获到如下场景:
合约代码可以被任何的JVM编程语言编写。并且这段代码拥有这门编程语言的”全部能力“。包括:
- 验证大量的输入,输出,命令(Commands),时间戳,附件(如果有的话)。
- 验证一个交易所涉及的所有组件(Input state, Output state, Commands, Attachment)的内容。
- 循环结构,变量分配,函数调用,帮助方法等。
- 把相似的状态分为一个组,并以组为单位进行验证。比如对所有的现金状态所关联的值设定一个规则。
如果一个交易的合约不是有效性的,那么这个交易是不应该被提议更新到账单的。用这种方式,合约暴露出状态随时间进化的规则,但是对于这个交易所涉及到的签名者,他们是否愿意签名则是独立于这个合约的。也就是合约你可以进行交易的签名者验证,就是验证需要哪些签名者,但是签名与不签名是这些签名者表达自己的意愿的。
合约沙箱
交易的验证一定是确定的,一个合约应该是这样的,要么总是接收一个交易,要么总是拒绝一个交易。比如,一个合约的有效性不是某个时间点确定是有效的,它就是有效的;一个合约的有效性也不是某个端(peer)运行着的合约持有大量信息,它就是有效的。因为一个很有必要的条件就是这个网络上的所有端(peer)都达成一致,都认为是有效的,才进行更新到账单。
为了实现这个,合约在一个确定的沙箱种评估交易。这个沙箱有一个白名单,阻止合约导入一些不确定的第三方源码库。这些库会提供当前时间,随机数产生。这些库提供文件系统访问或者网络库。最终,当合约验证交易时,它仅仅可以利用的信息就是交易它本身,而不是其他的信息。
合约限制
因为一个合约是不能访问外界信息的,所以它仅仅验证交易本身信息的有效性。比如,合约不能验证当前这个交易与原始参与方的一致性,因为某个具体的合约它接收的只是当前这个交易,根据验证规则,当前这个交易通过,则通过。
因此,端(peers)应该在签名一个交易之前就进行验证,即使这个交易是有效的,这个签名也是为了表达自己的意愿,是否同意把此交易更新到账单。一个端(peer)是没有义务签名一个交易的,仅仅因为它是合约有效性的。比如,他们可能不愿意贷一个大额的款,或者不同意一份资产所对应的现金数量。
这些都可以达成一致规则,写到合约中去。(有可能之前达成的一致协议,随着时间的流动,现实也在改变),又将如何应对?先知
先知(oracles)
有时候,交易的有效性是依赖于外部的信息的,比如交换率。在这样的情况下,一个先知就是必须的。
法律散文(Legal prose)
每一个合约也有一个合法的文档,这个文档陈述着状态规则,这些规则掌管着状态随时间流动的进化,这些规则也会与传统法律法律系统兼容。这个文档依赖法律争端场景。另一种表达方式:只要存在法律争端,则这个文档将会起作用。