0.18

Translate

交易处理

CITA 采用微服务架构，各个服务之间通过消息通道进行消息的传递，服务间的消息采用 Protobuf 格式进行编码。各个服务在收到消息后，根据实际情况将消息转化为服务内的结构，进行相应处理。

在 CITA 中交易的生命周期内，用户在客户端按照 Protobuf 结构进行交易构造，将 Protobuf 结构序列化为 bytes 结构，将消息以 JSON-RPC 格式发送到 RPC 模块。RPC 模块对消息进行简单验证，验证通过后将消息发送到 Auth 模块。Auth 模块进行签名验证等，将验证结果通过消息通道返回给 RPC 模块，与此同时，如果验证通过，会将消息插入交易池。最终共识模块打包交易，发送给 Chain&Auth 进行处理。

交易构造

交易的 Protobuf 结构如下。

enum Crypto {
    SECP = 0;
    SM2 = 1;
}

message Transaction {
    string to = 1;
    string nonce = 2;
    uint64 quota = 3;
    uint64 valid_until_block = 4;
    bytes data = 5;
    uint64 value = 6;
    uint32 chain_id = 7;
    uint32 version = 8;
}

message UnverifiedTransaction {
    Transaction transaction = 1;
    bytes signature = 2;
    Crypto crypto = 3;
}

message SignedTransaction {
    UnverifiedTransaction transaction_with_sig = 1;
    bytes tx_hash = 2;  // SignedTransaction hash
    bytes signer = 3; //public key
}

其中 Transaction 为原始的交易的内容，UnverifiedTransaction 为带签名的交易，SignedTransaction 为验证通过的交易。

用户要发送交易，首先构造 Transaction，然后再构造 UnverifiedTransaction，其中 signature 为 Transaction 结构的 Hash 值进行签名得到的字符串，用来保证 Transaction 未被修改。Crypto 用来表示使用的哪一种签名方法。

交易验证

CITA 中交易通过消息总线进行转发，用户通过 RPC 模块和系统进行交互。RPC 请求分为两种：一种是对链上状态进行查询的请求，一种是需要打包到区块中的交易。

首先在 RPC 模块，对用户请求进行验证：

  • 是否符合服务规范（目前支持 JSON-RPC 2.0）;
  • 服务 API 方法是否合法；
  • 参数个数和格式是否合法。

如果验证通过，则根据请求类型发往不同模块。对于查询请求，发送到相关模块，相关模块解析请求，并执行然后返回结果。对于交易，则发送到 Auth 模块，Auth 模块通过验证后，将交易放入交易池。

在 Auth 模块，需要验证

  • 交易签名是否合法；
  • 是否拥有权限；
  • 发送人是否有足够的配额；
  • 交易是否为重复交易。

交易验证通过后，以 SignedTransaction 的结构进行保存，并转发给其他模块。SignedTransaction 主要用来缓存签名和 Hash，这样避免了其他服务再去解签名，以及计算交易 Hash 的开销。

交易打包

最终共识将交易打包成 Block，发送到 Chain 和 Executor 模块，进行相应处理。

Block 的结构如下：

message Block {
    uint32 version = 1;
    BlockHeader header = 2;
    BlockBody body = 3;
}

message BlockBody {
    repeated SignedTransaction transactions = 1;
}

message BlockHeader {
    bytes prevhash = 1;
    uint64 timestamp = 2;
    uint64 height = 3;
    bytes state_root = 4;
    bytes transactions_root = 5;
    bytes receipts_root = 6;
    uint64 gas_used = 7;
    uint64 gas_limit = 8;
    Proof proof = 9;
    bytes proposer = 10;
}

共识对 Block 格式的验证包括：

  • PreHash 是否正确；
  • 区块签名是否正确；
  • 签名个数是否满足。

交易验证成功则正常执行，验证失败则将错误信息保存在交易回执中。CITA 中交易处理具有原子性，当交易在执行过程中发生错误，整个交易状态会回滚。

其中 BlockHeader 中的 transactions_root 用来保存 Body 中的交易 Root，在共识模块中构造 Proposal 时进行构造，以及验证 Proposal 时进行验证。在这里构造好 transactions_root，对于本节点共识的块，后续的 Chain/Executor 不需要再对交易格式进行验证，也不需要再计算 transactions_root。

交易执行

Chain 模块负责存储和保存 Block 相关结构，Executor 模块负责处理交易。交易在处理过程中，采用针对交易的每一步执行进行单步扣费的方式：先检查费用，再进行执行的方式。Chain/Executor 处理完成后，将处理的结果，包括 state_root，receipts_root，gas_used 信息写入 Block，并进行落盘保存。

异步交易处理

区块链节点的最主要职责包括点对点网络交互、共识、交易处理以及数据存储四个方面。节点通过共识算法，在系统中形成对交易排序的全局共识，再按照共识 后的顺序对交易进行逐个处理。只要处理过程能保证确定性，所有节点最后都能达到一致的状态，产生相同的本地数据。

在当前的区块链设计中，共识与交易处理耦合程度较高，共识的性能受到交易处理能力的影响。 CITA 将共识与交易处理解耦为独立的微服务，共识服务只负责交易排序，并不关心交易内容，交易处理服务只负责对排好顺序的交易进行处理。 此时共识过程可以先于交易处理完成，交易处理服务可以异步执行。异步交易处理技术不仅使 CITA 具有更好的共识性能，还带来了更有弹性的交易处理能力， 交易负荷可以被更均匀的分摊到一段时间内。

由于交易异步处理，在共识前只能对交易进行有限的检查，例如签名验证。无效的交易有可能通过共识进入交易处理服务，产生一定程度的垃圾数据。 在有必要的情况下，可以通过 CITA 的交易控制或者垃圾清理技术解决该问题。

← 共识视图 →