Reducing Participation Costs via Incremental Verification for Ledger Systems学习笔记

Posted 2022-07-20 mutourend

1. 引言

Weikeng Chen等人2020年论文《Reducing Participation Costs via Incremental Verification for Ledger Systems》。

相关代码见：

• IVLS（ incrementally verifiable ledger system ）：https://github.com/arkworks-rs/ivls
• PCD（Proof-Carrying Data）：https://github.com/arkworks-rs/pcd
• Non-native field arithmetic：https://github.com/arkworks-rs/nonnative
• Constraints of Marlin：https://github.com/arkworks-rs/marlin
• Constraints of Marlin’s polynomial commitments：https://github.com/arkworks-rs/poly-commit

账本系统为运行在P2P网络的许多servers（又名“全节点”）之上的应用，可提供强一致性保证。典型的账本系统有：仅支持basic payments的 cryptocurrencies，以及支持rich smart contracts的 cryptocurrencies。

但是，这种强一致性保证，源自high participation costs。本文重点关注如何降低账本系统中的participation costs。

1.1 何为participation cost？

所谓Participation costs，是指：
账本系统中的servers（“全节点”）为维护the entire application state，需根据某种共识协议，为每笔新交易（或区块内的一堆交易）运行相应的state transition。
新加入到网络中的server（“全节点”），需要下载每笔交易并执行迄今为止的每个state transition。随着交易数量的增加，其带宽和computation costs会线性增长。如截止2020年，Bitcoin账本已超过300GB，为获得最新状态，下载和执行每笔交易所需时间要数天，具体取决于机器。

此外，对于想要与该application交互的client，其：

• 要么需要自己像server（“全节点”）一样，维护整个application state；【client需要运行与其无关的计算，如处理系统内的所有payments。且使得client无法在weak devices（如手机）上运行。】
• 要么需要向某server回复关于当前状态（甚至过去交易状态）的请求。【要求client信任某server返回的结果是正确的。】

对于P2P账本系统来说，高participation cost意味着中心化（集中到少数能维护整个application state的参与者）。

1.2 通过cryptographic proofs来避免交易的re-execution

在验证state transition时，可利用密码学证明来避免交易的re-execution。

直白来说，密码学证明使得任何人都可生成一个短字符串来证明计算的正确性，相比于证明计算本身，验证该证明的速度为exponentially faster。
借助密码学证明，可为transition的正确性生成证明，对应有transition前后的application state的2个short commitments。这样，验证最新state仅需要:

• 下载所有的state commitments和transition proofs（远少于下载所有的交易）
• 并验证所有transition proofs（工作量远小于re-executing所有交易）

transition proofs可同时减少servers和clients端的participation costs，但是servers和clients仍需要处理每个transition proof。对于新加入（或重新加入）的参与者，处理到当前状态为止的所有transition proofs的cost仍与state transitions的数量呈线性关系。对于长期离线的client来说，这样的开销仍然是昂贵的。

为解决以上问题，直观的方案是引入untrusted operator来为batches of transactions生成transition proofs。这就是流行的“layer-2扩容解决方案”。但是，由于batches的size通常不能太大，并未根本性地解决该问题。

1.3 Incremental verification

Valiant [Val08]