最近在处理智能合约的事务上链问题，发现其中仍旧有知识盲点。原有的认识是一个事务请求会从客户端设备打包签名，然后通过RPC传到非出块节点，广播给超级节点，校验打包到可逆区块，共识确认最后变为不可逆区块。在执行事务完毕以后给客户端一个“executed”的状态响应。基于这个认识，本文将通过最新EOS代码详细分析验证。
关键字：EOS，区块链，eosjs，transaction，签名，节点，出块节点，事务校验，事务广播
客户端的处理：打包与签名
客户端设备可以通过eosjs完成本地的事务体构建。下面以调用hello智能合约为例。
注意：eosio.cdt的hello合约中hi方法的参数名为nm，而不是user，我们下面采用与cdt相一致的方式。
方便起见，可以首先使用eosjs-api提供的transact方法，它可以帮助我们直接将事务体打包签名并推送出去。
(async () => {
const result = await api.transact({
actions: [{
account: 'useraaaaaaaa', // 合约部署者，是一个EOS账户
name: 'hi', // 调用方法名，hello合约的一个方法。
authorization: [{ // 该方法需要的权限，默认为合约部署者权限
actor: 'useraaaaaaaa',
permission: 'active',
}],
data: { // 方法参数
nm: 'water'
},
}]
}, {
blocksBehind: 3, // 顶部区块之前的某区块信息作为引用数据，这是TAPoS的概念。
expireSeconds: 30, // 过期时间设置，自动计算当前区块时间加上过期时间，得到截止时间。
});
})();
然后我们可以进入transact方法中查看，仿照其实现逻辑，自行编写一个完整流程的版本。
“打包”在EOS中与“压缩”，“序列化”，“转hex”等是相同的，因此所有之前提到过的压缩，转化等概念都是指同一件事。例如compression：none属性，之前也提到过zlib的方式；cleos中convert命令；rpc中的abi_json_to_bin等。
①打包Actions
actions的结构与前面是相同的。
// actions结构与上面相同，这是我们与链交互的“个性化参数”
let actions = [{
account: 'useraaaaaaaa',
name: 'hi',
authorization: [
{
actor: 'useraaaaaaaa',
permission: 'active'
}
],
data: {
nm: 'seawater'
}
}];
// 打包Actions
let sActions = await api.serializeActions(actions);
eosjs中通过serializeActions方法将Actions对象序列化，序列化会把data的值压缩（可理解为密文传输参数以及参数的值），最终变为：
[{
account: 'useraaaaaaaa',
name: 'hi',
authorization: [{
actor: 'useraaaaaaaa',
permission: 'active'
}],
data: '0000005765C38DC2'
}]
②打包Transaction
首先设置事务Transactions的属性字段。
let expireSeconds = 3; // 设置过期时间为3秒
let blocktime = new Date(block.timestamp).getTime(); // 获得引用区块的时间:1566263146500
let timezone = new Date(blocktime + 8*60*60*1000).getTime(); // 获得+8时区时间:1566291946500
let expired = new Date(timezone + expireSeconds * 1000); // 获得过期时间:2019-08-20T09:05:49.500Z
let expiration = expired.toISOString().split('.')[0]; // 转换一下，得到合适的值:2019-08-20T09:05:49
expiration: expiration, // 根据延迟时间与引用区块的时间计算得到的截止时间
ref_block_num: block.block_num, // 引用区块号，来自于查询到的引用区块的属性值
ref_block_prefix: block.ref_block_prefix, // 引用区块前缀，来自于查询到的引用区块的属性值
max_net_usage_words: 0, // 设置该事务的最大net使用量，实际执行时评估超过这个值则自动退回，0为不设限制
max_cpu_usage_ms: 0, // 设置该事务的最大cpu使用量，实际执行时评估超过这个值则自动退回，0为不设限制
compression: 'none', // 事务压缩格式，默认为none，除此之外还有zlib等。
delay_sec: 0, // 设置延迟事务的延迟时间，一般不使用。
context_free_actions: [],
actions: sActions, // 将前面处理好的Actions对象传入。
transaction_extensions: [], // 事务扩展字段，一般为空。
};
let sTransaction = await api.serializeTransaction(transaction); // 打包事务
注释中没有对context_free_actions进行说明，是因为这个字段在《区块链 + 大数据：EOS存储》中有详解。
eosjs中通过serializeTransaction方法将Transaction对象序列化，得到一个Uint8Array类型的数组，这就是事务压缩完成的值。
Uint8Array[198, 164, 91, 93, 21, 141, 3, 236, 69, 55, 0, 0, 0, 0, 1, 96, 140, 49, 198, 24, 115, 21, 214, 0, 0, 0, 0, 0, 0, 128, 107, 1, 96, 140, 49, 198, 24, 115, 21, 214, 0, 0, 0, 0, 168, 237, 50, 50, 8, 0, 0, 0, 87, 101, 195, 141, 194, 0]
③准备密钥
密钥的准备分两步：首先通过已处理完毕的事务体获得所需密钥requiredKeys，然后在本地密钥库中查看可用密钥availableKeys，比对找到对应密钥。
signatureProvider.getAvailableKeys().then(function (avKeys) { // 获得本地可用密钥
// 查询事务必须密钥
rpc.getRequiredKeys({transaction: transaction, availableKeys: avKeys}).then(function (reKeys) {
// 匹配成功：本地可用密钥库中包含事务必须密钥
console.log(reKeys);
});
});
由于执行结果存在先后的依赖关系，因此要采用回调嵌套的方式调用。最后成功获得匹配的密钥：
[ 'PUB_K1_69X3383RzBZj41k73CSjUNXM5MYGpnDxyPnWUKPEtYQmVzqTY7' ]
小插曲：关于block.timestamp 与 expiration的处理在第②步的代码注释中分析到了，expiration的正确取值直接影响到了rpc的getRequiredKeys方法的调用，否则会报错：“Invalid Transaction”，这是由于事务体属性字段出错导致。另外时区的问题也要注意，new Date得到的是UTC时间，客户端一般可根据自己所在时区自动调整。
④本地签名
signatureProvider.sign({ // 本地签名。
chainId: chainId,
requiredKeys: reKeys,
serializedTransaction: sTransaction
}).then(function (signedTrx) {
console.log(signedTrx);
});
注意，这部分代码要代替第③步中的console.log(reKeys);，以达到回调顺序依赖的效果。得到的签名事务的结果如下：
{
signatures: ['SIG_K1_Khut1qkaDDeL26VVT4nEqa6vzHf2wgy5uk3dwNF1Fei9GM1c8JvonZswMdc3W5pZmvNnQeEeLLgoCwqaYMtstV3h5YyesV'],
serializedTransaction: Uint8Array[117, 185, 91, 93, 114, 182, 131, 21, 248, 224, 0, 0, 0, 0, 1, 96, 140, 49, 198, 24, 115, 21, 214, 0, 0, 0, 0, 0, 0, 128, 107, 1, 96, 140, 49, 198, 24, 115, 21, 214, 0, 0, 0, 0, 168, 237, 50, 50, 8, 0, 0, 0, 87, 101, 195, 141, 194, 0]
}
注意是由signatures和serializedTransaction两个属性构成的。
⑤推送事务
push_transaction方法的参数与第④步得到的结果结构是一致的，因此该对象可以直接被推送。
rpc.push_transaction(signedTrx).then(function (result) {
console.log(result);
})
注意，这部分代码要代替第④步中的console.log(signedTrx);，以达到回调顺序依赖的效果。得到推送结果为：
{
transaction_id: '4bc089165103879c4fcfc5331c8b03402e8206f8030c0c53374d31f5a1b35688',
processed: {
id: '4bc089165103879c4fcfc5331c8b03402e8206f8030c0c53374d31f5a1b35688',
block_num: 47078,
block_time: '2019-08-20T09:15:24.000',
producer_block_id: null,
receipt: {
status: 'executed',
cpu_usage_us: 800,
net_usage_words: 13
},
elapsed: 800,
net_usage: 104,
scheduled: false,
action_traces: [
[Object]
],
except: null
}
}
注意receipt响应值中包含了status: 'executed的内容，这个属性将是下文着重提及的。
源码位置
小结
事务的打包与签名是在客户端通过eosjs等工具完成的。从应用角度来看，直接使用api提供的transact是最简单的方法，但如果要理解其中的逻辑，可以自行编写一遍，但没必要重新做封装，毕竟transact已经有了。
节点的处理：校验、执行和广播
经过上一节，请求从客户端发出来到达了RPC供应商。RPC服务的提供者包括出块节点和非出块节点，一般来讲是非出块节点。非出块节点也会通过EOSIO/eos搭建一个nodeos服务，可以配置选择自己同步的数据区域，不具备出块能力。非出块节点如果想具备释放RPC服务的能力，需要配置chain_api_plugin，http_plugin。这部分内容可以转到《EOS行为核心：解析插件chain_plugin》详述。
push_transaction的返回结构体与上一节的响应数据体是一致的。
struct push_transaction_results {
chain::transaction_id_type transaction_id;
fc::variant processed;
};
记住这两个字段，然后向上滑动一点点，观察具体的响应数据内容。
关于RPC的push_transaction方法的论述链接。继承这篇文章的内容，下面进行补充。
transaction_async
事务的同步是通过transaction_async方法完成的，调用关系是chain_plugin插件通过method机制跳转到producer_plugin中。
此时事务停留在非出块节点的chain_plugin.cpp的void read_write::push_transaction方法中。除了传入的事务体对象参数外，还有作为回调接收响应的push_transaction_results结构的实例next。进入函数体，首先针对传入的参数对象params（具体内容参见上一节④本地签名最后的签名事务），转为transaction_metadata的实例ptrx。接下来调用
app().get_method<incoming::methods::transaction_async>()
这是method模板的语法，方法后紧跟传入等待同步的参数ptrx等以及一个result接收结果的对象（result由非出块节点接收，这部分将在下一小节展开）。transaction_async作为method的Key值，被声明在incoming::methods::transaction_async命名空间下。app应用实例的method集合中曾经注册过该Key值，注册的方式是关联一个handle provider。这段注册的代码位于producer_plugin.cpp，
incoming::methods::transaction_async::method_type::handle _incoming_transaction_async_provider;
该provider内容实际上是调用了producer_plugin.cpp的on_incoming_transaction_async方法，正在同步进来的事务。接下来调用process_incoming_transaction_async方法，处理正在进入的事务同步。这个方法首先会判断当前节点是否正在出块，如果未出块则进入_pending_incoming_transactions容器，这是一个双队列结构。
这些等待中的事务将会在出块节点开始出块时通过start_block方法触发重新回到process_incoming_transaction_async方法进行打包。
transaction_ack
当接收全节点同步过来的事务的出块节点处于当值轮次时，会将接收的事务立即向其他节点（包括非出块节点）进行广播，主要通过channel机制跳转到net_plugin中。
目前事务停留在当值出块节点的producer_plugin的process_incoming_transaction_async方法中。transaction_ack作为channel号被声明在producer插件的compat::channels::transaction_ack命名空间下。这个channel是由net_plugin订阅。
channels::transaction_ack::channel_type::handle incoming_transaction_ack_subscription;
这个频道的订阅器是net插件确认正在进来的事务。订阅器的实现方法绑定在net_plugin_impl::transaction_ack方法上。
my->incoming_transaction_ack_subscription = app().get_channel<channels::transaction_ack>().subscribe(boost::bind(&net_plugin_impl::transaction_ack, my.get(), _1));
进入net_plugin_impl::transaction_ack方法。
/**
* @brief 出块节点确认事务
*
* @param results 二元组pair类型，第一个元素为异常信息，第二个元素为事务数据。
*/
void net_plugin_impl::transaction_ack(const std::pair<fc::exception_ptr, transaction_metadata_ptr>& results) {
const auto& id = results.second->id; // 从事务体中得到事务id。
if (results.first) { //如果存在异常情况则拒绝广播该事务。
fc_ilog(logger,"signaled NACK, trx-id = ${id} : ${why}",("id", id)("why", results.first->to_detail_string()));
dispatcher->rejected_transaction(id);
} else { // 无异常情况，广播该事务。打印事务确认消息，到这一步就说明当前节点完成了确认
fc_ilog(logger,"signaled ACK, trx-id = ${id}",("id", id));
dispatcher->bcast_transaction(results.second);
}
}
成功确认以后，调用bcast_transaction方法继续广播该事务。
/**
* @brief 事务广播给其他节点
*
* @param ptrx 事务体
*/
void dispatch_manager::bcast_transaction(const transaction_metadata_ptr& ptrx) {
std::set<connection_ptr> skips; // 相当于连接黑名单，从连接集合中跳过广播。
const auto& id = ptrx->id; // 获取事务id
auto range = received_transactions.equal_range(id); // 已接收事务集是接收其他节点广播的事务，而不是自己发起广播的事务
for (auto org = range.first; org != range.second; ++org) {
skips.insert(org->second); // 如果找到该事务，说明该事务已被其他节点优先广播，则自己不必额外处理。将事务连接插入skips集合。
}
received_transactions.erase(range.first, range.second); // 删除已接收事务集中该事务，逻辑清空。
// 在本地事务集local_txns中查询，若找到则直接退出，说明该事务已完成广播共识。
if( my_impl->local_txns.get<by_id>().find( id ) != my_impl->local_txns.end() ) {
fc_dlog(logger, "found trxid in local_trxs" );
return;
}
// 将事务插入到本地事务集local_txns
time_point_sec trx_expiration = ptrx->packed_trx->expiration();
const packed_transaction& trx = *ptrx->packed_trx;
auto buff = create_send_buffer( trx );
node_transaction_state nts = {id, trx_expiration, 0, buff};
my_impl->local_txns.insert(std::move(nts));
// 符合广播条件，开始广播。
my_impl->send_transaction_to_all( buff, [&id, &skips, trx_expiration](const connection_ptr& c) -> bool {
if( skips.find(c) != skips.end() || c->syncing ) {
return false; // 若该事务已被其他节点优先广播，则自己不做处理。
}
const auto& bs = c->trx_state.find(id);
bool unknown = bs == c->trx_state.end();
if( unknown ) { // trx_state未找到事务，则插入。
c->trx_state.insert(transaction_state({id,0,trx_expiration}));
fc_dlog(logger, "sending trx to ${n}", ("n",c->peer_name() ) );
}
return unknown;
});
}
继续，进入send_transaction_to_all方法，查看广播的具体实现。net插件维护了一个connections集合，该集合动态维护了全网节点的p2p连接情况。
/**
* @brief 模板方法：发送事务给全体成员
*
* @tparam VerifierFunc 模板类
* @param send_buffer 事务数据
* @param verify 模板类实例
*/
template<typename VerifierFunc>
void net_plugin_impl::send_transaction_to_all(const std::shared_ptr<std::vector<char>>& send_buffer, VerifierFunc verify) {
for( auto &c : connections) {
if( c->current() && verify( c )) { // 在上面的使用中，就是检查是否在skips集合中。
// 进入连接队列，建立连接，发送消息。
c->enqueue_buffer( send_buffer, true, priority::low, no_reason ); // enqueue_buffer->queue_write->do_queue_write->boost::asio::async_write
}
}
}
最终的建立socket连接并发送数据的过程在注释中已体现：enqueue_buffer -> queue_write -> do_queue_write -> boost::asio::async_write，不再深入源码详细讨论。
process_incoming_transaction_async
void net_plugin_impl::transaction_ack方法中的参数二元组对象results是由process_incoming_transaction_async方法体中对transaction_ack频道发布的数据。上一小节详细分析了transaction_ack频道的订阅处理，这一小节回到process_incoming_transaction_async方法分析transaction_ack频道的信息发布。该方法体内部首先定义了一个send_response方法。
auto send_response = [this, &trx, &chain, &next](const fc::static_variant<fc::exception_ptr, transaction_trace_ptr>& response) {
next(response); // 通过next方法将response传回客户端。
if (response.contains<fc::exception_ptr>()) { // 响应内容中有异常情况出现，则发布数据中的第一个元素为异常对象，作为transaction_ack在net插件中的result.first数据。
_transaction_ack_channel.publish(priority::low, std::pair<fc::exception_ptr, transaction_metadata_ptr>(response.get<fc::exception_ptr>(), trx));
if (_pending_block_mode == pending_block_mode::producing) { // 如果当前节点正在出块，则打印日志区块拒绝该事务。
fc_dlog(_trx_trace_log, "[TRX_TRACE] Block ${block_num} for producer ${prod} is REJECTING tx: ${txid} : ${why} ",
("block_num", chain.head_block_num() + 1)
("prod", chain.pending_block_producer())
("txid", trx->id)
("why",response.get<fc::exception_ptr>()->what())); // why的值为拒绝该事务的原因，即打印出异常对象的可读信息。
} else { // 如果当前节点尚未出块，则打印未出块节点的推测执行：拒绝该事务。
fc_dlog(_trx_trace_log, "[TRX_TRACE] Speculative execution is REJECTING tx: ${txid} : ${why} ",
("txid", trx->id)
("why",response.get<fc::exception_ptr>()->what())); // 同样打印异常
}
} else { // 如果响应内容中无异常，说明成功执行，则第一个元素为空。
_transaction_ack_channel.publish(priority::low, std::pair<fc::exception_ptr, transaction_metadata_ptr>(nullptr, trx));
if (_pending_block_mode == pending_block_mode::producing) { // 如果当前节点正在出块，则打印日志区块接收该事务。
fc_dlog(_trx_trace_log, "[TRX_TRACE] Block ${block_num} for producer ${prod} is ACCEPTING tx: ${txid}",
("block_num", chain.head_block_num() + 1)
("prod", chain.pending_block_producer())
("txid", trx->id));
} else { // 如果当前节点尚未出块，则打印未出块节点的推测执行：接收该事务。
fc_dlog(_trx_trace_log, "[TRX_TRACE] Speculative execution is ACCEPTING tx: ${txid}",
("txid", trx->id));
}
}
};
从send_response方法的定义可以看出，第二个参数永远是事务体本身，这是不变的。而第一个参数是否包含异常信息是不确定的，取决于调用者的传入情况。所以接下来实际上是对事务状态的判断，从而影响传给send_response方法的第一个参数是否包含异常。这些异常情况包括：
- 事务超时过期，通过将事务过期时间与当前最新区块时间对比即可，若小于最新区块时间则判定事务过期。
- 事务重复，在当前节点的db中寻找是否有相同事务id的存在，若存在则说明事务重复。
- 事务执行时出错:
- 全节点配置为只读模式的，不可以处理推送事务。
- 不允许忽略检查以及延迟事务。
- 内部执行错误，例如权限问题，资源问题，事务进入合约内部校验错误等，详细内容看下面对controller::push_transaction方法的分析。
controller::push_transaction
/**
* @brief 这是新事务进入区块状态的进入点。将会检查权限，是否立即执行或延迟执行。
* 最后，将事务返回体插入到等待中的区块。
*
* @param trx 事务体
* @param deadline 截止时间
* @param billed_cpu_time_us CPU抵押时间
* @param explicit_billed_cpu_time CPU抵押时间是否明确，一般是false，未显式指定
*
* @return transaction_trace_ptr 事务跟踪，返回的结构体对象
*/
transaction_trace_ptr push_transaction( const transaction_metadata_ptr& trx,
fc::time_point deadline,
uint32_t billed_cpu_time_us,
bool explicit_billed_cpu_time = false )
{
EOS_ASSERT(deadline != fc::time_point(), transaction_exception, "deadline cannot be uninitialized"); // 截止时间的格式出现问题
transaction_trace_ptr trace; // 定义事务跟踪实例。
try {
auto start = fc::time_point::now();
const bool check_auth = !self.skip_auth_check() && !trx->implicit; // implicit事务会忽略检查也可以自己设置跳过auth检查，则check_auth 为false。
// 得到要使用的cpu的时间值。
const fc::microseconds sig_cpu_usage = check_auth ? std::get<0>( trx->recover_keys( chain_id ) ) : fc::microseconds();
// 得到权限的公钥
const flat_set<public_key_type>& recovered_keys = check_auth ? std::get<1>( trx->recover_keys( chain_id ) ) : flat_set<public_key_type>();
if( !explicit_billed_cpu_time ) { // 未显式指定CPU抵押时间。
// 计算已消费CPU时间
fc::microseconds already_consumed_time( EOS_PERCENT(sig_cpu_usage.count(), conf.sig_cpu_bill_pct) );
if( start.time_since_epoch() < already_consumed_time ) {
start = fc::time_point();
} else {
start -= already_consumed_time;
}
}
const signed_transaction& trn = trx->packed_trx->get_signed_transaction();
transaction_context trx_context(self, trn, trx->id, start);
if ((bool)subjective_cpu_leeway && pending->_block_status == controller::block_status::incomplete) {
trx_context.leeway = *subjective_cpu_leeway;
}
trx_context.deadline = deadline;
trx_context.explicit_billed_cpu_time = explicit_billed_cpu_time;
trx_context.billed_cpu_time_us = billed_cpu_time_us;
trace = trx_context.trace;
try {
if( trx->implicit ) { // 忽略检查的事务的处理办法
trx_context.init_for_implicit_trx(); // 检查事务资源（CPU和NET）可用性。
trx_context.enforce_whiteblacklist = false;
} else {
bool skip_recording = replay_head_time && (time_point(trn.expiration) <= *replay_head_time);
// 检查事务资源（CPU和NET）可用性。
trx_context.init_for_input_trx( trx->packed_trx->get_unprunable_size(),
trx->packed_trx->get_prunable_size(),
skip_recording);
}
trx_context.delay = fc::seconds(trn.delay_sec);
if( check_auth ) {
authorization.check_authorization( // 权限校验
trn.actions,
recovered_keys,
{},
trx_context.delay,
[&trx_context](){ trx_context.checktime(); },
false
);
}
trx_context.exec(); // 执行事务上下文，合约方法内部的校验错误会在这里抛出，使事务行为在当前节点的链上生效。
trx_context.finalize(); // 资源处理，四舍五入，自动扣除并更新账户的资源情况。
auto restore = make_block_restore_point();
if (!trx->implicit) {
transaction_receipt::status_enum s = (trx_context.delay == fc::seconds(0))
? transaction_receipt::executed
: transaction_receipt::delayed;
trace->receipt = push_receipt(*trx->packed_trx, s, trx_context.billed_cpu_time_us, trace->net_usage);
pending->_block_stage.get<building_block>()._pending_trx_metas.emplace_back(trx);
} else { // 以上代码段都包含在try异常监控的作用域中，因此如果到此仍未发生异常而中断，则判断执行成功。
transaction_receipt_header r;
r.status = transaction_receipt::executed; // 注意：这就是客户端接收到的那个非常重要的状态executed。
r.cpu_usage_us = trx_context.billed_cpu_time_us;
r.net_usage_words = trace->net_usage / 8;
trace->receipt = r;
}
fc::move_append(pending->_block_stage.get<building_block>()._actions, move(trx_context.executed));
if (!trx->accepted) {
trx->accepted = true;
emit( self.accepted_transaction, trx); // 发射接收事务的信号
}
emit(self.applied_transaction, std::tie(trace, trn));
if ( read_mode != db_read_mode::SPECULATIVE && pending->_block_status == controller::block_status::incomplete ) {
trx_context.undo(); // 析构器，undo撤销操作。
} else {
restore.cancel();
trx_context.squash(); // 上下文刷新
}
if (!trx->implicit) {
unapplied_transactions.erase( trx->signed_id );
}
return trace;
} catch( const disallowed_transaction_extensions_bad_block_exception& ) {
throw;
} catch( const protocol_feature_bad_block_exception& ) {
throw;
} catch (const fc::exception& e) {
trace->error_code = controller::convert_exception_to_error_code( e );
trace->except = e;
trace->except_ptr = std::current_exception();
}
if (!failure_is_subjective(*trace->except)) {
unapplied_transactions.erase( trx->signed_id );
}
emit( self.accepted_transaction, trx ); // 发射接收事务的信号，触发controller相关信号操作
emit( self.applied_transaction, std::tie(trace, trn) ); // 发射应用事务的信号，触发controller相关信号操作
return trace;
} FC_CAPTURE_AND_RETHROW((trace))
} /// push_transaction
信号方面的内容请转到controller的信号。
小结
我们知道，非出块节点和出块节点使用的是同一套代码部署的nodeos程序，然而非出块节点可以配置是否要只读模式，还是推测模式。所谓只读模式，是不做数据上传的，只能查询，不能新增，它的数据结构只保留不可逆区块的内容，十分简单。而推测模式是可以处理并推送事务的，它的数据结构除了不可逆区块的内容以外，还有可逆区块的内容。所以非出块节点是具备事务校验、本地执行以及广播的能力的，只是不具备区块打包的能力，到了区块层面的问题要到出块节点来解决。事务的广播和确认并不需要共识的存在，共识的发生是针对区块的，而区块打包是由出块节点来负责，因此区块共识只在出块节点之间完成。而事务的广播和确认只是单纯的接收事务，散发事务而已，可以在所有节点中完成。
出块节点的处理：打包区块、共识、不可逆
本节请参考文章EOS生产区块：解析插件producer_plugin。
前面介绍了事务的产生、执行、散发的过程，而事务被打包进区块的过程没有说明，可以参照start_block函数。这样，事务在区块链中就走完了完整过程。
本文仅代表作者观点，有疏漏部分欢迎讨论，经讨论正确的会自行更正。