一文读懂插件化共识机制

一、整体设计

共识插件模块的整体设计如图：

交易池模块：主要有交易过滤和交易排序的功能，为了防止交易的重放，每一笔新接收的交易都需要通过布隆过滤器进行过滤。过滤成功后的交易，会注入到交易队列中按交易时间进行排序，保证交易的先来后到和即时确认。

• 接收交易：接收来自API层传入的交易，将交易注入交易池模块中，随后通过节点的网络模块广播交易；
• 节点共识：包含当前分布式节点共识状态的确认以及网络的共识通信，共识状态可以判断当前分布式网络是否已经准备就绪，准备就绪的标准之一是已经选举出主节点。网络的共识通信是节点的共识消息通信，比如节点选举通信、节点共识消息通信、节点配置变动通信等等；
• 打包出块：节点收到共识消息后，根据出块时间定时收集交易出块。
• 区块确认：区块的交易执行完成并持久化之后，执行引擎通知共识插件模块区块已经确认。

二、接口设计

需要提供的接口主要分为以下四个部分：

>Prepare接口

>Step接口

• 共识消息（CONSENSUS）类型：由Raft发送的共识消息，其中消息的内容主要有共识的日志信息、日志索引以及当前的任期信息等。
• 广播交易（BROADCAST_TX）类型：由其它节点广播的交易消息，该节点接受到会将交易存在交易池中。
• 获取交易（GET_TX）类型：由其它节点发出获取交易的请求消息，如果某节点在出块阶段发现部分交易不存在交易池中，则会向全网异步发送获取丢失交易的请求消息。该节点接收到消息后发现交易确实存在交易池或者区块的历史数据中，则将该交易发送给丢失交易的节点。
• 响应交易（GET_TX_ACK）类型：和获取交易类型相对应，丢失交易的节点获取到其它节点发送的交易后，将交易存入交易池中进行出块。

message RaftMessage {

    enum Type {
        CONSENSUS = 0; //共识消息类型
        BROADCAST_TX = 1; //广播交易类型
        GET_TX = 2; //获取交易类型
        GET_TX_ACK = 3; // 响应交易类型
    }
    Type type = 1; // 消息类型
    uint64 fromId = 2; //消息来源方
    bytes data = 3; //消息数据
}

>Commit接口

//共识消息结构体
message Ready {
    repeated bytes txHashes = 1; //交易哈希列表
    uint64 height = 2; //区块高度
}

>ReportState接口

三、插件编译与接入

>插件编译

SHELL := /bin/bash
CURRENT_PATH = $(shell pwd)
GO  = GO111MODULE=on go
plugin:
   @mkdir -p build
   $(GO) build --buildmode=plugin -o build/raft.so etcdraft/*.go

$ make plugin

>插件接入

[order]
  plugin = "plugins/raft.so"

./
├── api
├── bitxhub.toml
├── certs
│   ├── agency.cert
│   ├── ca.cert
│   ├── node.cert
│   └── node.priv
├── key.json
├── logs
├── network.toml
├── order.toml //共识算法配置文件
├── plugins
│   ├── raft.so //共识算法插件
├── start.sh
└── storage

本文链接：https://www.8btc.com/media/620034
转载请注明文章出处