考虑 Scalar DLT 的架构 – 从与 Hyperledger Fabric 的比较角度出发

在本文中，我們將通過研究網絡上的設計文檔和與開發人員的訪談，探討Scalar公司正在開發的分散賬本軟件Scalar DLT的架構，並從與開放源碼區塊鏈基礎架構Hyperledger Fabric的比較角度進行考察。如果有任何錯誤，請聯繫開發人員或Scalar公司以獲取確切的信息。

关于标量DLT（Scalar DLT）

引用以下官方网页对于Scalar DLT的说明。

Scalar DLT由分散数据库软件Scalar DB和分布式分类账软件Scalar DL组成。它以分布式事务的形式执行带有电子签名的智能合约，并通过在多个独立组件中链式管理执行结果，具有高度抗篡改性。同时，它实现了传统区块链难以实现的高可扩展性、强一致性和确定性。

由于Scalar DLT的Sandbox使用方法和智能合约编写方式已经有了下面的文章，因此建议您参考那里的内容。

• 分散型台帳ソフトウェアScalar DLのSandbox環境を試してみた

分散型台帳 Scalar DLT のスマートコントラクトの書き方を調べてみた

设计理念

虽然Fabric专注于采用共享账本的联盟式结构，在多个公司之间共享账本，而Scalar DLT基本上专注于由一个或少数公司的节点群和其审计节点群组成的结构。因此，正如下面将要提到的那样，尽管它们看起来很相似，但两种架构在根本上是不同的。

架构概述

Scalar DLT分为以下三个层级。

• Client SDK

• Ordering

Ledger

最底层的账本是执行智能合约并管理账本数据的组件。在内部的事务处理中，使用了可作为开源软件广泛可用的 Scalar DB。多个节点组成了账本集群，并可以根据需要进行扩展。此外，还在 Scalar DB 上构建了多个哈希链结构，似乎即使仅有单一账本也具备一定的防篡改性。

中间层的Ordering的作用是以确定的顺序将智能合约（带有签名的业务逻辑）的执行请求排列起来，以便多个独立的Ledger集群组织可以按照相同的顺序接收到这些请求。它类似于Fabric中的Orderer，但不同于所谓的区块链，它不会像Fabric那样生成区块，只负责排序而已。

最高层次的Client SDK是一个带有与Ordering和Ledger交互接口的Java库。

我尝试将各个组件进行图示化。

要点在于多个账本（集群）相互独立且不相互通信，通过比较多个账本的状态来检测篡改的机制。此外，每个账本都有主处理集群和其他审计节点（集群）来分别承担不同的角色，这也是其特点之一。通常的节点构成是主集群数量为3至100个以上，而审计节点集群数量为1至3台。

改变对于合意形成的观点

Scalar DLT采用了称为Decoupled Consensus的方法（正在申请专利），其特点是执行阶段和验证阶段被分离（即解耦）。与Hyperledger Fabric通过合同（交易）的虚拟执行和背书在提交前达成针对未被篡改的一致（即检测篡改）相比，Scalar DLT通过比较多个账本的结果来进行篡改检测，这是其独特之处。我认为这是基于设计理念的架构上的重大差异。Scalar DLT似乎通过这种方式实现了性能可扩展性，即在提交后对篡改进行验证，这意味着在验证之前，每个账本可以独立执行合同。例如，合同执行可以通过增加主账本集群节点数量来快速进行，而篡改验证可以在包括审计用的小型账本集群在内的所有账本中使用执行完成时的数据进行。然而，与此同时，我认为这也是Scalar DLT无法像Fabric一样实时检测篡改的缺点。

在Fabric中，由于客户端必须根据背书政策从每个组织的对等节点收集背书，为了扩展性能，必须增加每个组织内的对等节点数。根据背书政策的不同，如果需要所有组织的背书，那么所有组织都必须以相同的方式扩展，这在运营和成本方面都是困难的。然而，与此同时，区块链具有即时检测篡改的能力，如果数据被篡改，可以在下一次处理时检测到篡改。

订购

Scalar DLT的Ordering组件选择了Kafka，从可靠性和性能的角度考虑，并假设具备故障容错性（CFT）。然而，Ordering组件只是确保了带有电子签名合约的执行请求的顺序一致，并且实际上只能做到拒绝接收请求的程度，而且这也可以由客户端进行检测。

一方，Fabric计划在将来的版本中引入具有拜占庭容错性(BFT)的共识算法于Orderer。作为前期阶段，我们在v1.4.1中支持了Raft。尽管Raft也属于CFT，但据说其可插拔性实际上与Kafka紧密结合的Orderer存在一定矛盾，这也是为了重新架构Orderer。此外，通过Raft的支持，现在可以在多个组织中以非集中式的方式操作Orderer，而不再仅限于一个组织。

对于这样的订购服务，是否应该在考虑到拜占庭故障的情况下进行非中央集权运营，这取决于预设的（区块链）网络以及有争议的问题。然而，个人认为，关于处理顺序的共识，在由正当的企业共同运营的联盟网络中，如果采用CFT机制就足够了，并且可以监视、审计和检测到篡改和不正行为，这样就足够好了。

合同执行处理

据说Scalar DLT采用了一项名为Partial-order-aware Execution的技术（据称该技术正在申请专利），以提高合同执行（交易）处理的性能。它动态地检测合同之间的依赖关系，并进行并行执行。

在版本1.0中，Fabric引入了Endorsement-Ordering-Validation模型，并通过并行进行合同的临时执行/模拟来提高性能。然而，正如之前写的文章中提到的那样，在验证阶段仍然是串行的，因此无法完全并行执行，这可能成为一个瓶颈的问题。

引用文献

• Scalar, Inc.

Scalar DL v1 design document