BSC 验证者获取接口的时间差问题分析 - 若

问题描述

在使用 BSC 网络时，遇到了一个有趣的问题：

 

# 通过 parlia.getValidators() 获取验证者
jayzhan@7e286d34ecbd osc % ./build/bin/geth --exec "parlia.getValidators()" attach http://localhost:8545
["0xa0754ecdd8c0867986e462ddc97089bd21a3cc1e", "0xb17a1bd545b45a918bf6b0450e88b9cafc0914a9", "0xb6cb6ecb011c7a72b1926ed3bf4ed04e6e2e67e3"]

 

返回了 3 个验证者，但是通过 StakeHub 更新 BscValidatorSet 的 updateValidatorSetV2 为 1 个验证者后，parlia.getValidators() 仍然返回 3 个验证者。

问题根源分析

两个不同的验证者获取路径

在 BSC 网络中，存在两个获取验证者信息的不同路径：

路径一：parlia.getValidators() API

// consensus/parlia/api.go
func (api *API) GetValidators(number *rpc.BlockNumber) ([]common.Address, error) {
    header := api.getHeader(number)
    snap, err := api.parlia.snapshot(api.chain, header.Number.Uint64(), header.Hash(), nil)
    if err != nil {
        return nil, err
    }
    return snap.validators(), nil
}

 

这个 API 通过以下步骤获取验证者：

1. 获取指定区块头

2. 创建该区块的快照

3. 从快照中提取验证者列表

4. 返回的验证者信息来自于区块头的 Extra 字段

路径二：BscValidatorSet.getValidators() 合约调用

直接调用 BscValidatorSet 智能合约的 getValidators 方法，返回合约当前状态中存储的验证者列表。

验证者信息的更新机制

区块头中的验证者信息更新：

// consensus/parlia/parlia.go
func (p *Parlia) prepareValidators(chain consensus.ChainHeaderReader, header *types.Header) error {
    epochLength, err := p.epochLength(chain, header, nil)
    if err != nil {
        return err
    }
    if header.Number.Uint64()%epochLength != 0 {
        return nil
    }
    
    newValidators, voteAddressMap, err := p.getCurrentValidators(header.ParentHash, new(big.Int).Sub(header.Number, big.NewInt(1)))
    // ... 将验证者信息写入区块头的 Extra 字段
}

 

• 更新发生在每个 epoch 区块（通常是每 200 个区块）

• 调用 getCurrentValidators 从 BscValidatorSet 合约获取当前验证者

• 将验证者信息写入区块头的 Extra 字段

BscValidatorSet 合约中的验证者信息更新：

// consensus/parlia/parlia.go
if p.chainConfig.IsFeynman(header.Number, header.Time) && isBreatheBlock(parent.Time, header.Time) {
    if err := p.updateValidatorSetV2(state, header, cx, txs, receipts, systemTxs, usedGas, false, tracer); err != nil {
        return err
    }
}

 

• 通过 updateValidatorSetV2 函数更新

• 更新发生在每个呼吸区块（每 24 小时一次）

• 从 StakeHub 合约获取最新的验证者选举信息并更新到 BscValidatorSet 合约

时间差导致的问题

呼吸区块判断逻辑：

// consensus/parlia/feynmanfork.go
func isBreatheBlock(lastBlockTime, blockTime uint64) bool {
    return lastBlockTime != 0 && !sameDayInUTC(lastBlockTime, blockTime)
}func sameDayInUTC(first, second uint64) bool {
    return first/params.BreatheBlockInterval == second/params.BreatheBlockInterval
}// params/protocol_params.go
BreatheBlockInterval uint64 = 24 * 3600 // 24小时

 

问题根源：

1. updateValidatorSetV2 每 24 小时执行一次，更新 BscValidatorSet 合约中的验证者列表为 1 个

2. 区块头中的验证者信息只有在 epoch 区块（每 200 个区块）才会更新

3. 如果最近的 epoch 区块发生在 updateValidatorSetV2 更新之前，区块头中仍然包含旧的 3 个验证者信息

4. parlia.getValidators() 读取的是区块头中的信息，所以仍然返回 3 个验证者

时间线分析

时间轴：

T1: 最近的 epoch 区块，区块头写入 3 个验证者

T2: updateValidatorSetV2 执行，BscValidatorSet 合约更新为 1 个验证者  

T3: 当前时间，调用 parlia.getValidators() 仍然返回 3 个验证者（来自 T1 的区块头）

T4: 下一个 epoch 区块，区块头才会更新为 1 个验证者

验证者信息在区块头中的存储

区块头 Extra 字段格式：

// consensus/parlia/parlia.go
func getValidatorBytesFromHeader(header *types.Header, chainConfig *params.ChainConfig, epochLength uint64) []byte {
    // Before luban fork: |---Extra Vanity---|---Validators Bytes (or Empty)---|---Extra Seal---|
    // After luban fork:  |---Extra Vanity---|---Validators Number and Validators Bytes (or Empty)---|---Vote Attestation (or Empty)---|---Extra Seal---|
    // After bohr fork:   |---Extra Vanity---|---Validators Number, Validators Bytes and Turn Length (or Empty)---|---Vote Attestation (or Empty)---|---Extra Seal---|
}

 

验证者信息被编码在区块头的 Extra 字段中，只有在 epoch 区块才会更新。

解决方案

短期解决方案

1. 直接调用合约方法：使用 BscValidatorSet.getValidators() 获取最新的验证者信息

2. 等待下一个 epoch 区块：等待下一个 epoch 区块生成，区块头中的验证者信息会自动更新

长期解决方案

1. 修改 API 接口：在 parlia.getValidators() API 中添加一个参数，允许直接从合约获取最新信息

2. 调整更新频率：考虑修改 epoch 长度，使其与呼吸区块同步

3. 添加缓存机制：在 API 层面添加缓存，优先返回最新的验证者信息

总结

这个问题不是 bug，而是 BSC 网络设计中的一个时间差问题。parlia.getValidators() 返回的是区块头中存储的验证者信息，而 BscValidatorSet.getValidators() 返回的是合约当前状态中的验证者信息。由于两者的更新频率不同（epoch 区块 vs 呼吸区块），在某些时间点会出现不一致的情况。

理解这个机制对于开发 BSC 相关应用非常重要，开发者需要根据具体需求选择合适的验证者获取方式。