前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >EOS源码分析:transaction的一生

EOS源码分析:transaction的一生

作者头像
文彬
发布2019-08-23 16:09:40
1.5K0
发布2019-08-23 16:09:40
举报
文章被收录于专栏:醒者呆

最近在处理智能合约的事务上链问题,发现其中仍旧有知识盲点。原有的认识是一个事务请求会从客户端设备打包签名,然后通过RPC传到非出块节点,广播给超级节点,校验打包到可逆区块,共识确认最后变为不可逆区块。在执行事务完毕以后给客户端一个“executed”的状态响应。基于这个认识,本文将通过最新EOS代码详细分析验证。 关键字:EOS,区块链,eosjs,transaction,签名,节点,出块节点,事务校验,事务广播

客户端的处理:打包与签名

客户端设备可以通过eosjs完成本地的事务体构建。下面以调用hello智能合约为例。

注意:eosio.cdt的hello合约中hi方法的参数名为nm,而不是user,我们下面采用与cdt相一致的方式。

方便起见,可以首先使用eosjs-api提供的transact方法,它可以帮助我们直接将事务体打包签名并推送出去。

代码语言:javascript
复制
(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的结构与前面是相同的。

代码语言:javascript
复制
// 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的值压缩(可理解为密文传输参数以及参数的值),最终变为:

代码语言:javascript
复制
[{
    account: 'useraaaaaaaa',
    name: 'hi',
    authorization: [{
        actor: 'useraaaaaaaa',
        permission: 'active'
    }],
    data: '0000005765C38DC2'
}]

②打包Transaction

首先设置事务Transactions的属性字段。

代码语言:javascript
复制
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类型的数组,这就是事务压缩完成的值。

代码语言:javascript
复制
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,比对找到对应密钥。

代码语言:javascript
复制
signatureProvider.getAvailableKeys().then(function (avKeys) { // 获得本地可用密钥
    // 查询事务必须密钥
    rpc.getRequiredKeys({transaction: transaction, availableKeys: avKeys}).then(function (reKeys) {
        // 匹配成功:本地可用密钥库中包含事务必须密钥
        console.log(reKeys);
    });
});

由于执行结果存在先后的依赖关系,因此要采用回调嵌套的方式调用。最后成功获得匹配的密钥:

代码语言:javascript
复制
[ 'PUB_K1_69X3383RzBZj41k73CSjUNXM5MYGpnDxyPnWUKPEtYQmVzqTY7' ]

小插曲:关于block.timestamp 与 expiration的处理在第②步的代码注释中分析到了,expiration的正确取值直接影响到了rpc的getRequiredKeys方法的调用,否则会报错:“Invalid Transaction”,这是由于事务体属性字段出错导致。另外时区的问题也要注意,new Date得到的是UTC时间,客户端一般可根据自己所在时区自动调整。

④本地签名

代码语言:javascript
复制
signatureProvider.sign({ // 本地签名。
    chainId: chainId,
    requiredKeys: reKeys,
    serializedTransaction: sTransaction
}).then(function (signedTrx) {
    console.log(signedTrx);
});

注意,这部分代码要代替第③步中的console.log(reKeys);,以达到回调顺序依赖的效果。得到的签名事务的结果如下:

代码语言:javascript
复制
{
    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方法的参数与第④步得到的结果结构是一致的,因此该对象可以直接被推送。

代码语言:javascript
复制
rpc.push_transaction(signedTrx).then(function (result) {
    console.log(result);
})

注意,这部分代码要代替第④步中的console.log(signedTrx);,以达到回调顺序依赖的效果。得到推送结果为:

代码语言:javascript
复制
{
    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的返回结构体与上一节的响应数据体是一致的。

代码语言:javascript
复制
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。接下来调用

代码语言:javascript
复制
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,

代码语言:javascript
复制
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订阅。

代码语言:javascript
复制
channels::transaction_ack::channel_type::handle  incoming_transaction_ack_subscription;

这个频道的订阅器是net插件确认正在进来的事务。订阅器的实现方法绑定在net_plugin_impl::transaction_ack方法上。

代码语言:javascript
复制
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方法。

代码语言:javascript
复制
/**
 * @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方法继续广播该事务。

代码语言:javascript
复制
/**
 * @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连接情况。

代码语言:javascript
复制
/**
 * @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方法。

代码语言:javascript
复制
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方法的第一个参数是否包含异常。这些异常情况包括:

  1. 事务超时过期,通过将事务过期时间与当前最新区块时间对比即可,若小于最新区块时间则判定事务过期。
  2. 事务重复,在当前节点的db中寻找是否有相同事务id的存在,若存在则说明事务重复。
  3. 事务执行时出错:
    1. 全节点配置为只读模式的,不可以处理推送事务。
    2. 不允许忽略检查以及延迟事务。
    3. 内部执行错误,例如权限问题,资源问题,事务进入合约内部校验错误等,详细内容看下面对controller::push_transaction方法的分析。

controller::push_transaction

代码语言:javascript
复制
/**
 * @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函数。这样,事务在区块链中就走完了完整过程。

本文仅代表作者观点,有疏漏部分欢迎讨论,经讨论正确的会自行更正。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2019-08-22 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 客户端的处理:打包与签名
    • ①打包Actions
      • ②打包Transaction
        • ③准备密钥
          • ④本地签名
            • ⑤推送事务
              • 源码位置
                • 小结
                • 节点的处理:校验、执行和广播
                  • transaction_async
                    • transaction_ack
                      • process_incoming_transaction_async
                        • controller::push_transaction
                          • 小结
                          • 出块节点的处理:打包区块、共识、不可逆
                          相关产品与服务
                          区块链
                          云链聚未来,协同无边界。腾讯云区块链作为中国领先的区块链服务平台和技术提供商,致力于构建技术、数据、价值、产业互联互通的区块链基础设施,引领区块链底层技术及行业应用创新,助力传统产业转型升级,推动实体经济与数字经济深度融合。
                          领券
                          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档