目录
-
sawtooth基本概念
1、Batch:a protobuf object,包含一系列的transactions,一个header一个签名，batch signer用私钥对batch header进行签名。
2、Transaction：一个protobuf object，包含payload，header，和signature。签名是transaction signer使用自己的私钥进行签名。transaction修改状态，客户端建立交易发送给valid
ator(个人理解是节点）。transaction打包在batch中，客户端发送出去。
3、Consensus：建立一个共识（the mutually distrusting participants are the other nodes on the validator network.）
4、Transaction Family：包含了transaction payload 的格式，a model for storing information in global state（一个模型用于往global state（merkle hsah）中存储数据）验证交易以及基于transaction payload更新更新状态的程序。由开发者开发（codify business rules used to modify state）
5、Transaction Processor：基于Transaction Family定义的规则进行交易验证并且更新状态。
6、Validator：一个component来验证batches和transaction，将它们存入区块，保证整个网络的一致（maintaining consensus），负责和client以及其他的validator和transaction processor通信（validator个人理解就是网络中的节点）。
7、Node:一个尝试连接到网络的validator
8、Client：尝试连接到validator的程序，可以去查询区块链状态、发送交易
9、Radix Merkle Tree:representation of state
10、Validator Network：p2p网络，同一个区块链
11、Authorization Procedure:与validator建立链接的时候必须遵循的规则。
12、Policy：一系列规则来判断是否能够加入validator network，以及一个交易是否会被处理。
13、Transactor:对batch和transaction签名的人，对batch签名的话同时也是batch signer，对transaction签名的话同时也是transaction signer
14、Network Operator：一个或多个sawtooth网络的管理员，配置协调整个网络的配置（which transaction processors are being run, the consensus mechanism, modifying on-chain settings）
15、Sysadmin：运行validator software的人
-
全局状态：
区块中数据Radix Merkle Tree表示全局状态，树中每个节点有一个地址，用于标识一个节点。所有的transaction family的交易存储在一个merkle tree当中。merkle tree的根哈希存储在区块头中。地址前三个字节为命名空间，命名空间使得transaction family authors可以定义、共享、复用全局数据（merkle tree的数据），地址35个字节，前三个字节为命名空间，后32个字节为命名空间相关的编码。不同的transaction processor设定不同地址的数据，数据是业务相关的，对平台透明。个人理解：所有transaction processor的交易数据存储在一颗merkle tree中，merkle tree可寻址，每个节点有一个地址，由不同的命名空间区分不同的transaction processor的数据。
-
Transaction和Batches：
sawtooth运行基本流程：client生成交易=>提交交易给validator=>validator处理交易，修改状态。
Transaction：transaction signer对交易进行签名，公钥放在交易中，validator进行验证。交易中的dependencies字段：必须在此交易处理以前完成的交易，对于不在同一个batch中的交易，可以指定dependencies去明确处理的顺序。
Batch：batch signer 对batch再进行签名，batch signer的公钥也一同发给validator。多个交易可以打包在一个batch中，batch内的所有交易是原子的。batch内的交易按照在batch内的顺序处理，batch内存放有关联性的交易，简化客户端的设计。交易中的dependencies字段用于指定不在一个batch中交易的执行顺序。
例如：A，B，C三个交易，任意一个交易无效所有交易都无效，如果只通过设定dependencies，则A依赖BC，B依赖AC，C依赖AB，难以对交易进行排序。
Batch signer和transaction signer可以不一样，例如客户端浏览器对一个交易进行签名，一个服务端组件（server-side component）将交易打包成batch对batch签名，即多个客户端浏览器看到的是一个服务器（server-side component），服务器将多个客户端签名的交易打包发送给平台。
-
Journal：
journaal为整个sawtooth的核心部分，journal负责维护、扩展区块链，负责验证候选区块、生成新区块。对于发送给validator的区块和batches进行处理，候选区块和batches通过gossip协议（validator之间）或restapi（客户端）发送过来。
Journal的架构：
对于blocks和batches进行不同的处理，首先blocks和batches被发送给completer，blocks被传送给chain controller去验证区块的有效性并且解决分叉问题，batches被传送给block publisher去验证交易并写入一个新的候选区块。
Journal是异步的，允许并行处理。
实现了consensus interface去支持不同的共识算法。
BlockStore模块：包含当前区块链上所有的区块，genesis blocks一直到current chain head。可以通过block id、batch id、transaction id、block number去访问区块。保存了transaction-to-block和batch-to-block的映射。
BlockCache模块：保存blocks的工作集，追溯区块的状态。区块状态包括valid、invalid、unknown（未完成validation）。
Completer模块：validator收到blocks和batches后首先递送给completer模块，该模块保证blocks和batches的依赖关系已经满足（predecessors已经递送给其他的模块），有一个时间限制，如果到了时间限制以后还没有满足条件的额话就drop掉。
Consensus Interface模块：共识模块，可更改共识算法，通过transaction family的设置可以改变共识算法。初始共识算法由创世区块设定，可以动态改变（this may be changed during the course of a Chain’s lifetime）。Consensus Interface被分成三个更小的额模块：
Consensus.BlockPublisher、Consensus.BlockVerifier、Consensus. ForkResolver。Sawtoot的共识算法必须实现这三个接口：
①Consensus.BlockPublisher:由BlockPublisher调用，产生新的候选区块。首先initialize_block，产生候选区块，检查区块头是否正确，检查依据共识算法是否可以成块。如果这一步失败的话BlockPublisher模块会周期性地尝试产生新的区块。接着check_publish_block，检查是否到了成块的时间。最后finalize_block，已经到了成块的时机，期待所有节点对于成块的共识结果，BlockPublisher模块调用finalize_block，填充block_header的consensus field，BLockPublisher对新的区块进行签名并广播出去
②Consensus.BlockVerifier:提供区块验证服务，检查是否符合共识算法，验证区块的有效性等。
③Consensus.ForkResolver:解决链分叉的问题
ChainController模块：收到新的候选区块后进行处理，如果区块链产生了分叉，ChainController并行检查所有的分支，用于几个节点同时脱离了区块链网络一段时间后又重新连接的情况。
收到一个新的区块=>ChainController生成一个BlockValidator，放入线程池处理=>处理完成，回调ChainController检查是否该区块可以作为新的链头区块，如果检查成功，则新生成一个区块。更新区块链（使用BlockStore模块进行更新）的时候将一些新生成的区块加入，将一些旧的区块移除（数据的一致性），通知BlockPublisher链的更新。ChainController可以生成多个BlockValidator去并行验证多个区块。并行验证，通过fork resolution保证数据的一致性。
验证区块的步骤①Transaction Permissioning检查谁有权限提交交易。
②检查新区块没有违反on-chain block validation rules
③检查交易，例如双花问题
④Consensus Verification：通过共识算法的规则验证区块
⑤计算StateRootHash与区块头内的StateRootHash比较
BlockPublisher模块：负责生成新的候选区块，并且增加新区块到链上。
每个阶段共识算法都可以检查区块的有效性。生成新的候选区块的时候，一个Consensus.BlockPublisher被创建，Delay用于处理交易。
个人理解：网络中每个validator并行的处理交易，并行的生成新的候选区块并广播出去。validator并行的对区块进行验证，并且提供了Consensus.ForkResolver保证所有节点数据的一致性。
创世区块生成：通过创世区块的生成配置共识算法，进行相应的配置。创世区块的生成：将一些batches存入文件，引导整个网络的启动。GenesisData包含一些列的初始batches。
TransactionFamily的开发人员提供GenesisData
从文件中读取交易，按照标准的交易处理流程处理交易生成新的区块。成创世区块的过程中使用创世共识算法（genesis consensus），创建了一个区块，共识算法字段是空的（this will produce a block with an empty consensus field）。同时，记录block chain ID（对创世区块的签名）。创建创世区块的过程中配置共识算法，第二个区块生成的时候使用这个配置好的共识算法，这样在第一个创世区块consensus字段为空的时候可以知道使用什么样的共识算法。写入第二个区块的consensus字段，在以后的成块过程中，每次成块的时候从前一个区块当中consensus字段读取共识算法，使用该共识算法进行共识，这样的话实现了共识算法可配。通过修改每个区块中的Consensus field字段来确定每次使用什么样的共识算法。（Part of the production of the genesis block will require the configuration of the consensus mechanism. The second block will then use the configured consensus model, which will need to know how to initialize the consensus field from an empty one. In future cases, transitions between consensus models may be possible, as long as they know how to read the consensus field of the previous block.）
共识算法动态可配（the consensus is selected during the initial network setup and can be changed on a running blockchain with a transaction)，个人的理解：在生成创世网络区块的时候配置共识算法，区块头中有一个consensus的字段，每次成块共识的时候从前一个区块头中读取共识算法的字段。如果要改变共识算法的话，client发送一笔改变共识算法的交易，这笔交易成块后，新的区块的consensus字段为新的共识算法，此后的共识采用新的共识算法。初始的共识算法也是通过创世交易配置的。
整个平台运行的总体流程：client通过restapi发送batches=>validator收到batches=>completer收到batches，确保之前的交易都已经delivered，将batches发送给BlockPublisher=>BlockPublisher处理交易，处理完成后生成一个新的候选区块=>将候选区块签名广播出去=>其他节点的completer收到了候选区块，将候选区块发送给ChainController=>ChainController生成BlockValidator去验证区块，根据共识算法得到共识=>通过BlockStore更新块链
-
交易处理
Chain Controller和Block Publisher发送一个scheduler给executor，scheduler负责调度交易与候选区块。一个validator有多个scheduler并且动态创建scheduler。
ChainController：收到一个候选区块的时候，创建一个scheduler，为新的区块计算merkle hash，与区块头中的哈希比较。验证区块有效性。
BlockPublisher：validator收到新的batch=>加入BlockPublisher的scheduler，处理交易=>有效的交易被放入下一个候选区块。
处理交易的时候可以并行处理。
-
RestAPI
Get方法：通用格式/resources或者/resources/resource-identifier
提交交易：
-
Validator Network
sawtooth的网络层：validator之间的通信使用gossip或者epidemic协议。网络层独立于应用层。
使用0MQ（socket library）进行节点通信（0MQ Asynchronous Client/Server Pattern ）
定义了connection的三种状态：unconnected、connected（套接字之间建立了连接，peered状态的前提）、peered（双向状态，可以进行应用层消息通信）。
每个节点和部分节点建立peered关系（peering minimum connectivity threshold）。
节点发现（peer discovery）：通过不断地向节点发送CONNECT/GET_PEERS获取集群信息（neighbors of neighbors)，在拿到的集群信息中随机选择一些，进行connect与peer连接，当达到minumum connectivity。
节点之间的connection有一个role，这个role控制了在这个connection上发送什么类型的消息。根据connection的role，validator可以决定将消息是否丢弃。上面是RoleType数据类型表明了各种Connection的Role。
建立connection的流程：
希望建立连接的节点发送ConnectionRequest，接着validator回复ConnectionResponse，包含了多个RoleEntry 和一个AuthorizationType。RoleEntry为支持的connection类型（role），AuthorizationType描述了认证方式（建立链接需要执行的步骤）
AuthorizationType为trust：
当收到的Authorization为trust的时候，发送AuthorizationTrustRequest，包含了期望申请的connection role以及公钥，validator返回结果。
AuthorizationType为challenge：
requester发送AuthorizationChallengeRequest，validator回复AuthorizationChallengeResponse包含了待签名的数据以及公钥，签名后连同公钥一同发送过去，验证通过后，存储公钥。
-
PoET共识机制
PoET（Proof-of-Elapsed-Time）是Sawtooth默认采用的共识机制，每次出块直接乐透抽奖选出一个出块人，sawtooth使用一个可信任环境（TEE）如 Intel® Software Guard Extensions (SGX) 来随机选出一个出块人（无法作弊）。
每个节点发布块之前都要从一个enclave获取一个随机的等待时间，等待时间最短的率先发布块（相当于被选为leader），其中的enclave是通过新型的安全CPU指令（TEE）来实现的。TEE提供基于保证等待时间：保证每个节点确实是随机选取了一个等待时间，并且确实等待了对应长的时间以后发起了成块。