Mina中的Snark Worker

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