摘要：區(qū)塊多線程簽名改動(dòng)同步區(qū)塊時(shí)進(jìn)行多線程簽名，過(guò)程中依然是單線程簽名。代碼解析塊簽名因?yàn)椴贿m用多線程簽名，所以依舊沿用之前的簽名代碼，而同步則使用了新的部分。當(dāng)大家比較關(guān)注的使用并沒有得到改善，因?yàn)槎嗑€程簽名無(wú)法應(yīng)該在生產(chǎn)區(qū)塊上。

昨天早上，EOS 1.5.0 release 版本發(fā)布了。這次比較大改動(dòng)點(diǎn)是在多線程簽名上面。它將同步區(qū)塊時(shí)的 block 簽名驗(yàn)證和 trx 簽名驗(yàn)證都使用多線程簽名驗(yàn)證，來(lái)節(jié)省同步所需要的時(shí)間， 但是生產(chǎn)區(qū)塊所需要的成本是不變的，但為什么生產(chǎn)區(qū)塊成本不變呢。接下來(lái)介紹一下具體的改動(dòng)。

 區(qū)塊多線程簽名改動(dòng)：同步區(qū)塊時(shí)進(jìn)行多線程簽名， replay 過(guò)程中依然是單線程簽名。因?yàn)閰^(qū)塊同步時(shí)需要回滾 pending block 的 trx 操作, 這塊時(shí)間剛好可以用來(lái)并行處理簽名， 但 replay 的時(shí)候沒有這一步，即使用多線程簽名也無(wú)法節(jié)省時(shí)間，反而會(huì)讓主線程阻塞等待異步結(jié)果返回。

 trx 多線程簽名改動(dòng)：同步區(qū)塊以及 replay 過(guò)程都會(huì)進(jìn)行多線程簽名， 因?yàn)橛卸鄠€(gè) trx 要執(zhí)行，所以執(zhí)行 trx 的時(shí)間可以供其他 trx 的簽名并行進(jìn)行。 但生產(chǎn)區(qū)塊的時(shí)候無(wú)法使用，因?yàn)閳?zhí)行 BP 接受到一個(gè) 廣播的 trx 就立馬去執(zhí)行了，執(zhí)行完之后才回去接受下一個(gè)廣播 trx, 所以無(wú)法使用多線程簽名。

因?yàn)?replay 不適用多線程簽名， 所以 replay 依舊沿用之前的簽名代碼， 而同步則使用了新的部分。

// producer_plugin.cpp 接受到廣播塊
void on_incoming_block(const signed_block_ptr& block) {
   // ...

   // start processing of block
   // 調(diào)用一個(gè)線程去對(duì)塊進(jìn)行簽名驗(yàn)證
   auto bsf = chain.create_block_state_future( block );

   // abort the pending block
   // 回滾掉 pending block 的執(zhí)行 trx， 這段時(shí)間剛好可以用來(lái)并發(fā)執(zhí)行區(qū)塊簽名驗(yàn)證
   chain.abort_block();

   // ...
}

// controller.cpp
std::future create_block_state_future( const signed_block_ptr& b ) {

   //驗(yàn)證區(qū)塊是否存在。
   EOS_ASSERT( b, block_validate_exception, "null block" );

   auto id = b->id();

   // no reason for a block_state if fork_db already knows about block
   auto existing = fork_db.get_block( id );
   EOS_ASSERT( !existing, fork_database_exception, "we already know about this block: ${id}", ("id", id) );

   auto prev = fork_db.get_block( b->previous );
   EOS_ASSERT( prev, unlinkable_block_exception, "unlinkable block ${id}", ("id", id)("previous", b->previous) );

   // 進(jìn)行多線程簽名
   return async_thread_pool( [b, prev]() {
      const bool skip_validate_signee = false;
      return std::make_shared( *prev, move( b ), skip_validate_signee );
   } );
}

void push_block( std::future& block_state_future ) {
   controller::block_status s = controller::block_status::complete;
   EOS_ASSERT(!pending, block_validate_exception, "it is not valid to push a block when there is a pending block");

   auto reset_prod_light_validation = fc::make_scoped_exit([old_value=trusted_producer_light_validation, this]() {
      trusted_producer_light_validation = old_value;
   });
   try {
      // 獲取驗(yàn)證結(jié)果， 當(dāng)區(qū)塊驗(yàn)證失敗時(shí)會(huì)拋出異常，中止 push block
      block_state_ptr new_header_state = block_state_future.get();
      auto& b = new_header_state->block;
      emit( self.pre_accepted_block, b );

      fork_db.add( new_header_state, false );

      if (conf.trusted_producers.count(b->producer)) {
         trusted_producer_light_validation = true;
      };
      emit( self.accepted_block_header, new_header_state );

      if ( read_mode != db_read_mode::IRREVERSIBLE ) {
         maybe_switch_forks( s );
      }

   } FC_LOG_AND_RETHROW( )
}

從改動(dòng)得知，apply_block 的時(shí)候才會(huì)啟動(dòng)交易的多線程驗(yàn)證簽名，而 bcast_transaction 則不會(huì),因?yàn)椴]有多余的動(dòng)作可以與驗(yàn)證簽名并行。

void apply_block( const signed_block_ptr& b, controller::block_status s ) { try {
   try {
      EOS_ASSERT( b->block_extensions.size() == 0, block_validate_exception, "no supported extensions" );
      auto producer_block_id = b->id();
      start_block( b->timestamp, b->confirmed, s , producer_block_id);

      // 按順序啟動(dòng)每個(gè) trx 的多線程驗(yàn)證簽名，生產(chǎn)對(duì)應(yīng)公鑰
      std::vector packed_transactions;
      packed_transactions.reserve( b->transactions.size() );
      for( const auto& receipt : b->transactions ) {
         if( receipt.trx.contains()) {
            auto& pt = receipt.trx.get();
            auto mtrx = std::make_shared( pt );
            if( !self.skip_auth_check() ) {
               std::weak_ptr mtrx_wp = mtrx;
               mtrx->signing_keys_future = async_thread_pool( [chain_id = this->chain_id, mtrx_wp]() {
                  auto mtrx = mtrx_wp.lock();
                  return mtrx ?
                         std::make_pair( chain_id, mtrx->trx.get_signature_keys( chain_id ) ) :
                         std::make_pair( chain_id, decltype( mtrx->trx.get_signature_keys( chain_id ) ){} );
               } );
            }
            packed_transactions.emplace_back( std::move( mtrx ) );
         }
      }

      // 執(zhí)行 trx
      // ...

      commit_block(false);
      return;
   } catch ( const fc::exception& e ) {
      edump((e.to_detail_string()));
      abort_block();
      throw;
   }
} FC_CAPTURE_AND_RETHROW() } /// apply_block

// trx 執(zhí)行時(shí)獲取簽名返回的公鑰
const flat_set& recover_keys( const chain_id_type& chain_id ) {
   // Unlikely for more than one chain_id to be used in one nodeos instance
   if( !signing_keys || signing_keys->first != chain_id ) {
      if( signing_keys_future.valid() ) {
         // 獲取公鑰，如果未簽名完則阻塞等待簽名完畢
         signing_keys = signing_keys_future.get();
         if( signing_keys->first == chain_id ) {
            return signing_keys->second;
         }
      }
      // 當(dāng)沒開啟多線程簽名時(shí), 直接驗(yàn)證生成對(duì)應(yīng)公鑰
      signing_keys = std::make_pair( chain_id, trx.get_signature_keys( chain_id ));
   }
   return signing_keys->second;
}

    從這次的改動(dòng)可以看出主要優(yōu)化的地方是節(jié)點(diǎn)同步區(qū)塊的速度， 因?yàn)殚_啟了多線程簽名，所以在 block 驗(yàn)證以及 apply_block 時(shí)節(jié)省了一定 CPU 時(shí)間， 可供其他地方使用。 例如 EOS 現(xiàn)在是當(dāng)線程的，所以當(dāng)你進(jìn)行 RPC 訪問的時(shí)候，如果涉及到數(shù)據(jù)提取，主線程的同步時(shí)會(huì)暫停的，等待你的操作結(jié)束， 這樣就會(huì)影響節(jié)點(diǎn)的同步，所以 get_table_rows API 才會(huì)限制 10 ms。 現(xiàn)在同步所需時(shí)間減少，降低了節(jié)點(diǎn)既要同步數(shù)據(jù)也要提供 RPC API 的壓力。

當(dāng)大家比較關(guān)注的 CPU 使用并沒有得到改善， 因?yàn)槎嗑€程簽名無(wú)法應(yīng)該在生產(chǎn)區(qū)塊上。所以在生產(chǎn)區(qū)塊時(shí)， trx 執(zhí)行所需要的 CPU 時(shí)間并不會(huì)減少，也就是 CPU 資源的使用并沒有得到改善。

EOS 開發(fā)的小伙伴有技術(shù)問題可以進(jìn)群討論喲