Mina如何实现22KB？

Posted 2022-05-02 mutourend

1. 引言

Mina宣城其整个链大小为22KB。【实际目前约为11KB】
此处的链，是指：

• 1）为用户通常关心的account balance的明确可用的表示法，而不仅仅是相应的哈希表示。
• 2）节点验证状态所需的数据为真正的trustless模式。
• 3）支持在网络中广播交易来进行转账。

Bitcoin和以太坊中，miners需要所有历史交易来验证网络的当前状态，新加入的节点需要以trustless方式同步网络中的所有区块。Bitcoin和以太坊的light client定位为低容量环境，帮助用户快速验证与其相关的最新状态，而不需要进行时空昂贵的区块同步操作。light client需要信任全节点发送给其的数据。

Mina将 从genesis到任一区块的整个链 替换为 an easily verifiable constant-sized cryptographic proof。验证该proof相当于验证该区块及之前的所有交易。在区块内包含了相应的proof和inputs。

2. 以明确可用方式表达Mina链所需的数据

“明确可用”体现在：

• 1）可检查特定account的balance。
• 2）可向网络提交交易。

Mina中的22KB节点为非共识节点，其仅需要在内存中存储：

• 1）a protocol state
• 2）the account
• 3）a merkle path to this account
• 4）a verification key

不过，Mina中的22KB节点并非为light client，它具有与全节点相同的安全性。
当前，Mina官方并未实现这种仅作为“non-consensus node”的22KB节点，未来将实现。

2.1 protocol state

protocol state为网络当前状态的明确可用表示，其中包含了包括ledger等多种数据结构的哈希值。产块节点之间gossip的区块内包含了该protocol state。

Mina的区块内还包含其它信息，如：

• 1）当前区块内所包含的新交易的proof。
• 2）之前区块内包所包含的交易对应的SNARKs。

通过当前单个新区块内的proof和protocol state，借助：

• recursive zk-SNARKs
• a verification function
• a verification key

来验证the entire sequence of blocks。

在验证new state为valid之后，节点可在无需信任任何源的情况下独立判断当前的new block是否比现有block更好——通过与the last known best protocol state进行比较，若其不够好，可选择forget该区块；若够好，可替换现有block。换句话说，当监听newer states时，仅需维护一个protocol state。

2.2 account

Mina采用类似以太坊的account模式，某公钥对应的balance存储在 an account record内。未存储整个account-based ledger的节点可向全节点（如产块节点）请求某特定的account record。全节点会返回相应的merkle path to the account 来verify the account record is valid without needing to trust any node。最终的merkle root应与blockchain snark验证通过的ledger state匹配。

3. Mina 22KB size计算

A non-consensus node in Mina is therefore able to verify the entire blockchain and accounts from the ledger certified by the blockchain SNARK in a trustless manner like any other larger, more expensive (in syncing time, and space) full node would on other networks (like Bitcoin or Ethereum).

Mina的22KB 非共识节点，其size组成为：

	   Core.printf "Proof size: %d\\n%!"
         (Proof.Stable.Latest.bin_size_t precomputed_values.genesis_proof) ;
       Core.printf "Protocol State size: %d\\n%!"
         (Mina_state.Protocol_state.Value.Stable.Latest.bin_size_t
            precomputed_values.protocol_state_with_hash.data) ;
       Core.printf "Account size: %d\\n%!"
         (Account.Stable.Latest.bin_size_t account) ;
       Core.printf "Path size: %d\\n%!" (Merkle_path.bin_size_t path) ;
       Core.printf "Total size (combined): %d\\n%!"

以字节为单位，相应的输出为：

Proof size: 7063
Protocol State size: 822
Account size: 181
Path size: 741
Total size (combined): 8807

节点还需要a key来验证blockchain SNARKs，其size on disk为2039 字节，因此$8807+2039\approx 11$KB。Mina的当前密码学进化使得实际大小为11KB，比之前设计的22KB要更高效。

4. snarked-ledger

具体见Mina中的Scan State。
注意：
为了提升链的效率，采用的异步方式，即当前区块内包含的是之前区块内交易的SNARKs，而当前区块交易的SNARKs在之后的数个区块内。因此称其为snarked ledger，由SNARK worker节点来生成transaction SNARKs证明。即The latest ledger corresponding to a block (staged-ledger) is verified explicitly by block producers by applying the transactions to the ledger and are not guaranteed by the blockchain proof。

5. Mina的产块节点

Mina的产块节点除了验证状态之外，还需要执行其它任务。为了高效产块，产块者会维护最近$k$（当前Mina主网设置为290）个区块的链。$k$表示区块固化的深度，若某区块之上有$k$个区块，则该区块被reverse的概率可忽略，从而该区块内的所有交易都将永远被证实。
产块者在最近的$k$个区块内维护所有的分叉，以确定the best chain，并在best chain上产块。

此外，产块者还需要维护所有的数据结构，包括：

• the full ledger：以生成其它节点可验证的protocol state。

尽管需要更大的状态，但对于一个新的产块节点，同步到最新状态相当于验证$k$个blockchain SNARKs，并执行这$k$个块内的交易。

参考资料

[1] 22kB-Sized Blockchain — A Technical Reference

附录1. Mina系列博客

Mina系列博客有：

• Mina概览
• Mina的支付流程
• Mina的zkApp
• Mina中的Pasta（Pallas和Vesta）曲线
• Mina中的Schnorr signature
• Mina中的Pickles SNARK
• Mina中的Kimchi SNARK
• Mina Kimchi SNARK 代码解析
• Mina Berkeley QANet测试网zkApp初体验
• Mina中的Poseidon hash
• Mina中的多项式承诺方案
• Recursive SNARKs总览
• Mina技术白皮书
• Mina代码解析
• Mina中的Snark Worker
• Mina中的Scan State
• Mina中的VRF
• Mina中的delta_transition_chain_proof/delta_block_chain_proof
• Mina中的stake delegation