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

Mina中的Snark Worker相关推荐

Mina中的zkApp交易snark
1. 引言前序博客有: Mina中的支付交易snark(针对Payment交易) Mina的zkApp Mina中的树结构 --账号树 Mina中的user_command交易目前有: 1)Sign ...
Mina中的支付交易snark
1. 引言前序博客有: Mina的支付流程 Mina中目前的交易类型主要有: Coinbase交易:给产块者激励和手续费的交易,为内部交易. Fee_transfer交易:给snark worker ...
Mina中的wrap snark
1. 引言前序博客有: Mina技术白皮书所谓wrap snark,是将Tick snark(Mina代码中称为step proof)包裹为Tock snark(Mina代码中称为wrap pro ...
Mina中的区块证明
1. 引言 Mina的Pickles支持2种类型的tag: Side_loaded Compiled type ('var, 'value, 'n1, 'n2) t ={ kind : kind; i ...
Mina中的stake delegation
1. 引言为支持将某人的质押委托给另一人,增加受托人赢的几率. 质押委托的设计目标为: 从网络安全的角度来看,希望质押或委托的金额越多越好. 应不会too expensive inside the ...
Mina中的Kimchi SNARK
1. 引言 Mina系列博客有: Mina概览 Mina的支付流程 Mina的zkApp Mina中的Pasta(Pallas和Vesta)曲线 Mina中的Schnorr signature Min ...
Mina中的Pickles SNARK
1. 引言 Mina系列博客有: Mina概览 Mina的支付流程 Mina的zkApp Mina中的Pasta(Pallas和Vesta)曲线 Mina中的Schnorr signature 视频可 ...
mina 中的IoBufer(一)
为什么80%的码农都做不了架构师?>>> IoBuffer 是 MINA 中的独有接口,主要继承实现的是 java NIO 中的 ByteBuffer ,所以从使用方法上来看二 ...
从Jetty、Tomcat和Mina中提炼NIO构架网络服务器的经典模式（三）
2019独角兽企业重金招聘Python工程师标准>>> 从Jetty.Tomcat和Mina中提炼NIO构架网络服务器的经典模式(三) 博客分类: java 最后我们再看看NIO方面 ...

Mina中的Snark Worker