将代码放在区块链上的方法不止一种
在有关区块链的大多数讨论中，很快就出现了“智能合约”的概念。 在普遍的想象中，智能合约可自动执行党内互动，而无需受信任的中介。 通过用代码而不是文字表达法律关系，他们承诺使交易能够直接进行而不会出错，无论是否经过深思熟虑。
从技术角度来看，智能合约更具体：存在于区块链上并定义该链交易规则的计算机代码。 这种描述听起来很简单，但其背后隐藏着这些规则的表达、执行和验证方式的大量变化。 在为新应用程序选择区块链平台时，“这个平台是否支持智能合约？”的问题不适合问。 相反，我们需要问：“这个平台支持什么类型的智能合约？”
在本文中，我的目标是研究智能合约方法与它们所代表的取舍之间的一些主要差异。 我将通过研究四个流行的企业区块链平台来做到这一点，这些平台支持某种形式的自定义链上代码。 首先，IBM的 超重织物，将其合同称为“链码”。 其次，我们的MultiChain平台 智能过滤器 在2.0版中。 第三， 以太坊 （及其许可 法定人数 和 地洞 衍生产品），从而普及了“智能合约”的名称。 最后， R3 Corda，在其交易中引用“合同”。 尽管有所有不同的术语，但最终所有这些都指向同一事物-定义链规则的特定于应用程序的代码。
在继续之前，我应该警告读者，以下许多内容本质上是技术性的，并且假定您已熟悉一般的编程和数据库概念。 无论好坏，这都是无法避免的–如果不深入细节，就无法就是否为特定项目使用区块链以及（如果使用）正确的区块链类型做出明智的决定。
区块链基础
让我们从一些背景开始。 想象一个由多个组织共享的基于基础数据库的应用程序。 在传统的集中式体系结构中，该数据库由单个参与者托管和管理，即使所有参与者彼此都不信任，也可以信任所有参与者。 经常响应于从参与者收到的消息，仅由该中央方系统上的应用程序启动修改数据库的事务。 数据库只是按照告知的方式进行操作，因为应用程序被隐式信任，仅向其发送有意义的事务。
区块链提供了一种无需信任的中介机构即可管理共享数据库的替代方法。 在区块链中，每个参与者运行一个“节点”，该节点保存数据库的副本并独立处理修改数据库的交易。 使用公共密钥或“地址”识别参与者，每个公共密钥或“地址”具有仅身份所有者已知的对应私钥。 尽管可以由任何节点创建事务，但是它们通过其发起者的私钥进行“数字签名”，以证明其来源。
节点以点对点的方式相互连接，在网络中快速传播事务和时间戳，并在其中进行“确认”。 区块链本身实际上就是这些区块链，形成了每个历史交易的有序日志。 “共识算法”用于确保所有节点都对区块链的内容达成共识，而无需集中控制。 （请注意，此描述中的某些内容不适用于Corda，在Corda中，每个节点只有一部分数据库副本，并且没有全局区块链。稍后我们将详细讨论。）
原则上，任何共享数据库应用程序都可以通过在其核心使用区块链来构建。 但是这样做会带来一些集中式方案中不存在的技术挑战：
- 交易规则。 如果有任何参与者可以直接更改数据库，我们如何确保他们遵循应用程序的规则？ 是什么阻止一个用户以自服务方式破坏数据库的内容？
- 确定性。 一旦定义了这些规则，在为自己的数据库副本处理事务时，多个节点将多次应用这些规则。 我们如何确保每个节点获得完全相同的结果？
- 预防冲突。 在没有中央协调的情况下，我们如何处理两个都遵循应用程序规则但又相互冲突的事务？ 冲突可能源于蓄意尝试对系统进行游戏，也可能是运气和时机的无辜结果。
那么智能合约，智能过滤器和链码从何而来呢？ 他们的核心目的是与区块链的基础架构合作，以解决这些挑战。 智能合约是应用程序代码的去中心化等价物-它们不是在一个中央位置运行，而是在区块链中的多个节点上运行，创建或验证修改该数据库内容的交易。
让我们从交易规则开始，这是这些挑战中的第一个，然后看看它们如何分别在Fabric，MultiChain，Ethereum和Corda中表达。
交易规则
交易规则在由区块链支持的数据库中执行特定功能-限制 转换 可以在该数据库的状态上执行。 这是必要的，因为区块链的交易可以由其任何参与者发起，并且这些参与者彼此之间并不足够信任，无法让他们随意修改数据库。
让我们看两个为什么需要交易规则的例子。 首先，想象一下一个区块链，该区块链旨在聚合和加盖参与者发布的PDF文档的时间戳。 在这种情况下，任何人都无权删除或更改文档，因为这样做会破坏系统的整个目的，即文档持久性。 其次，考虑代表共享财务分类帐的区块链，该区块链跟踪其用户的余额。 我们不能允许参与者任意增加自己的余额或带走他人的钱。
输入和输出
我们的区块链平台依靠两种广泛的方法来表达交易规则。 第一个我称为“输入-输出模型”，用于MultiChain和Corda。 在这里，事务显式列出它们删除和创建的数据库行或“状态”，分别形成一组“输入”和“输出”。 修改一行表示为删除该行并在其位置创建一个新行的等效操作。
由于数据库行仅在输入中删除，而仅在输出中创建，因此每个输入都必须“花费”先前事务的输出。 数据库的当前状态被定义为“未使用的交易输出”或“ UTXO”的集合，即以前尚未使用的交易的输出。 事务还可能包含称为“元数据”，“命令”或“附件”的其他信息，这些信息不会成为数据库的一部分，但有助于定义其含义或目的。
给定这三组输入，输出和元数据，MultiChain或Corda中事务的有效性由一些代码定义，这些代码可以对这些集合执行任意计算。 该代码可以验证交易，或者返回带有相应说明的错误。 您可以将输入输出模型视为持有清单的自动化“检查员”，以确保交易遵循每条规则。 如果交易未通过其中任何一项检查，它将被网络中的所有节点自动拒绝。
应该指出的是，尽管共享了输入输出模型，但MultiChain和Corda的实现方式却大不相同。 在MultiChain中，输出可以包含JSON，文本或二进制格式的资产和/或数据。 规则在“事务过滤器”或“流过滤器”中定义，可以将其设置为检查所有交易，或仅检查涉及特定资产或数据分组的交易。 相比之下，Corda输出的“状态”由Java或Kotlin编程语言中的对象表示，带有已定义的数据字段。 Corda的规则在附于特定州的“合同”中定义，州合同仅适用于在其输入或输出中包含该州的交易。 这与科尔达的 异常可见度模型，其中交易只能由其交易对手或他们影响其后续交易的交易者查看。
合同和讯息
第二种方法，我称为“合同消息模型”，用于Hyperledger Fabric和以太坊。 在这里，可以在区块链上创建多个“智能合约”或“链码”，每个都有自己的数据库和关联的代码。 合同的数据库只能通过其代码进行修改，而不能直接通过区块链交易进行修改。 这种设计模式类似于面向对象编程中的代码和数据“封装”。
在这种模型下，区块链交易从一条发送到合同的消息开始，带有一些可选参数或数据。 合同的代码是对消息和参数的响应而执行的，并且可以自由地读写自己的数据库作为响应的一部分。 合同也可以将消息发送到其他合同，但不能直接访问彼此的数据库。 用关系数据库的语言，合同充当 强制执行 “存储过程”，其中对数据库的所有访问都通过一些预定义的代码进行。
Fabric和Quorum是以太坊的一种变体，它通过允许网络定义多个“通道”或“私有状态”，使此图复杂化。 目的是通过创建单独的环境来缓解区块链机密性问题，每个环境仅对特定的参与者子组可见。 尽管从理论上讲这听起来很有希望，但实际上每个渠道或私有国家中的合同和数据都与其他渠道或私有国家中的合同和数据是隔离的。 结果，就智能合约而言，这些环境相当于单独的区块链。
规则范例
让我们看看如何使用这两种模型为单资产财务分类账实施交易规则。 分类帐数据库中的每一行都有两列，分别包含所有者的地址和所拥有资产的数量。 在投入产出模型中，交易必须满足两个条件：
- 交易输出中的资产总数必须与其输入中的总数相匹配。 这样可以防止用户随意创建或删除钱。
- 每个交易都必须由其每个输入的所有者签名。 这样可以防止用户未经允许而花费对方的钱。
综上所述，这两个条件是创建简单但可行的金融系统所需要的。
在合同消息模型中，资产合同支持“发送付款”消息，该消息带有三个参数：发件人的地址，收件人的地址和要发送的数量。 作为响应，合同执行以下四个步骤：
- 验证交易是否由发件人签名。
- 检查发件人是否有足够的资金。
- 从发件人行中扣除请求的数量。
- 将该数量添加到收件人的行。
如果前两个步骤中的任何一项检查均失败，则合同将中止并且不会付款。
因此，输入-输出模型和合同-消息模型都是定义事务规则和保持共享数据库安全的有效方法。 实际上，从理论上讲，这些模型中的每一个都可以用来模拟另一个模型。 但是，实际上，最合适的模型将取决于正在构建的应用程序。 每笔交易会影响很少或很多信息吗？ 我们是否需要能够保证交易独立性？ 每个数据都有明确的所有者吗？或者是否有一些全局状态要共享？
探索答案如何影响这两种模型之间的选择超出了我们的讨论范围。 但是作为一般准则，在开发新的区块链应用程序时，值得尝试以两种形式表示其交易规则，并看一看是否更自然。 这种差异将在以下方面表现出来：（a）编程的简易性，（b）存储要求和吞吐量，以及（c）冲突检测的速度。 稍后我们将详细讨论最后一个问题。
内置规则
说到交易规则，MultiChain与Fabric，以太坊和Corda有一种特别的区别。 与其他平台不同，MultiChain具有多个内置抽象，这些抽象为区块链驱动的应用程序提供了一些基本构建块，而无需 要求 开发人员编写自己的代码。 这些抽象涵盖了通常需要的三个领域：（a）动态权限，（b）可转让资产和（c）数据存储。
例如，MultiChain管理用于连接到网络，发送和接收事务，创建资产或流或控制其他用户的权限的权限。 可以安全，原子地发行，转移，退役或交换多种可替代资产。 可以在链上创建任意数量的“流”，以发布，索引和检索JSON，文本或二进制格式的链上或链下数据。 这些抽象的所有事务处理规则都是现成可用的。
在MultiChain上开发应用程序时，可以忽略此内置功能，而仅使用智能过滤器来表示交易规则。 但是，智能过滤器旨在通过将其默认行为设置为可与内置抽象功能一起使用 受限 以定制的方式。 例如，某些活动的权限可能由特定管理员控制，而不是由任何管理员执行的默认行为控制。 某些资产的转移可能会受到时间的限制，或者需要一定数量以上的额外批准。 可以验证特定流中的数据，以确保它仅由具有必需字段和值的JSON结构组成。
在所有这些情况下，智能筛选器都会为要验证的交易创建其他要求，但不会 去掉 这是内置的简单规则。这可以帮助解决区块链应用程序中的关键挑战之一：某些链上代码中的错误可能导致灾难性后果。 我们已经在以太坊公共区块链中看到了无尽的例子，最著名的是 DAO的灭亡 和 奇偶校验多重签名错误. 更广泛的调查 在以太坊智能合约中发现了大量常见漏洞，攻击者可以利用这些漏洞窃取或冻结其他人的资金。
当然，MultiChain智能过滤器也可能包含错误，但是其后果在范围上更加有限。 例如，内置的资产规则可防止一个用户花掉他人的钱，或不小心使自己的钱消失，无论智能过滤器包含什么其他逻辑。 如果在智能过滤器中发现错误，则可以将其停用并用更正的版本替换，同时保护分类帐的基本完整性。 从哲学上讲，MultiChain更接近于传统的数据库体系结构，在传统的数据库体系结构中，数据库平台提供了许多内置的抽象，例如列，表，索引和约束。 在实际需要时，应用程序开发人员可以选择编码更强大的功能，例如触发器和存储过程。
| 交易规则 | 面料 | 多链 | 以太坊 | 科尔达 |
|---|---|---|---|---|
| 型号 | 合同消息 | 输入输出 | 合同消息 | 输入输出 |
| 内建 | 不包含 | 权限+ 资产+流 |
不包含 | 不包含 |
确定性
让我们继续对决的下一部分。 无论我们选择哪种方法，区块链应用程序的自定义交易规则都表示为应用程序开发人员编写的计算机代码。 与集中式应用程序不同，此代码将多次执行，并且每个事务在多个位置执行。 这是因为属于不同参与者的多个区块链节点必须各自验证和/或执行该交易。
这种重复和冗余的代码执行引入了在集中式应用程序中很少发现的新要求：确定性。 在计算的上下文中，确定性意味着无论在何时何地运行，一段代码对于相同的参数始终会给出相同的答案。 这对于与区块链交互的代码至关重要，因为如果没有确定性，该链上节点之间的共识可能会灾难性地崩溃。
让我们首先在输入输出模型中看一下实际情况。 如果两个节点对交易是否有效持有不同意见，则一个节点将接受包含该交易的块，而另一个节点则无效。 由于每个块都明确链接回上一个块，因此这将在网络中创建一个永久性的“叉子”，从那时起，一个或多个节点不接受有关整个区块链内容的多数意见。 少数节点将被从数据库的演进状态中切断，并且将不再能够有效使用该应用程序。
现在，让我们看看如果合同消息模型中的共识破裂，会发生什么。 如果两个节点对合同应如何响应特定消息有不同意见，则可能导致其数据库内容不同。 反过来，这可能会影响合同对未来消息的响应，包括它发送给其他合同的消息。 最终结果是，不同节点对数据库状态的看法之间的分歧越来越大。 （以太坊区块中的“状态根”字段可确保合同响应中的任何差异都立即导致完全灾难性的区块链分叉，而不是冒一段时间内被隐藏的风险。）
非确定性的根源
因此，区块链代码中的不确定性显然是一个问题。 但是，如果诸如算术之类的基本计算基础是确定性的，那么我们要担心什么呢？ 好吧，事实证明，很多事情：
- 最明显的是，随机数生成器，因为根据定义，它们被设计成每次都会产生不同的结果。
- 检查当前时间，因为节点不会在完全相同的时间处理事务，并且在任何情况下它们的时钟都可能不同步。 （仍然有可能通过参考区块链本身中的时间戳来实现与时间有关的规则。）
- 查询外部资源，例如Internet，磁盘文件或计算机上运行的其他程序。 无法保证这些资源总是给出相同的响应，并且可能变得不可用。
- 在并行“线程”中运行多段代码，因为这会导致“竞态条件”，在竞态条件中无法预测这些进程的完成顺序。
- 执行任何浮点计算，即使在不同的计算机处理器体系结构上，也可以给出微小的不同答案。
我们的四个区块链平台采用了几种不同的方法来避免这些陷阱。
确定性执行
让我们从以太坊开始，因为它的方法是最“纯粹”的。 以太坊合约以一种特殊用途的格式表示，称为“以太坊字节码”，由以太坊虚拟机（“ EVM”）执行。 程序员不会直接编写字节码，而是从称为Solidity的类似于JavaScript的编程语言生成或“编译”字节码。 （其他语言曾经可用，但是自那以后就已弃用。）确定性是由Solidity和以太坊字节码不能对任何不确定性操作进行编码的事实来保证的-就是这么简单。
通过适应现有的编程语言和运行时环境，MultiChain筛选器和Corda合同选择了不同的方法。 MultiChain使用在Google的 V8 引擎，该引擎也构成了Chrome浏览器和Node.js平台的核心，但是禁用了不确定性来源。 同样，Corda使用Java或 科特林，两者都被编译为在Java虚拟机（“ JVM”）中执行的“ Java字节码”。 目前，Corda使用Oracle的标准非确定性JVM，但正在进行整合一个 确定性版本。 同时，Corda合同开发人员必须注意不要在其代码中使用不确定性。
以太坊的纯粹主义与MultiChain和Corda采取的进化方法相比如何？ 以太坊的主要优势是将风险最小化–专用虚拟机不太可能包含无确定性来源。 尽管任何此类监督都可以通过软件更新来解决，但对于任何不幸遇到的链条来说，这都是破坏性的。 然而，以太坊的问题在于，在更广泛的编程语言和运行时环境中，Solidity和EVM构成了一个很小的新生生态系统。 相比之下，JavaScript和Java是 Github上的前两种语言可以在数十亿台数字设备上运行，并且运行时间经过数十年的优化。 大概这就是为什么公共以太坊区块链正在考虑过渡到 eWASM，这是新兴的WebAssembly标准的确定性分支。
通过认可的确定性
在确定性方面，Hyperledger Fabric采用了完全不同的方法。 在Fabric中，当“客户端”节点想要将消息发送到某些链码时，它将首先将该消息发送到某些“背书者”节点。 这些节点中的每一个都独立执行链代码，从而形成消息的观点 效果 在该chaincode的数据库上。 这些意见连同构成正式“认可”的数字签名一起发送回客户。 如果客户收到了预期结果的足够认可，它将创建一个包含这些认可的交易，并将其广播以包含在链中。
为了保证确定性，每条链码都有一个“背书政策”，该政策明确定义了使交易有效所需的批准级别。 例如，一个链码的政策可能规定，至少要有一半的区块链节点需要背书。 另一个可能需要三个受信方之一的认可。 无论哪种方式，每个节点都可以独立检查是否收到了必要的认可。
为了澄清差异，大多数区块链平台中的确定性基于以下问题：“在此数据上运行此代码的结果是什么？” –并且我们必须绝对确保每个节点都将同样回答该问题。 相比之下，Fabric中的确定性基于一个不同的问题：“是否有足够的认可者同意在此数据上运行此代码的结果？” 回答这个问题很简单，而且没有确定性的余地。
Fabric的认可决定有许多有趣的结果。 首先，链码可以用许多不同的编程语言编写，因为这些代码不需要针对确定性进行修改（当前支持Go，Java和JavaScript）。 其次，链码可以对某些区块链参与者隐藏，因为它只需要由客户和背书人执行（数据库本身是全局可见的）。 最后，也是最值得注意的是，Fabric链码可以执行其他区块链环境中禁止的操作，例如使用在线Web API检查天气。 在最坏的情况下，每个背书人都从此API获得不同的答案，客户端将无法获得足够的背书以实现任何特定结果，并且不会进行任何交易。 （应注意，Fabric团队成员仍然 建议 为了避免意外，在chaincode中使用确定性逻辑。）
Fabric为这种灵活性支付了什么价格？ 如果区块链的目的是从共享的数据库驱动的应用程序中删除中介，那么Fabric对代言人的依赖就大大超出了这一目标。 对于链中的参与者来说，仅遵守链代码的规则已不再足够-他们还需要某些其他节点来同意这样做。 更糟糕的是，背书的恶意子集可能会批准根本不遵循链码的数据库更改。 与常规区块链中的验证者相比，这可以给认可者更大的权力，后者可以审查交易，但不能违反区块链的规则。 区块链应用程序开发人员必须决定这种折衷在他们的特定情况下是否有意义。
| 确定性 | 面料 | 多链 | 以太坊 | 科尔达 |
|---|---|---|---|---|
| 型号 | 代言 | 适应的运行时 | 专用VM | 适应的运行时 |
| 语言 | 围棋 + Java + JavaScript | JavaScript的 | 密实度 | Java + 科特林 |
| 代码可见性 | 交易对手+ 背书人 |
全面、 | 全面、 | 交易对手+ 家属 |
| 强制执行 | 没有 | Yes | Yes | 否（目前） |
预防冲突
到目前为止，我们已经讨论了不同的区块链平台如何在代码中表达交易规则，以及它们如何确定性地确保每个节点都相同地应用这些规则。 现在是时候讨论我们的对决的第三方面：每个平台如何处理两个本身有效的交易彼此冲突的可能性？ 在最简单的示例中，假设Alice的财务分类帐中有10美元，并广播了两次交易-一笔向Bob寄出8美元，另一笔向Charlie寄出7美元。 显然，这些交易中只有一项可以被允许成功。
两种型号
我们可以通过将MultiChain和Corda的方法组合在一起来开始这个问题。 如前所述，这两种方法都使用输入-输出模型来表示事务及其规则，其中每个事务输入都花费前一个事务输出。 这导致了一个防止冲突的简单原理：每个输出只能使用一次。 MultiChain过滤器和Corda合同可以依靠各自的平台来绝对实施此限制。 由于Alice的10美元是由先前的交易输出代表的，因此该单笔支出规则会自动停止将其发送给Bob和Charlie。
尽管有相似之处，但重要的是要指出在MultiChain和Corda如何防止冲突方面的关键区别。 在MultiChain中，每个节点都可以看到每个事务，因此可以独立地验证每个输出仅花费一次。 任何针对先前确认的交易执行双花的交易将被立即自动拒绝。 相比之下，在Corda中没有全球性的区块链，因此需要“公证人”来防止这些双重花费。 每个Corda输出状态都分配给一个公证人，该公证人必须签署该输出的任何交易支出，以确认该支出之前没有被支出。 区块链的参与者必须信任公证人才能诚实地遵守该规则，恶意公证人会随意造成破坏。 与Fabric的认可一样，“单项支出即服务设计在保密性方面具有优势，但会重新引入中介机构，这与区块链背道而驰。 （重要的是要澄清，Corda公证可以由一组参与者使用共识算法来运行，因此仍可以保护分类帐的完整性免受个别不良行为者的侵害）。
让我们继续以太坊。 回想一下，以太坊使用合同和消息，而不是输入和输出。 结果，区块链引擎无法立即看到诸如Alice的两次付款之类的交易冲突。 相反，它们会被检测并阻止 合同 在链上确认订单后，由哪个处理交易。 在处理爱丽丝的每笔付款时，合同都会验证她的余额是否足够。 如果首先向Bob支付了$ 8的交易，则交易将照常进行，从而使Alice的帐户中剩下$ 2。 结果，当合同处理向Charlie支付$ 7的第二笔交易时，它发现Alice缺少必要的资金，交易中止。
产出与合同
到目前为止，我们已经看到了两种防止交易冲突的技术-MultiChain和Corda中的单笔支出输出以及以太坊中的基于合同的验证。 那么哪个更好呢？
为了帮助回答这个问题，让我们考虑一个示例“ 1-of 2 multisignature”帐户，该帐户代表Gavin和Helen持有100美元，并允许他们两个人单独花钱。 加文指示他的申请向唐娜支付80美元，几秒钟后，海伦想向爱德华寄40美元。 由于两次付款都没有足够的资金，因此这些交易将不可避免地发生冲突。 如果两个交易都被广播，则结果将由首先进入链中的任何一个来确定。 请注意，与Alice的示例不同，此冲突是 偶然，因为没有人试图破坏应用程序的规则–他们只是不幸的时机。
在考虑发生这种冲突的可能性时，关键问题是：加文发出交易之后，海伦的节点要花多长时间才能知道她的付款可能失败？ 该时间段越短，Helen越有可能被阻止尝试付款，从而使她和她的申请免于随后的意外。
使用输入-输出模型，交易之间的任何冲突对于区块链平台都是直接可见的，因为这两个交易将明确地尝试花费相同的先前输出。 在MultiChain中，这通常在Gavin的交易传播到Helen的节点后立即发生，通常在几秒钟或更短的时间内。 在Corda中，输出的公证人将拒绝签署Helen的交易的请求，因为它已经签署了Gavin的交易，因此Helen会立即知道她的付款将失败。 （尽管Corda公证人本身是分发的，但她可能不得不等待几秒钟才能得到答复。）不管哪种方式，都无需等待交易在区块链中得到确认和订购。
以太坊的模型呢？ 在这种情况下，区块链平台无法立即知道会发生冲突。 虽然Helen的节点可能会在网络上看到Gavin的交易，但它不知道这将如何影响Helen的交易，因为从其角度来看，这只是发送到同一合同的两条消息。 大概十秒钟后，一旦在区块链上确认了冲突交易的最终顺序，Helen的节点将重新计算实际值，而不是预期结果，并且她的应用程序将相应地更新其显示。 同时，加文（Gavin）和海伦（Helen）都将处于黑暗之中。
但是，我们不应由此得出结论，即输入输出模型始终可以发挥最佳作用。 考虑我们的示例方案的一种变体，在这种情况下，Gavin和Helen都在同一时间从原来的$ 40要求较小的$ 100付款。 在输入输出模型中，这些事务将发生冲突，因为它们都在包含100美元的同一数据库行上花费，并且只有一笔付款会成功。 但是在以太坊中，无论交易的最终顺序如何，这两项交易都将被成功处理，因为该账户中有足够的资金来进行交易。 在这种情况下，以太坊更加忠实地实现了加文和海伦的意图。
读写集
最后，让我们谈谈Fabric，其基于认可的方法是这两种技术的混合。 如前所述，当结构“客户端”节点要向合同发送消息时，它首先要求一些背书节点代表其执行该消息。 背书节点的执行方式与以太坊类似（对本地数据库运行合同），但是观察到的过程并非立即进行。 每个背书者都会记录将要读取和写入的行集，并同时注意这些行的确切版本。 版本化行的“读写集”在背书中明确引用，并包含在客户端广播的事务中。
一旦在链中确定了Fabric事务之间的冲突，便解决了它们之间的冲突。 每个节点独立处理每个事务，检查背书策略并应用指定的数据库更改。 但是，如果事务读取或写入已被前一个事务修改的数据库行版本，则该第二个事务将被忽略。 回到Alice对Bob和Charlie的付款有冲突的情况，这两个交易都将读取并修改相同的行版本，其中包含Alice开始使用的10美元。 因此，第二笔交易将安全且自动中止。
Fabric解决冲突的方法效果很好，但是就性能和灵活性而言，它结合了前两种模型中最差的一种。 由于代言将交易转换成特定的读写集，因此加文和海伦同时但兼容的40美元付款将导致以太坊避免的冲突。 但是，Fabric无法获得输入输出模型的速度优势，因为背书人针对区块链确认的数据库的最新版本执行合同，而忽略了未确认的交易。 因此，如果海伦（Helen）在加文（Gavin）之后几秒内开始付款，但在加文（Gavin）在区块链上得到确认之前，Fabric将创建冲突的交易，而纯输入输出模型可以避免这种交易。
| 预防冲突 | 面料 | 多链 | 以太坊 | 科尔达 |
|---|---|---|---|---|
| 型号 | 读写集 | 单笔消费 | 合同检查 | 单笔消费 |
| 企业验证 | 独立 (Independent) | 独立 (Independent) | 独立 (Independent) | 值得信赖的公证人 |
| 迅速的 | 〜10s（确认） | 〜1s（传播） | 〜10s（确认） | 0〜5s（公证） |
一个复杂的选择
在本文中，我们回顾了Corda，以太坊，Fabric和MultiChain解决“智能合约”或嵌入在区块链中的应用程序代码的主要挑战的许多不同方式。 每个平台对我们的三个核心问题都有不同的答案：交易规则如何表示？ 如何确定性地执行代码？ 以及我们如何防止冲突？
那么谁是我们智能合约摊牌的赢家？ 到目前为止，还没有一个简单的答案应该很明显。 每个平台都代表了灵活性，简单性，性能，非中介性，安全性和机密性之间的复杂多方折衷。 因此，为特定应用程序选择平台时，必须先详细了解该应用程序的信任模型，所涉及的交易类型及其可能的冲突方式。 如果您发现有人在推销特定的智能合约解决方案之前还不知道这些问题的答案，那么我建议您礼貌而坚定地坚持他们采用“更智能”的方法。
请发表任何评论 在LinkedIn.
