以太坊C++源码解析（五）区块链同步(2)

区块链同步的核心类是BlockChainSync，在继续深入了解同步流程之前，我们还是先来了解一下这个类有哪些重要成员吧。

• m_chainStartBlock & m_startingBlock & m_highestBlock
  这三个分别表示链起始块号，一般是0；需要同步的起始块号；当前所知的最大块号
• m_lastImportedBlock & m_lastImportedBlockHash
  这两个表示当前同步的最新块的块号和块hash值，在同步中我们需要知道当前同步到多少块了就是看m_lastImportedBlock这个值，这是一个重要指标。
• m_downloadingHeaders & m_downloadingBodies & m_headerSyncPeers & m_bodySyncPeers
  这几个定义稍微复杂一些：

  1 2 3 4

  std::unordered_set<unsigned> m_downloadingHeaders; ///< Set of block body numbers being downloaded std::unordered_set<unsigned> m_downloadingBodies; ///< Set of block header numbers being downloaded std::map<std::weak_ptr<EthereumPeer>, std::vector<unsigned>, std::owner_less<std::weak_ptr<EthereumPeer>>> m_headerSyncPeers; ///< Peers to m_downloadingSubchain number map std::map<std::weak_ptr<EthereumPeer>, std::vector<unsigned>, std::owner_less<std::weak_ptr<EthereumPeer>>> m_bodySyncPeers; ///< Peers to m_downloadingSubchain number map

其中m_downloadingHeaders记录当前正在同步的块头对应的块号；m_downloadingBodies记录单曲正在同步的块体对应的块号；m_headerSyncPeers在m_downloadingHeaders的基础上还记录了peer信息；m_bodySyncPeers在m_downloadingBodies的基础上记录了peer信息。

注意到这里有个模板std::owner_less<>，这个模板是用来表明如何对std::weak_ptr<EthereumPeer>进行排序的，这里有一个owner-base和value-base的概念，在一般情况下owner-base和value-base是相同的，但是在std::shared_ptr和std::weak_ptr使用
aliasing constructor(别名构造函数)时这两者不同，需要区分。
推荐两篇文件，讲得比较详细：
C++ Memory Library - owner_less
What is shared_ptr’s aliasing constructor for?

那么同步中记录这四个值有什么用呢？在这里是用来做校验的。
因为BlockChainSync类从HasInvariants类继承而来，因此继承了一个接口：

1

virtual bool invariants() const = 0;

可以在BlockChainSync::invariants()中找到答案：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

bool BlockChainSync::invariants() const
{
    if (!isSyncing() && !m_headers.empty())
        BOOST_THROW_EXCEPTION(FailedInvariant() << errinfo_comment("Got headers while not syncing"));
    if (!isSyncing() && !m_bodies.empty())
        BOOST_THROW_EXCEPTION(FailedInvariant() << errinfo_comment("Got bodies while not syncing"));
    if (isSyncing() && m_host.chain().number() > 0 && m_haveCommonHeader && m_lastImportedBlock == 0)
        BOOST_THROW_EXCEPTION(FailedInvariant() << errinfo_comment("Common block not found"));
    if (isSyncing() && !m_headers.empty() &&  m_lastImportedBlock >= m_headers.begin()->first)
        BOOST_THROW_EXCEPTION(FailedInvariant() << errinfo_comment("Header is too old"));
    if (m_headerSyncPeers.empty() != m_downloadingHeaders.empty())
        BOOST_THROW_EXCEPTION(FailedInvariant() << errinfo_comment("Header download map mismatch"));
    if (m_bodySyncPeers.empty() != m_downloadingBodies.empty() && m_downloadingBodies.size() <= m_headerIdToNumber.size())
        BOOST_THROW_EXCEPTION(FailedInvariant() << errinfo_comment("Body download map mismatch"));
    return true;
}

那么在哪里调用这个函数呢？在InvariantChecker::checkInvariants()函数里：

1
2
3
4
5
6
7
8

void InvariantChecker::checkInvariants(HasInvariants const* _this, char const* _fn, char const* _file, int _line, bool _pre)
{
    if (!_this->invariants())
    {
        cwarn << (_pre ? "Pre" : "Post") << "invariant failed in" << _fn << "at" << _file << ":" << _line;
        ::boost::exception_detail::throw_exception_(FailedInvariant(), _fn, _file, _line);
    }
}

而这个函数被定义成了两个宏：

1
2
3
4
5
6
7

#if ETH_DEBUG
#define DEV_INVARIANT_CHECK ::dev::InvariantChecker __dev_invariantCheck(this, BOOST_CURRENT_FUNCTION, __FILE__, __LINE__)
#define DEV_INVARIANT_CHECK_HERE ::dev::InvariantChecker::checkInvariants(this, BOOST_CURRENT_FUNCTION, __FILE__, __LINE__, true)
#else
#define DEV_INVARIANT_CHECK (void)0;
#define DEV_INVARIANT_CHECK_HERE (void)0;
#endif

DEV_INVARIANT_CHECK和DEV_INVARIANT_CHECK_HERE这两个宏在代码中多次调用，有兴趣可以去看看源码。

除了BlockChainSync类之外，还有一个重要类BlockQueue类也是从HasInvariants类继承而来，因而也具有check的能力。

• m_headers & m_bodies
  这两个是下载的块头和块体的缓冲区，当块头和块体不属于同一个块，因而无法合并时，被暂存在这里。

  1 2	std::map<unsigned, std::vector<Header>> m_headers; ///< Downloaded headers std::map<unsigned, std::vector<bytes>> m_bodies; ///< Downloaded block bodies

这里使用了std::map，key表示m_headers或m_bodies中连续段最低块的块号，value表示m_headers或m_bodies中存在的数据。每个std::vector中保存一个连续段的数据。以m_headers为例，假如有块5，6，7，10，13，15，16，那么在m_headers中存储为：{ {5, {块5，块6，块7} }, {10, {块10} }, {13, {块13} }, {15, {块15，块16} } }，其中5，6，7是一个连续段，存为一个pair，key为5，value为std::vector<Header>{块5，块6，块7}，块10为一个单独不连续块，那么存为一个pair，key为10，value为std::vector<Header>{块10}，以此类推，m_bodies也是一样。为了在这种数据结构中方便查找，插入和删除数据，还专门定义了专有方法，比如haveItem()，findItem()，removeItem()，removeAllStartingWith()和mergeInto()，有兴趣可以自己看下，能更深入理解这种数据结构的操作。
m_headers 和 m_bodies构成了整个区块链同步的第一级缓存，存放了刚下载下来未经校验的分离的区块头和区块体。整个区块链同步的数据流程大致如下：

• m_haveCommonHeader
  这是一个简简单单的布尔值，默认为false，但是却非常重要，它实际决定了同步块的起点，这里可能会有人问上面不是有个m_lastImportedBlock吗？难道不是每次都是从这里开始同步的吗？理论上是的，但是实际中同步区块链有个回退操作，开始时m_haveCommonHeader值为false，那么回退一个块，从m_haveCommonHeader - 1块开始同步，当m_haveCommonHeader - 1块头下载下来以后，和本地区块链或者BlockQueue中的m_haveCommonHeader - 1块做比较，如果是一样的，那么m_haveCommonHeader值设为true，证明我们之前下载的区块链和当前这个peer上下载的区块是同一条链上的，可以放心向后同步了。如果不一样，那么证明我们的区块链和peer上的区块不是在同一条链上（可能有分叉），这时候需要继续回退，下载m_haveCommonHeader - 2等等，直到m_haveCommonHeader值为true才算回退到头，这个也是区块链同步有时候会停滞的原因之一，尤其是在ropsten测试链中这种情况经常出现。除了开始同步时可能存在回退的情况，在导入块，也就是从一级缓存进入二级缓存BlockQueue时也会做检查，如果出错也可能导致回退。