NEAR light client

1. 引言

NEAR官方在2020年10月发布了一则 Succinct Proof for NEAR light client的悬赏。

NEAR采用的是ed25519签名。 NEAR light client应：

• 压缩the light block verification 到 仅需验证一个单一的proof，这样可快速同步区块并用于Rainbow bridge中。

NEAR light client希望达成的目标有：

• 1）Light client proof generator, that fetches specific block by height from the node over RPC and generates a succinct proof that takes block hash and a block from previous epoch as arguments。
• 2）提供多种blocks proofs的测试用例，包括但不限于：epoch的最后一个区块、epoch的第一个区块、epoch的中间区块、无效区块（如无效data，无效签名等）、扫描NEAR主网所有区块生成proof并verify。
• 3）Solidity携程的Proof verifier合约，输入为某previous epoch的某block hash和block，输出为a proof。
• 4）从创世区块到指定区块的recursively proof。

2. Light client

NEAR light client state定义为：

• 当前区块头BlockHeaderInnerLiteView：包含了height、epoch_id、next_epoch_id、prev_state_root、outcome_root、timestamp。
• 下一epoch的block producers set的hash值next_bp_hash。
• 所有区块hashes的merkle root block_merkle_root。
• 当前epoch的block producers set。
• 下一epoch的block producers set。

Light client需定期通过特殊的RPC end-point来获取LightClientBlockView instances。

Light client并不需要收所有区块的LightClientBlockView。具有区块 B B B的LightClientBlockView，就足以验证区块B及其之前任意区块的state或outcome statement。

但是，为了验证某特定LightClientBlockView的有效性，light client必须验证a LightClientBlockView for at least one block in the preceding epoch，从而，在每个epoch需向light client至少同步并验证一个LightClientBlockView。

2.1 Validating light client block views

相关结构体定义为：

pub enum ApprovalInner {
    Endorsement(CryptoHash),
    Skip(BlockHeight)
}

pub struct ValidatorStakeView {
    pub account_id: AccountId,
    pub public_key: PublicKey,
    pub stake: Balance,
}

pub struct BlockHeaderInnerLiteView {
    pub height: BlockHeight,
    pub epoch_id: CryptoHash,
    pub next_epoch_id: CryptoHash,
    pub prev_state_root: CryptoHash,
    pub outcome_root: CryptoHash,
    pub timestamp: u64,
    pub next_bp_hash: CryptoHash,
    pub block_merkle_root: CryptoHash,
}

pub struct LightClientBlockLiteView {
    pub prev_block_hash: CryptoHash,
    pub inner_rest_hash: CryptoHash,
    pub inner_lite: BlockHeaderInnerLiteView,
}


pub struct LightClientBlockView {
    pub prev_block_hash: CryptoHash,
    pub next_block_inner_hash: CryptoHash,
    pub inner_lite: BlockHeaderInnerLiteView,
    pub inner_rest_hash: CryptoHash,
    pub next_bps: Option,
    pub approvals_after_next: Vec,
}

block hash的计算方式为：

sha256(concat(
    sha256(concat(
        sha256(borsh(inner_lite)),
        sha256(borsh(inner_rest))
    )),
    prev_hash
))

可根据prev_block_hash、next_block_inner_hash 和 inner_rest_hash 来重构当前区块hash和下一区块hash。approval_message为待签名消息，其中block_view为an instance of LightClientBlockView：

def reconstruct_light_client_block_view_fields(block_view):
    current_block_hash = sha256(concat(
        sha256(concat(
            sha256(borsh(block_view.inner_lite)),
            block_view.inner_rest_hash,
        )),
        block_view.prev_block_hash
    ))

    next_block_hash = sha256(concat(
        block_view.next_block_inner_hash,
        current_block_hash
    ))

    approval_message = concat(
        borsh(ApprovalInner::Endorsement(next_block_hash)),
        little_endian(block_view.inner_lite.height + 2)
    )

    return (current_block_hash, next_block_hash, approval_message)

当且仅当满足以下条件时，light client才会根据LightClientBlockView来更新区块头：

• 1）区块高度 高于 当前高度；
• 2）区块中的epoch 等于当前head中的epoch_id或next_epoch_id；
• 3）若区块中的epoch 等于当前head中的next_epoch_id，则next_bps不为None；
• 4）approvals_after_next中包含了来自于相应epoch的block producers对approval_message的有效签名；
• 5）approvals_after_next中的签名对应more than 2/3 of the total stake；
• 6）若next_bps不为none，则sha256(borsh(next_bps))对应为inner_lite中的next_bp_hash。

def validate_and_update_head(block_view):
    global head
    global epoch_block_producers_map

    current_block_hash, next_block_hash, approval_message = reconstruct_light_client_block_view_fields(block_view)

    # (1)
    if block_view.inner_lite.height