bigchaindb源码分析（十）——总结

根据我们耗时如此长的源码分析，我们可以对bigchaindb进行一些初步的总结了

首先是可以总结一些相关的概念：

• 联盟：维护bigchaindb的所有合法的节点，相当于配置文件中的keyring项加上节点本身
• 事务：事务分为三种
  
  • 用来构建创世区块的事务：这个事务在bigchaindb首次启动时将会自动创建
  • CREATE事务：代表着创建资产，CREATE事务中的asset项应当包含了资产的全部内容，资产的全部内容也会当成记录保存在assets表中
  • TRANSFER事务：代表着转移资产，TRANSFER事务中的asset项仅仅包含了资产的id
• 区块：多个事务组成区块，一个区块记录了前一个区块的信息，从而形成链。区块的状态有三种
  
  • valid：合法
  • invalid：验证失败
  • undecided：投票还未结束
• 投票：当一个区块被创建时，联盟中的所有节点将会对区块进行投票，这个投票主要验证了写区块的节点的合法性、区块签名、区块中所有事务的签名
• 选举：当一个区块被投票后，选举用来根据投票结果来确定区块的合法性。当半数投票节点投票valid或者invalid后，区块的状态被确定。选举的另一个作用还在于确定区块的前一个区块，做法是对所有投票本区块为valid的投票节点所投票的上一个区块进行计数，数目最多的上一个区块为本区块的上一个区块
• 分配：当一个事务被创建后，将分配一个节点来处理该事务，如是否创建区块

节点按照功能可以分为三类：

• 请求节点：写事务请求的节点
• 被分配节点（或者处理节点）：处理事务的节点
• 投票节点：对区块进行投票的节点

后端存储有四个表：

• backlog：记录事务
• bigchain：记录区块
• assets：记录资产
• votes：记录投票

bigchaindb所启动一直在无限运行的、与区块链逻辑有关的进程有四种：

• block：
  
  • 触发条件：backlog表中有insert或者update操作发生
  • 任务：验证事务、对事务去重、根据事务创建区块、写bigchain表、删除backlog中已经被包含在区块中的事务
• vote：
  
  • 触发条件：bigchain表中有新的未投票的区块
  • 任务：验证区块、验证区块中的事务、投票、写votes表
• stale：
  
  • 触发条件：backlog表中有事务处理超时
  • 任务：对该事务重新分配处理节点
• election：
  
  • 触发条件：votes表中有insert操作发生
  • 任务：根据投票结果确定区块的合法性、若区块合法确定区块的上一个区块、对不合法区块里的所有事务重新写入backlog表

当客户端使用API对bigchaindb写事务时，整个流程为：

• client API：
  
  • prepare：创建事务的节点给出json格式的事务
  • fulfill：创建事务的节点对事务进行签名
  • send：创建事务的节点将事务发送给bigchain守护进程
• client bigchaindb:
  
  • validate：守护进程验证事务的签名
  • write：设置事务的被分配者，将事务写入backlog表
• block:
  
  • 当backlog表中写入数据时，block进程的pipeline被触发，indata将事务放入输出队列中
  • filter: 如果事务分配给本节点处理，移除事务中的被分配者项
  • validate：判断事务是否已经被确定为valid或者正在等待投票，若是，则删除事务，否则被分配节点验证事务签名
  • create：被分配节点对现有的事务进行去重，当要处理的事务数达到1000条，或者超时时，根据这些事务创建区块，同时设置投票者，并对区块进行签名
  • write: 被分配节点将区块写入bigchain表
  • delete：被分配节点从backlog表中删除当前区块的所有事务
• vote:
  
  • 找到本节点最后投票的区块，然后对这个最后的区块之后所有bigchain表中添加的区块都使用yield进行抛出到indata的输出队列中
  • validate_block：判断vote表中是否已经有了本投票节点对该区块的投票，如果有则直接退出。若还未投票，则从assets表中查询该区块中所有事务的资产，并将CREATE事务（以及创世区块）的asset项更新为assets表中的记录。确保所有CREATE事务（以及创世区块）的asset项为完整的资产记录，而TRANSFER区块的asset项为asset的id
  • validate_block：验证写区块节点身份，验证区块签名
  • validate_tx：对区块中的每个事务进行处理。若包含该事务的区块的投票结果为valid或者undecided，抛出“事务已经存在”的异常，否则验证事务的签名。这样给予了之前投票为invalid的事务再次被投票的机会
  • vote：当验证完本区块中的所有事务，且验证结果均为True时，构建投票记录，并对投票记录进行签名
  • write_vote：将投票记录写入votes表中
• election：
  
  • 当votes表中写入数据时，election进程的pipeline被触发，indata将事务放入输出队列中
  • 获取投票所对应的区块记录
  • 根据区块记录获取到区块应该有的投票者，然后根据节点配置文件中设置的联盟中所有节点，做交集得出符合条件的投票者
  • 从votes中查询得到的对本区块的投票记录，判断记录的投票者是否符合条件，判断投票记录的签名是否正确
  • 判断所有成功的投票记录中，是否有某个节点投票了不止一次，若出现这种情况则抛出异常
  • 对投票记录进行统计，这个统计还包含了认为该区块为valid的节点所投票的上一个节点的一致性。具体来说，对所有对本区块投票为valid的节点，用计数器记录了这些节点投票过的上一区块，然后利用Collections模块的most_common函数返回计数最多的上一个区块，将这个区块作为本区块的前一个区块
  • 决定投票结果。确定区块是否为valid的方案则是看哪种投票结果超过半数
  • 若区块的投票为invalid，将该区块中的所有事务重新写入到backlog表中，此后block进程的pipeline又将被触发来处理这些事务
• stale：
  
  • 若backlog表中的事务处理超时，重新分配处理节点