1. 引言
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代码解析
大多数区块链协议只有一类node operator,通常被称为miner、validator或block producer,而Mina还有第二类node operator——Snark Worker。
Snark Workers是维护Mina网络健康的重要成员,Snark Worker负责为网络中的交易生成SNARK proofs,从而帮助维护Mina链的succinctness。
产块者会创建blockchain proofs来证明the current state of the blockchain的有效性,但是产块者并不证明其包含的各个交易的有效性。
Snark workers会负责为各个交易创建transaction proof。将transaction proofs的生成任务由产块者转移至snark worker,意味着可对transaction proof的生成进行并行化,从而有效提高网络吞吐量。
运行snark worker需要运行一个全节点,以:
- 获得最新的work(即待生成proof的job)
- 向网络提交完成的proof
可借助snark coordinators,在一个daemon上运行多个snark workers。
snark pool中一条entry的结构类似为:
{
"work_ids":[
839740827,
702578095
],
"fee":"0.011",
"prover":"B62qpEX1JXC7qNrC3bTwEEDU3UQGSE5DUVSenpmmLpLnNmwPDsLj8Jh"
}
2. 为何需要Snark Worker?
Mina的独特属性是succinct blockchain。当每个产块者为网络propose新区块时,还必须包含该区块的zk-SNARK。使得节点可忽略之前已固化的所有历史数据,仅需保留该SNARK。
然而,Mina中,不仅需要产块者为区块生成SNARK proof,还需要对交易生成SNARK proof。这是因为,blockchain SNARK并未make any statements of 该区块内交易的有效性。
比如,当前区块头中的state hash为a6f8792226...
,收到一个state hash为0ffdcf284f...
的新区块,该新区块内包含了产块者选择的所有交易及相应的metadata,同时还会收到一个对应该新区块的blockchain SNARK proof以验证如下statement:
“There exists a block with a state hash 0ffdcf284f which extends the blockchain with a previous best tip with state hash a6f8792226.”
注意,该statement并无任何关于该新区块内交易有效性的申明。若啥也不做就信任该blockchain SNARK,我们可能会被发送该区块的恶意产块者欺骗。幸运地是,我们有该raw block,可验证每笔交易以确保有效。但是对于网络中仅接收proof而不验证每个区块内交易的其它节点,该怎么办呢?
为了确保节点可以在不信任Mina的情况下运行,每个节点都可在无需重放交易的情况下验证链的状态,这一点很重要。为了实现这一点,仅有blockchain SNARK proof是不够的。还需要知道这些交易也是有效的。好吧,既然SNARK对这一点非常有用,那么天真的建议可能是在每笔交易进入时生成一个SNARK,然后将它们组合起来。
但是,生成SNARK proof是计算昂贵的——若为每笔交易串行生成SNARK,交易吞吐量将很低,block将猛涨。此外,现实环境中交易是异步到达的,因此很难预测何时perform the next item of work。
幸运地是,可利用SNARK的如下两个属性:
- 1)proofs可合并:2个proof可结合形成一个merge proof。
- 2)merge具有结合性:与结合的顺序无关,最终的merge proof是相同的。
SNARK的这2个属性使得我们可利用并行化的优势。若proof可合并,且与合并的顺序无关,则可并行生成SNARK proofs。先生成的proof可后续与在生成中的proof结合。可将其想象为binary tree,底层行(叶子)为独立的transaction proofs,而每个parent行,可看成是merge proofs。依次结合到root,该root即代表了a state update performed by applying all the transactions。
此外,由于SNARK proofs相互不依赖,也可并行化——即任何人都可参与生成SNARK proof。最终的结果是该distributed work pool是无需许可的,任何具有算力的人都可作为Snark Workers参与到Mina网络,观察需要SNARK的交易,并贡献其算力。同时,也会通过snarketplace获得相应的补偿。
3. High Throughput with Slow Snarks
详细见:High Throughput with Slow Snarks
4. Snarketplace
理解Snark Work的关键在于:
- Block producers use their block rewards to purchase snark work from snark workers.
不存在对Snark定价的协议,也没有为Snark Workers生成snarks提供协议层面的激励。激励是纯peer-to-peer的,由名为snarketplace的public marketplace动态建立。
可能会问,产块者为何需要购买SNARKs?原因在于为确保Mina区块头中的state是有效的,需要对区块内的所有交易进行snark。但是,如果我们不断地添加更多的交易,而不以相同的速度将它们snark,那么随着时间的推移,我们积累了永远无法完成的工作。为了达到稳态平衡,我们需要以与work增加速率大致相同的速率处理work。
由于产块者通过在区块中包含交易(通过交易费和coinbase交易)获利,他们负责通过购买同等数量的已完成snark work来抵消交易,从而创造出对snark work的需求。然而,他们的当务之急是以最低的价格从snarketplace购买snark work。相反,Snark Workers希望在销售snark work的同时实现利润最大化。这两个角色扮演着市场的两面,并随着时间的推移,以市场价格为snark work建立平衡。
5. 如何为snark work定价?
我们预计snarketplace将动态地重新平衡——例如遵循简单的供求规律。虽然从更大的角度来看,每个snark work适用于不同的交易,但snark work在很大程度上是一种商品(这意味着,哪个Snark Worker生产商品并不重要,它将是相同的)。然而,也有一些细微差别,因此对定价策略有一些启发可能会有所帮助:
- 如果市场价格为X,以低于X的价格出售snark work(如X-1)可能是有效的,前提是在扣除运营费用后盈利。
- 产块者被激励从同一个Snark Worker那里购买更多snark work,因为他们只需要在区块中包含一笔fee transfer交易。
- 基本上,产块者支付Snark Woker的方式是通过一种特殊类型的交易,称为fee transfer。产块者的动机是尽量减少fee transfer的数量,因为每一笔交易都是需要添加到区块中的离散交易(因此会被更多的snark work抵消)。因此,最好的情况是从同一个Snark Worker那里购买一捆snark work。
- 一些snark work将比其他work更重要,因为它将释放整个树的内存(有关更多详细信息,请参阅上面的视频)。这是通过不同的work选择方法实现的。目前,本机支持的两种方法是顺序和随机的。然而,这两种方法都没有利用动态市场,这是Mina社区可以开发解决方案的一个改进领域。
由于所有关于snarks和价格的数据都是公开的,所以有几种方法可以检查snarketplace。一个例子是使用GraphQL API,其他选项包括使用CLI,或滚动一个跟踪snark mempool中snark的自定义解决方案。
请继续关注snarketplace动力学的更详细分析。我们也将很快发布一份经济白皮书,提供更多的背景。
参考资料
[1] Mina Doc——Snark Workers
[2] What are SNARK Workers and the Snarketplace?
[3] Guide to Snark Work
[4] High Throughput with Slow Snarks
[5] SNARKs and Snark Workers FAQ