区块链确定性，终止和隔离

Question

有一个矩阵可以比较确定性，终止和隔离参数的虚拟机（对于以太坊）和Docker（对于Hyperledger Fabric）。

此图像无法很好地捕获所有信息。例如，对于Hyperledger中的Determinism，它提出了合同开发的挑战，而不是Docker行为本身。

我很想知道，有哪些设计决策导致Hyperledger Fabric选择Docker作为容器而不是自己的VM？

Answer 1

在Hyperledger Fabric的早期，有很多关于如何最好地实施智能合约的讨论。各种贡献者一直致力于客户约定/他们自己的项目，并且发现EVM存在缺陷（这是有充分理由的，因为虽然EVM是图灵完整的操作代码，但它依赖于天然气和账户作为结构并且确实难以做到复杂的数据建模等）。

我们决定不尝试创建新的合同语言和执行语言，而是决定允许人们使用他们选择的编程语言的全部功能（今天Golang完全支持，Java是实验性的， JavaScript即将发布。）

现在为了允许多语言合同而不创建复杂的嵌入式解释器等，我们选择在进程外编译和运行链代码。然后，我们需要找到一种方法来“隔离”（并在一定程度上管理）这些外部流程，并且使用Docker似乎是一个非常可行的选择。

有几点需要注意：   - 链代码进程/容器仅与对等进程通信（即，它们启动与对等方的通信，并且不公开自己的端点）   - chaincode实际上将命令传递给对等体（即当你执行Get / Put状态时，实际上是通过安全的gRPC连接发送给对等体） - 对等体实际上管理/隔离来自其他调用的每个链代码调用（意味着一个调用不能从另一个调用访问任何状态） - Hyperledger Fabric本身提供了一种机制，通过这种机制，对等体的管理员必须实际安装链码（这是运行许可的区块链的好处）。因此，在实际安装任何链代码之前，对等方的管理员/所有者可以检查链代码并确保它没有做任何恶意的事情。

当谈到非决定论时，研究了一些事情。例如，我们已经查看了将各种语言的某些功能列入白名单。但最终，v1.0架构确保每个链代码调用的非确定性实际上并不需要。 在v1.0模型中，每个节点执行链代码，输出实际上是状态访问/更改的读/写集。如果成功执行了链码逻辑，则对等体然后签署响应。这称为模拟和认可。认可的数量（即必须成功运行链码的对等体）可通过策略配置。一旦为交易收集了足够的认可，它们就是包并提交给订购服务，然后订购服务创建有序交易块并将它们交付给同行进行验证和承诺。这个逻辑是100％确定性的（检查事务是否格式正确，确保有足够的认可来满足策略，并最终进行经典的MVCC检查以避免冲突（又称“双重支出”）。

希望这会有所帮助