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中，

Accounts-Hash為the hash of th econcatentation of the state hashes of each account modified during the current slot，即：
A c c o u n t s H a s h = H a s h ( H a s h ( a c c o u n t 1 s t a t e ) ∣ ∣ H a s h ( a c c o u n t 2 s t a t e ) ∣ ∣ . . . ∣ ∣ H a s h ( a c c o u n t n s t a t e ) ∣ ) AccountsHash=Hash(Hash(account1_{state})||Hash(account2_{state})||...||Hash(accountn_{state})|) AccountsHash=Hash(Hash(account1state?)∣∣Hash(account2state?)∣∣...∣∣Hash(accountnstate?)∣)

receipt需要transaction status，因為需要為block構建state receipt，同一區塊中可能有具有相同state的2筆交易，僅根據state無法區分一筆交易是否提交成功，盡管可能沒必要encode the full status code，但是需要一個status bit來標記交易是否成功，

當前Solana中并未實作Block-Merkle，因此，為了驗證entry E在 bank hash為B 的block中，需提供該block中的所有entry hashes，這樣的實作效率很低，未來Solana應該會實作Block-Merkele，

3.1.2 Block Headers

為了驗證Transaction inclusion proofs，light client應能推斷出網路中的拓撲結構，

light client應能跟蹤新生成的block headers，如新來的2個bank hash為A,B的區塊，light client應能判斷出A是B的ancestor（具體見下面提到的 Optimistic Confirmation Proof），header中的內容將用于計算bank hash，

Bank-Hash=Hash(Accounts-Hash || Block-Merkle)

具體代碼實作為：

		let mut hash = hashv(&[
            self.parent_hash.as_ref(),
            accounts_delta_hash.hash.as_ref(),
            &signature_count_buf,
            self.last_blockhash().as_ref(),
        ]);

可跟現有的Validator replay logic中的streaming logic來實作該邏輯：

			if let Some(sender) = bank_notification_sender {
                sender
                    .send(BankNotification::Root(root_bank))
                    .unwrap_or_else(|err| warn!("bank_notification_sender failed: {:?}", err));
            }

3.1.3 Optimistic Confirmation Proof

當前可通過a listener that monitors gossip and the replay pipeline for votes來獲得optimistic confirmation資訊，具體為：

				if is_confirmed {
                    new_optimistic_confirmed_slots.push((*slot, last_vote_hash));
                    // Notify subscribers about new optimistic confirmation
                    if let Some(sender) = bank_notification_sender {
                        sender
                            .send(BankNotification::OptimisticallyConfirmed(*slot))
                            .unwrap_or_else(|err| {
                                warn!("bank_notification_sender failed: {:?}", err)
                            });
                    }
                }

對bank hash為B的區塊的每一個投票都是a signed transaction，一旦投票數達到了某閾值T，即可認為該區塊是optimistially confirmed，參與投票的這T個validators需要show that the block with bank hash B was optimistically confirmed，

但是，當前signed votes本身并不存盤，未來可能需要維護在Rocksdb資料庫中，以key (Slot, Hash, Pubkey)索引，來表示the slot of the vote, bank hash of the vote 以及 vote account pubkey responsible for the vote，

可擴展現有的signature subscription logic，將transaction merkle proof和optimistic confirmation proof通過RPC提供給訂閱者，
當探測到optimistic confirmation，即會通知訂閱者“Confirmed” confirmation，同時，需要提供一個flag來標記應回傳transaction merkle proof和optimistic confirmation proof，

It is important to note that optimistcally confirming B also implies that all ancestor blocks of B are also optimistically confirmed, and also that not all blocks will be optimistically confirmed.

B -> B'

So in the example above if a block B' is optimisically confirmed, then so is B. Thus if a transaction was in block B, the transaction merkle in the proof will be for block B, but the votes presented in the proof will be for block B'. This is why the headers in the Block headers section above are important, the client will need to verify that B is indeed an ancestor of B'.

3.1.4 Proof of Stake Distributioin

當收到transaction merkle proof 和optimistic confirmation proof時，客戶端需驗證交易T確實optimistially confirmed在bank hash為B的block中，
最后，需要驗證，在optimistic proof中的投票確實超過了T%的質押，以保證“optimistic confirmation”的安全性，

對于每個epoch，當stake set變化時，將所有的stakes寫到a system account，然后validators可訂閱該system account，然后全節點提供a merkle proving that the system account state was updated in some block B，再show that the block B was optimistically confirmed/rooted，

3.2 Account State Verification

可通過向cluster提交包含某TBD指令的交易來驗證某account的state（如balance或其它資料），然后client可使用Transaction Inclusion Proof來驗證該cluster是否同意 that the account has reached the expected state，

3.3 Validator Votes

Leaders可將股權與權重合并到一個entry中，這將減少創建receipt所需的entry數量，

3.4 Chain of Entries

A receipt has a PoH link from the payment or state Merkle Path root to a list of consecutive validation votes.

receipt中包含：

• Transaction -> Entry-Merkle -> Block-Merkle -> Bank-Hash

receipt中還包含一組PoH entries：

• Validator vote entries
• Ticks
• Light entries

/// This Entry definition skips over the transactions and only contains the
/// hash of the transactions used to modify PoH.
LightEntry {
    /// The number of hashes since the previous Entry ID.
    pub num_hashes: u64,
    /// The SHA-256 hash `num_hashes` after the previous Entry ID.
    hash: Hash,
    /// The Merkle Root of the transactions encoded into the Entry.
    entry_hash: Hash,
}

The light entries are reconstructed from Entries and simply show the entry Merkle Root that was mixed in to the PoH hash, instead of the full transaction set.

Clients do not need the starting vote state. The fork selection algorithm is defined such that only votes that appear after the transaction provide finality for the transaction, and finality is independent of the starting state.

3.5 Verification

A light client that is aware of the supermajority set validators can verify a receipt by following the Merkle Path to the PoH chain. The Block-Merkle is the Merkle Root and will appear in votes included in an Entry. The light client can simulate fork selection for the consecutive votes and verify that the receipt is confirmed at the desired lockout threshold.

3.6 Synthetic State

Synthetic state should be computed into the Bank-Hash along with the bank generated state.

For example:

• Epoch validator accounts and their stakes and weights.
• Computed fee rates

These values should have an entry in the Bank-Hash. They should live under known accounts, and therefore have an index into the hash concatenation.

參考資料

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