摘要：在每個(gè)交易中，我們都會(huì)看到和這個(gè)參數(shù)有什么作用呢。先講下它的大致作用，再來(lái)對(duì)代碼進(jìn)行分析。這是白皮書(shū)對(duì)這個(gè)參數(shù)的作用描述他是用來(lái)防止有不包含區(qū)塊引用的交易被重放到某個(gè)分叉上，這樣能避免不是該分叉的區(qū)塊被添加到該分叉。

在每個(gè) trx 交易中，我們都會(huì)看到 ref_block_num 和 ref_block_prefix, 這2個(gè)參數(shù)有什么作用呢。

先講下它的大致作用，再來(lái)對(duì)代碼進(jìn)行分析。

這是白皮書(shū)對(duì)這2個(gè)參數(shù)的作用描述

Transaction as Proof of Stake (TaPoS)
The EOS.IO software requires every transaction to include part of the hash of a recent block header. This hash serves two purposes:

1. prevents a replay of a transaction on forks that do not include the referenced block; and
2. signals the network that a particular user and their stake are on a specific fork.
Over time all users end up directly confirming the blockchain which makes it difficult to forge counterfeit chains as the counterfeit would not be able to migrate transactions from the legitimate chain.
1. 他是用來(lái)防止有不包含區(qū)塊引用的交易被重放到某個(gè)分叉上， 這樣能避免不是該分叉的區(qū)塊被添加到該分叉。
2. 告訴用戶該塊是在哪個(gè)分支上面。

這樣做有什么作用呢？

假設(shè)現(xiàn)在有2個(gè)用戶 A 和 B， B 叫 A 說(shuō)你轉(zhuǎn) 2 個(gè) EOS 給我， 我就送你 100 個(gè) LIVE，A 說(shuō)好啊。 然后 A 就轉(zhuǎn) 2 個(gè) EOS 給 B 了， 這個(gè)時(shí)候 A 的區(qū)塊 a 還不是不可逆狀態(tài)， 如果此時(shí) B 轉(zhuǎn)給 A 100 個(gè) LIVE， 要是 區(qū)塊 a 被回滾掉了怎么辦，那么 B 就白白給了 A 100 個(gè) LIVE 了。 這時(shí)候 ref-block 的作用就體現(xiàn)了，如果區(qū)塊 a 被回滾了，那么 B 轉(zhuǎn)給 A 100 個(gè) LIVE 的區(qū)塊 b 也會(huì)被丟棄掉。 所以 當(dāng)區(qū)塊 b ref-block 是 區(qū)塊 a 的時(shí)候，只有 區(qū)塊 a 被成功打包了， 區(qū)塊 b 才會(huì)被成功打包。

所以很顯然， 這兩個(gè)參數(shù)是為了讓鏈更穩(wěn)固，也讓用戶交易更安全。

先看下 transaction_header 對(duì)這兩個(gè)字段的描述。

struct transaction_header {
  // ...
  // 可以指定 head_block_num - 0xffff ~ head_block_num 之間的塊。
  uint16_t               ref_block_num       = 0U; ///< specifies a block num in the last 2^16 blocks.
 // block_id 的按 32 bits分割的第二個(gè)部分，也就是 block_id._hash[1];
  uint32_t               ref_block_prefix    = 0UL; ///< specifies the lower 32 bits of the blockid at 
 // ...
};

再來(lái)看下該參數(shù)如何被驗(yàn)證。

 // 在 trx 初始化的時(shí)候便回去驗(yàn)證
void transaction_context::init_for_input_trx( uint64_t packed_trx_unprunable_size,
                                             uint64_t packed_trx_prunable_size,
                                             uint32_t num_signatures,
                                             bool skip_recording )
{
    //...
    if (!control.skip_trx_checks()) {
         control.validate_expiration(trx);
         control.validate_tapos(trx);
         control.validate_referenced_accounts(trx);
      }
    //...
}

void controller::validate_tapos( const transaction& trx )const { try {
   const auto& tapos_block_summary = db().get((uint16_t)trx.ref_block_num);

   //Verify TaPoS block summary has correct ID prefix, and that this block"s time is not past the expiration
   EOS_ASSERT(trx.verify_reference_block(tapos_block_summary.block_id), invalid_ref_block_exception,
              "Transaction"s reference block did not match. Is this transaction from a different fork?",
              ("tapos_summary", tapos_block_summary));
} FC_CAPTURE_AND_RETHROW() }

bool transaction_header::verify_reference_block( const block_id_type& reference_block )const {
   return ref_block_num    == (decltype(ref_block_num))fc::endian_reverse_u32(reference_block._hash[0]) &&
          ref_block_prefix == (decltype(ref_block_prefix))reference_block._hash[1];
}

從 block_summary_object 獲取的 block 數(shù)據(jù)拿來(lái)跟 ref-block 的， 很奇怪為什么不直接用 get_block 那種方式取 block 的信息呢? 這樣不用維護(hù)多一個(gè)多索引容器，而且還能獲取全部的 block 。 來(lái)看看 block_summary_object 是如何創(chuàng)建和維護(hù)的。

// libraries/chain/include/eosio/chain/block_summary_object.hpp
class block_summary_object : public chainbase::object
   {
         OBJECT_CTOR(block_summary_object)

         id_type        id;
         block_id_type  block_id;
   };

   struct by_block_id;
   using block_summary_multi_index = chainbase::shared_multi_index_container<
      block_summary_object,
      indexed_by<
         ordered_unique, BOOST_MULTI_INDEX_MEMBER(block_summary_object, block_summary_object::id_type, id)>
   //      ordered_unique, BOOST_MULTI_INDEX_MEMBER(block_summary_object, block_id_type, block_id)>
      >
   >;



// 創(chuàng)建了 id 從 0 ~ 65535 的數(shù)據(jù)
void contoller_impl::initialize_database() {
  // Initialize block summary index
  for (int i = 0; i < 0x10000; i++)
     db.create([&](block_summary_object&) {});

  // ...
}

// 每次添加新的區(qū)塊的時(shí)候都回去更新 block_summary_object 的 索引表
void contoller_impl::finalize_block()
{
  // ...

  auto p = pending->_pending_block_state;
  p->id = p->header.id();

  create_block_summary(p->id);

} FC_CAPTURE_AND_RETHROW() }

void create_block_summary(const block_id_type& id) {
  auto block_num = block_header::num_from_id(id);
  // 從這里可以看出 block_summary_object 的 id 永遠(yuǎn)都是 0 ~ 65535。也就是說(shuō)它只維護(hù) head_block_num - 0xffff ~ head_block_num 的塊， 你 ref-block 只能是這個(gè)區(qū)間的塊， 如果 ref 更早的 block 就會(huì)驗(yàn)證出錯(cuò)。
  auto sid = block_num & 0xffff;
  db.modify( db.get(sid), [&](block_summary_object& bso ) {
      bso.block_id = id;
  });
}

cleos 在 push transaction 的時(shí)候默認(rèn)的 ref-block 是取 last_irreversible_block ，當(dāng)head_block_num 跟 lib_num 相差超出 0xffff 個(gè)塊的時(shí)候就會(huì)出現(xiàn)該錯(cuò)誤：

Error 3040007: Invalid Reference Block
Ensure that the reference block exist in the blockchain!
Error Details:
Transaction"s reference block did not match. Is this transaction from a different fork?

如果你的私鏈出現(xiàn)問(wèn)題，檢查你鏈上有沒(méi) 2/3 個(gè) BP 在出塊，如果沒(méi)有則是因?yàn)闆](méi)確認(rèn)塊，導(dǎo)致 head_block 和 lib 之間超過(guò)了 0xffff 個(gè)塊而導(dǎo)致該錯(cuò)誤。

結(jié)論: ref-block 的主要作用從白皮書(shū)可以看出，它是為了建立一條難以造假的鏈， 因?yàn)槠渌溸`法從 合法鏈鏈直接遷移交易，只能添加交易。每個(gè) block 都會(huì) ref-block 前面的數(shù)據(jù)， 你也無(wú)法直接 ref-block 的早期的塊，因?yàn)橹荒?ref-block 只能是從 head_block_num - 0xffff ~ head_block_num， 像比特幣，只要你算力足夠，你從第一個(gè)塊重新建造一條鏈都可以。 并且他告訴用戶當(dāng)前交易是在哪個(gè)分叉上， 這樣用戶可以根據(jù)交易需要在哪條分叉上成功來(lái)指定分叉， 也就是我們上面舉的例子。

原文: https://eos.live/detail/17094