Solana light client

Posted 2021-12-10 mutourend

1. 引言

Solana已接收提案——Simple Payment and State Verification 中指出：
资源有限的客户端可运行light client来参与Solana网络，可在无需信任第三方的情况下，确认其提交的交易已提交到账本。

Solana中的Validators会将最近确认交易的签名在本地存储一段时间，已确保这些交易不会被重复处理。

客户端可：

• 通过Validator提供的JSON RPC端口来查询其提交的交易是否已被处理。
• 通过注册监听Validator提供的PubSub通知，可获知某签名是否已被Validator注意到。

以上两种方式，客户端都可验证一笔支付，但是，这不是a proof，需完全信任某单一Validator。

为了进一步减少客户端对某单一Validator的信任，可改为：

• 使用Merkle Proofs来锚定 该Validator在账本中的response，允许客户端通过验证 其选择的足够多数量的Validators是否已确认该交易。通过多个Validators的attestations可进一步减少对某单一Validator的信任。

2. Solana的light client

light client：是指不运行validator的参与者。
light client 可在无需增加资源投入的情况下验证账本，其提供的安全性要高于信任某一远程Validator。

Validator并不会将交易签名提交给light client，而是生成：

• a Merkle Proof from the transaction of interest to the root of a Merkle Tree of all transactions in the including block。

该Merkle Root存在ledger entry中，并经由Validators投票来提供共识合法性。

light client的安全性还取决于其初始收录的validators set。随着网络中Validators变化，light client也需要使用receipts来更新其内部的validators set。

考虑到性能，Validators本身可能也会想用light client API。如，在初始启动a validator的过程中，该validator可使用a receipt来验证一个由cluster提供的checkpoint of the state。

3. Receipts

A receipt为a minimal proof，用于证明：

• 1）某一交易被包含在某一区块——Transaction Inclusion Proof；
• 2）该区块已经由light client所选择的validators set 投票——；
• 3）投票达到了要求的确认深度（desired confirmation depth）——Chain of Entries。

3.1 Transaction Inclusion Proof

Transaction Inclusion Proof为一种数据结构，包含了：

• 某笔交易经由Entry-Merkle到达Block-Merkle的Merkle Path。

Block-Merkle会与the required set of validator votes一起，被包含在a Bank-Hash中。
包含后续validator投票的PoH entry chain（源自Bank-Hash）即为proof of confirmation。

3.1.1 Transaction Merkle

An Entry-Merkle即为a Merkle Root，包含了某个entry中的所有交易，按签名排序。

entry中的每笔交易均通过如下方式被merkled：【由此可证明某交易T被包含在某entryE中。】

poh.record(hash_transactions(transactions)).unwrap().hash

pub fn hash_transactions(transactions: &[VersionedTransaction]) -> Hash {
    // a hash of a slice of transactions only needs to hash the signatures
    let signatures: Vec<_> = transactions
        .iter()
        .flat_map(|tx| tx.signatures.iter())
        .collect();
    let merkle_tree = MerkleTree::new(&signatures);
    if let Some(root_hash) = merkle_tree.get_root() {
        *root_hash
    } else {
        Hash::default()
    }
}

pub struct VersionedTransaction {
    /// List of signatures
    #[serde(with = "short_vec")]
    pub signatures: Vec<Signature>,
    /// Message to sign.
    pub message: VersionedMessage,
}
pub enum VersionedMessage {
    Legacy(Message),
    V0(v0::Message),
}

A Block-Merkle为the Merkle Root of all the Entry-Merkles sequenced in the block。

将以上2个merkle proof一起，即可证明a transaction T被包含在bank hash为B的某block中。

参考资料

[1] Solana已接收提案——Simple Payment and State Verification
[2] 用于Solana-Ethereum的zk-bridge方案——=nil; Foundation’s In-EVM Solana Light-Client State Verification