技术专栏丨面料与锯齿技术分析（下）

在上一篇文章（Fabric 和锯齿波技术分析（上））中，我们重点与大家分享了Fabric 相关的内容。 在本文中，我们将围绕Sawtooth进行一些分析和讨论。

锯齿结构及分析

Sawtooth是英特尔公司推出的企业级区块链。 2018 年，英特尔将其贡献给了 Hyperlegder 项目。 在本文中，笔者主要对Sawtooth的存储结构、数据结构、网络结构做了简单的介绍。

锯齿

Sawtooth的存储结构

Sawtooth 使用了一种称为 Radix Merkle Tree 的存储结构，它结合了 Radix Tree 和 Merkle Hash Tree 的功能。 我们来看看这两个结构：

Radix Tree的概念有点啰嗦，简单记住在这棵树中，任意一个叶子节点的位置都唯一对应一个01字符串，所以我们可以根据一个01组成的地址来判断叶子节点是谁细绳。

下图是Sawtooth使用的Radix Tree对应的字符串。 它由 70 个十六进制字符组成。 前6位称为命名空间前缀（Namespace prefix），后6位可分配在前缀对应的空间中。 地址范围。

我们以Sawtooth预定义的一个Transaction Family-IntegerKey为例。 请注意，Sawtooth 中的交易族等同于 Fabric 中的链代码或以太坊中的智能合约。 IntegerKey的前缀计算方式为：hashlib.sha512('intkey'.encode('utf-8')).hexdigest()[0:6]，运算结果为'1cf126'。 那么，在交易族中存放一个区块的地址是：

address = "1cf126" + hashlib.sha512('name'.encode('utf-8')).hexdigest()[-64:]

当然，地址的构成也可以更复杂。 例如，自定义交易家族的前缀是 prefix = “my-transaction-family-namespace-example”。 命名空间可以进一步分为对象类型和唯一对象标识符。 其中，object-type = "widget-type", unique-object-identifier = "unique-widget-identifier"。 那么，相应的字符串可以计算如下：

hashlib.sha256("my-transaction-family-namespace-example".encode('utf-8')).hexdigest()[:6] + hashlib.sha256("widget-type".encode('utf-8) ')).hexdigest()[:4]

+ hashlib.sha256("unique-widget-identifier".encode('utf-8')).hexdigest()[:60]

最终得到如下地址：

'4ae1df0ad3ac05fdc7342c50d909d2331e296badb661416896f727131207db276a908e'

众所周知，2的10次方是1K，20次方是1M，30次方是1G，40次方是1T。 对于命名空间，Sawtooth 为其保留 64 位。 在存储空间需求上，即使有一些Bits用于子空间划分，也应该足够了。 查找的时候可以根据Transaction的名字找到它的存储位置，所以检索速度会很快。

我们可以认为 Sawtooth 就像一个原始的区块链，每一层都可以分叉，数据存储以树的形式组织，而不是线性的方式。 最初的比特币区块链也可以理解为只有一个交易族的锯齿波。 完整的分析完Sawtooth，最需要记住的就是Sawtooth的存储结构，后续的所有设计都是基于这个结构。

Merkle Hash Tree的特点是所有节点的值都是哈希值，每个哈希值都是根据其子节点的哈希值计算的，所以任何一个节点和哈希值发生变化，其上层节点的哈希值都会相应地改变。

Sawtooth 使用 Radix Merkle Tree 结构进行数据存储的好处是，给定 Block 名称和类别，可以直接计算哈希值找到其存储位置。 而且，存储空间是隔离的。 每个交易族的存储空间相互独立，互不影响。 因此，从存储结构上看，基于Sawtooth的区块链本质上是多连接的（Forked），很容易分析其分叉。

Sawtooth 的数据结构

Fabric并没有严格定义数据结构，Sawtooth的数据结构也没有什么值得一提的亮点。 只知道Sawtooth定义的Transaction包括Header和Payload，而Sawtooth要求一个或多个Transaction必须封装在Batch中才能提交给Transaction Processor，或者Transaction Processor只接受Batch作为Transaction的最小单位。 同样，Batch也包括Header和Payload两部分，它们的关系如下图所示：

锯齿波的网络结构

如下图所示，Sawtooth 的一个节点可能由以下组件组成：Validator、Transaction Processor、REST API 和 Client。 Validator 是 Sawtooth 的核心组件。 其主要功能包括接收Transaction请求，并转发给相应的Transaction Processor进行处理。 根据Transaction Processor的处理结果，决定如何保存新的块，如何回显给Client。 Validator 还与其他 Validator 合作，以保持 Sawtooth 网络的全局状态一致。 Transaction Processor，顾名思义，就是用来处理某一类Transaction Family的Transaction的Processor。

Client需要根据Transaction和Batch规定的数据结构产生请求，REST API是一种标准化的网络传输数据格式。 之所以可能由这几部分组成，是因为对于Sawtooth来说，只有Validator属于它的固定结构。 比如图中有Validator1和Validator2，Validator2没有连接其他组件，只连接了Validator1。 从组成的角度来看，锯齿网络只能由一个验证器组成。 从网络的角度来看，其他 Validator 可以动态加入网络。 从组件的角度来看，可以将Transaction Processor动态注册到Validator，然后Client提交对应的Transaction，由对应的Processor进行处理。 网络节点和组件可以分别使用不同的端口来区分。 这样，锯齿网络就变成了完全动态的，每个组件都可以动态地插入和拔出。

接下来我们看一下Validator的结构。 Validator的软件实现部分称为Journal，如下图所示。 从功能上看，Journal主要包括三个部分：Completer、ChainController和BlockPublisher。

当 Batch 被提交给 Validator 时，它首先被交付给 Completer，Completer 首先检查是否满足 Batch 的所有依赖项。 完整且依赖的 Batch 将提交给 ChainController。 Sawtooth 的这种设计可以支持串行和并行批处理。 请注意，这不再是进程级并行，而是线程级并行。 接下来我们看看ChainController做了什么：

ChainController 需要完成 4 个工作：

写入新区块链后的发布工作由 BlockPublisher 完成。 从图中可以看出，ChainController和BlockPublisher本质上是接口，具体实现由更底层的共识（Consensus）机制完成，向上提供了BlockVerifier、ForkResolver和BlockPublisher三个功能。

整体来说，Validator的结构比较简单。 接下来，让我们看看Validators是如何连接起来的。 Sawtooth的Validator的网络连接方式如下图所示。 可能有点乱，解释的不是很清楚。 在这里，笔者的理解是：把它看成一个Ad Hoc网络，组网过程完全是模拟发现的Ad Hoc网络路由节点。 一开始，有一个初始的（Genesis block generated）节点，可以发送一个广播包，询问旁边有谁，可以按照设定的规则加入网络。 如果有人回答，就可以加入，然后这些节点继续广播，每个广播包只传给距离自己1跳的Validator节点，这样网络就很快形成了。 当有新节点要加入时也是如此。 发一个广播包，看看你身边有没有可以直连的节点。 退出也没关系。 反正少一个节点不会影响网络。 我们知道 Ad Hoc 网络的鲁棒性和灵活性都非常高，所以 Sawtooth 的 Validator 网络中的任何节点都可以动态加入或退出，只要网络规模足够大，理论上网络的鲁棒性是有保证的。

这里有两个关键问题没有弄清楚。

这两个问题构成了访问控制和隐私保护功能的核心，而Fabric着力实现的架构正是为了回答这两个问题，后面会详细解释。 引入核心网后，会想到Client提交Transaction，这个Transaction到底执行还是不执行？ 所以还是有事件机制来实现消息传递和回显功能。 这里的事件机制需要确定几个东西：

下图是Sawtooth的事件机制示意图。 它把技术实现和组件名称混在一起，看起来很乱。 大致意思就是左上部分是用零消息队列技术实现的事件子系统，特点是需要的时候可以随时创建，右上部分是写好的类库。 注册后，只要满足约束就可以调用。 下半部分是Transaction Processor调用具体的Handler处理Transaction，会告诉ChainController的Scheduler和Executor执行Transaction结果。 ChainController除了会把新的区块写到它应该在的地方之外，还会把Transaction的Receipt放在一个叫做Transaction Receipt Store的地方。 这时候ChainObserver（Client注册后生成的组件）会告诉Client Transaction已经完成，并过来拿回执。

以下是一些事件示例，可以帮助我们理解事件的格式：

 1Example events generated by BlockEventExtractor:
 2Event {
 3 event_type = "sawtooth/block-commit",
 4 attributes = [
 5 Attribute { key = "block_id", value = "abc...123" },
 6 Attribute { key = "block_num", value = "523" },
 7 Attribute { key = "state_root_hash", value = "def...456" },
 8 Attribute { key = "previous_block_id", value = "acf...146" },
 9 ],
10}
11
12
13Example events generated by ReceiptEventExtractor:

14// Example transaction family specific event
15Event {
16 event_type = "xo/create",
17 attributes = [Attribute { key = "game_name", value = "game0" }],
18}
19
20// Example sawtooth/block-commit event
21Event {
22 event_type = "sawtooth/state-delta",
23 attributes = [Attribute { key = "address", value = "abc...def" }],
24 event_data = 
25}

Sawtooth的访问控制

Sawtooth的Permissions机制应该参考Fabric。 主要功能包括网络权限设置（哪些Validator可以加入网络）、Transaction权限设置（哪些client提交的Batch可以被Validator执行）。 与 Fabric 一样，Sawtooth 也需要配置文件。 如果所有功能都通过配置文件完成，则称为Off-Chain transactor Permission。 一般来说，对于小型网络，在极端情况下，只有一个节点的网络可以使用Off-Chain transactor权限。 链式方式实现。 在 Off-Chain Permission 中，权限是静态设置的。 在配置文件validator.toml中，直接配置：

[权限]

角色 = POLICY_NAME

策略文件：

PERMIT_KEY

DENY_KEY

这里的ROLE和POLICY_NAME暂且不做解释。 密钥一般是公钥。 PERMIT_KEY和DENY_KEY把它理解成一个bool值，一个是1，一个是0，表示允许或不允许。

与 Fabric 不同的是，Sawtooth 还有一种配置方法，称为 On-Chain transactor Permission。 就是直接在区块链上设置访问权限，为此专门设置了一个叫做Identity的Transaction Family。 这样transactor Permission就有了自己的存储空间，无论是当前值还是变化，所有节点都可以同步到过去，不会有每个节点配置文件不同导致系统出错的可能。

接下来详细看一下Identity。 Identity Namespace 以键值对的形式存储角色，其中键是角色名称，值是策略。 所有角色都以 transactor 为前缀。 例如：

transactor.SUB_ROLE = POLICY_NAME

首先，第一个问题是谁可以设置访问权限。 与 Fabric 示例类似，组织 R4 通过网络配置文件设置访问权限。 在 Sawtooth 中，创世块的创建者应该设置初始权限是理所当然的。 它执行以下命令来设置允许授权他人的人的公钥：

sawset 建议创建 sawtooth.identity.allowed_keys=00000

这里的00000是创世块创建者的公钥，现在可以自己授权给别人了。 这类似于 Fabric 中的设置。 设置好公钥后，可以使用identity-tp进行授权，也可以继续使用sawset proposal create命令让其他Validator有权限做网络或交易授权。 proposal子命令其实可以猜到Sawtooth在设计访问权限的时候一定参考了Fabric。

具体交易授权命令示例如下：

sawtooth identity policy create policy_1 "PERMIT_KEY *"，意思是创建一个名为policy_1的策略，允许所有人，即任何人都可以提交Transaction。 请注意，这只是一个策略，还可以定义其他策略。 相当于Deploy in Fabric而不是Invoke。 可以调用锯齿波身份策略列表查询当前策略。 比如执行刚才的命令后，会得到如下echo：

$ 锯齿形身份策略列表

政策_1：

参赛作品：

PERMIT_KEY*

接下来执行以下命令：

$ 锯齿身份角色创建事务处理程序 policy_1

交易者的政策将设置为 policy_1。 也就是说ae换成比特币怎么填写委托价格，此时policy_1才真正生效，类似于Fabric中的Invoke。 然后可以调用sawtooth identity role list查询当前角色的状态：

$ 锯齿形身份角色列表

交易者：policy_1

上面我们都是以transactor为例，其实角色可以有如下几种：

默认，交易者，transactor.transaction_signer，transactor.transaction_signer.{tp_name}，transactor.batch_signer。

字面意思可以看出，这里的transactor可以是组织，一个transactor.batch_signer可以是组织下的一个部门，transactor.transaction_signer可以是该部门的一个用户，如果有很多tp，用户只能有一个对某些 tp 的执行权限。

比如我们现在新写了一个tp叫supply_chain，定义了两个新用户，一个公钥为12345，一个公钥为23456，我们希望只有这两个新用户才能运行这个tp。 然后我们可以执行命令：

锯齿身份策略创建 policy_2“PERMIT_KEY 12345”“PERMIT_KEY 23456”

锯齿身份角色创建 transactor.transaction_signer.supply_chain policy_2

网络权限设置类似于tp执行权限设置。 例如，如果有一个外部公钥为00001的Validator，然后执行下面的命令，它就无法加入网络：

$sawtooth 身份策略创建 policy_3“DENY_KEY 00001”

$ 锯齿身份角色创建网络策略_3

$ 锯齿形身份角色列表

网络：policy_3

织物和锯齿的比较

相信看完Fabric和Sawtooth的介绍，大家对这两个项目都有了自己的理解。 笔者就谈谈我个人对这两个项目的理解。

首先，从背景来看，Fabric脱胎于以太坊，或者说在Fabric上可以看到以太坊的影子，但是Sawtooth已经看不到任何以太坊的踪迹。 相反，我个人觉得Sawtooth更纯净。 它是一个具有共同起点的比特币区块链，但比特币没有不同交易的概念，Sawtooth 将交易根据用途进行分类，并允许用户根据需要定义新的交易（这个概念是由以太坊提出的） .

从架构的角度来看，我认为 Sawtooth 明显优于 Fabric。 Fabric 看起来像是针对特定问题的专门解决方案，而不是通用架构。 锯齿可以被认为是一种通用架构，然后根据需要变成一种专门的解决方案。 从访问控制的角度来看，Fabric 似乎是根据实际情况搭建了一个管网，让涉及隐私的数据只能在其中运行。 Sawtooth更像是在一组管网中加入阀门，通过阀门来控制数据的流动。 这或许与IBM和英特尔的业务特点和企业文化密切相关。 在我的印象中，IBM是一家为企业级用户设计解决方案的咨询公司。 英特尔是一家处理器公司。 无论您的业务是什么，它都提供了一个通用的中央处理器ae换成比特币怎么填写委托价格，您可以根据需要将其配置成您自己的专用解决方案。

当然，两者也有一些具体的区别：在Fabric中，多个节点收到相同的输入后独立执行，以获得一致的结果。 Sawtooth 的 SGX 和基于 SGX 的 PoET 在一台机器上验证执行结果，不是让每个节点重新执行一次，而是在一次执行完成后与其他节点同步结果。 两者的假设不同，效率也不同。 Fabric 的访问控制依赖于通道架构，而 Sawtooth 的访问控制是通过 Transaction 本身来设置的。 也就是说，Fabric只能被特定的人看到，但是一定范围内的所有人都可以看到。 Sawtooth 中的每个人都可以看到，但是交易权限限制了可以看到的内容。 Fabric的orderer完成Transaction排序，可以实现进程级的并行。 Sawtooth的排序是在batch中指定依赖关系，通过Completer排序实现线程级的并行。

对于Fabric来说，在设计的时候，大家公认的网络结构就是以太坊，怎么能稍微修改一下，实现隐私保护和访问控制是它的设计目标。 Sawtooth 没有这样的包袱，可以重新设计网络。 所以，我觉得Fabric更多的是一个过渡产品。 在我看来，Sawtooth的结构设计比较精致，可扩展性强，这是它比Fabric强的地方。 但是也可以借鉴Fabric，加入类似CA的机制来保证用户可以被识别，还应该增加权限配置的灵活性，比如引入ABAC等等。 不过，就目前而言，它还不错。