简介

zendoo：减小了侧链和主链之间的锚定开销

与ZK Rollup比较

zk-snark：简洁的非交互式零知识证明

向一个算术约束系统C，证明一组输入满足某个条件

由三个部分组成

setup：针对一个约束系统C的引导程序，设定安全参数为$\lambda$ 。该程序由一对密钥组成，pk为证明密钥，vk为验证密钥
$(pk,vk)\leftarrow Setup(C,1^\lambda)$
prove：生成证明$\pi$，证明$(a,w)$是一组满足约束系统C的值。其中，a是公共输入，w是需要保密的内容（叫做witness）
$\pi \leftarrow Prove(pk,a,w)$
verify：验证证明$\pi$是否是输入(a,w)满足约束C的有效证明
$true/false\leftarrow Verify(vk,a,\pi)$

专指比特币场景，以比特币为主链

表示为三元组形式

fig1

分别为：侧链ID，接收者相关元数据（结构在主链中不固定，语义未知），货币数量

可以将这种交易视作不可花费的交易

表示为二元组形式

fig3

所有在当前epoch中的（withdrawal epoch），转账到主链的交易，都收集到提款证明Withdrawal Certificate (WCert)中，再将该提款证明提交到主链进行处理（作为主链上的一笔带着提款证明的特殊交易进行处理）

fig4

quality：可能会发生同一条侧链在同一个epoch中出现多个提款证明的现象，该现象可能由于侧链的分叉或其他恶意行为。主链会选择最先提交的提款证明，或quality值最高的提款证明来接受
BTList为侧链转账到主链的交易列表
proofdata为SNARK verify的输入值，注意该字段自由规定（公共输入a）
proof为SNARK proof

提款证明还扮演着侧链心跳证明的角色，即使不存在侧链到主链的转账，仍然有提款证明定时发送到主链上

一个withdrawal epoch是由主链上的一系列块来决定的，且每种侧链对应的withdrawal epoch长度不同（在侧链创建时进行设置），因此整个系统是一个异步的状态

主链中的withdrawal epoch划分如下所示

fig2

侧链必须在下一个withdrawal epoch的前submit_len块内提交提款证明，否则就认为当前侧链为中断状态，该侧链之后提交的提款证明将不会再被主链接受

验证内容如下

fig5

proof为提款证明中的proof
$vk_{WCert}$是侧链创建时生成的SNARK验证密钥
$wcert_sysdata$ 包括提款证明中需要进行验证的交易列表、quality值，以及该提款证明是否对应当前epoch

用以下式子表示

其中MH(BTList)是交易Merkle tree root，$H(B^{i-1}_{last})$和$H(B^{i}_{last})$是epoch i和i-1的最后一个块的块头哈希