区块链之联盟链（四） 认识Sawtooth
Sawtooth 是由INTEL 提供给超级帐本联盟的。作为其中的一个完整区块链框架，它经常会被拿来和Fabric比较。其实Sawthooth的提出，更多是Inter对其基于硬件安全的自家产品SGX的长期推广战略。所以Sawtooth 1.0 我们看到在产品环境是仅支持POET-SGX共识方式的。
Sawtooth 号称是支持公链，联盟链，私链, 但实际上缺乏钱包等公链基础设施，且社区更多是企业用户。所以Sawtooth用于公链更多是技术理论上的。
与同一联盟的Fabric 相同，Sawtooth 也是支持模块化的，利于未来的扩展，从1.2以后，Sawtooth项目也支持了自己实现的PBFT共识 和 RAFT共识，但当前RAFT共识模块还没有正式发布。
本文将仿照区块链（三）认识Fabric 的文章组织结构，来和大家一起看看Sawtooth，方便搭建快速认识和对比。
在Sawtooth中并没有Fabric特有的Channel概念，所有企业都拥有一个或多个Sawtooth Node（有点类似于Qurotum）。如下图，一个Validator Node 节点通常包括 Validator，Consensus Engine， Transaction Processor 这些核心服务。
Consensus Engine 是Sawtooth网络中共识的具体实现，同一网络中所有节点只能使用同一共识。
Transaction Processor 是业务的具体处理服务，也就是智能合约实现的服务。通常在Sawtooth网络中，某一种业务对应一个Transaction Processor 和 一个独立命名下的存储空间（sawtooth 称它为 Transaction Family）。
而Validator 作为核心， 接受来自客户的请求，验证业务，分发给Processor处理，并验证后打包到Block，最终通过gossip网络传播到其它节点，并达到公式。
Sawtooth 的网络连接
联盟链中的一个重要概念是权限控制，其决定用户是否可以访问和节点是否可以加入。在Fabric 用户或客户应用的身份（identity）是由CA发布的certificate来代表的，而在Sawtooth网络中没有CA中心，所有的身份由Public key（公钥）表示。 而public key保存在两个地方， validator的本地配置文件和 链上（on-chain)配置中, 链上配置由 Sawtooth 提供的 Identity Family 实现。
总结一下，Sawtooth的权限控制包括两部分：
Transactor key permissioning：控制谁有权限提交事务和批处理（在下文介绍），在客户应用提交一个批处理的时候，Validator将会验证提交者的Key， 只有本地规则和在线规则都满足时才可以提交。
Validator key permissioning： 控制谁可以连接到Sawtooth网络节点内。 当一个Validitor加入网络时，系统会验证该Validator的public signing key， 当匹配时才允许加入。
在Sawtooth 中为这两种方式默认定义了一系列的角色。一个角色拥有一个Policy，一个Policy 中包含了能够使用该角色的Public key。更简单的立即，Policy 包含了一系列的用户，将一个Policy指定给一个角色，就是给这些用户分配相应的角色； 当然，只有具有角色的用户可以正常使用角色所赋予的权限。
带有权限验证的节点
Sawtooth Identity Family 事务簇里定义了系统内使用的Transactor key permissioning需要的角色和Validator key permissioning需要的角色。
Transactor 系统定义角色
Validator节点间通信的角色定义
可以看到，Identity Familly 默认定义好的角色只满足Sawtooth Validator 节点验证与节点通信的权限定义。但对于更多的权限要求，可以通过Identity Familly增加身份与角色。
Sawtooth提供了Restful API、命令行工具、ZMQ消息三种方式，同Validator 通信。命令行工具方式只用于管理和运维，而客户端通常使用标准Restful API 和 由ZMQ消息实现的客户化的API来同客户端通信。默认提供的Restful API 没有任何访问限制，而客户化的API 可以添加自己的权限逻辑。
客户端与Validator节点通信
如上图，Client A 适用标准接口，Client B 适用Custom 接口，相比较ClientB可以通过Custom API 隔绝人与Block 有关的信息，同时可以增加自定义权限控制。企业环境中应该适用Client B方式更合适。
通过Sawtooth 网络连接的分析，我们可以看到对于Sawtooth网络，区块链应用主要需要开发两个部分，Custom API与Transaction Processor。要更好的开发基于Sawtooth的应用，我们需要了解一下Sawtooth自己的状态存储与事务。
在Fabric， world State是以键值对的方式存储在couchdb中；而Sawtooth则使用Merkle-Radix数的方式组织World State。每个State的存储地址的地址总长35个bytes，前三个byte用于区分命名空间，每个命名空间对应一个Transaction family, 也就是说每个transaction Family 具有独立连续的存储空间。整个Sawtooth网络只有一个World State树。
Radix树将存储数据地址分为35层，叶子节点真正存储数据，Radix数的方式可以有效减小存储空间。
而Merkle数是区块链中进行数据防伪的主要方法，基于加密学的，自校验防篡改的数据结构，用来存储键值对关系。子节点存储数据，上层节点是多个子节点的Hash值，最后形成根Hash， 只要一个数据发生变更，根hash就会发生变更。
Word State的存储方式
World state存储的实质仍旧是Key-value键值对。在Merkle-Radix数中，Merkle 表征的是数据与Hash的树， Radix 表征的数据与寻找关系的树。当量个树重合后，每一个叶子结点将存储数据，每一个非叶子结点将存储所有子节点的路径和所有子节点连接后的新hash值。每一个Block块儿中都会写入上一个Block加入链后的根结点Hash，验证节点只需要验证根Hash是否和当前world state所组成的Merkle-Radix树的根结点Hash一致，就可以判断当前Block是否有效。
