除了前面所讲述的技术细节外,仍然存在一些其他的技术细节暂未涉及,比如delegate prover方案,零知识证明算法,递归/聚合方案等,有兴趣的同学可继续研究。
一个简短的视频了解Zcash,大概需要2分钟。
https://zcash.readthedocs.io/en/latest/rtd_pages/basics.html
特点:
• 匿名版的BTC,类UTXO模型
• 只能做支付场景,不具备可编程性
Zcash protocol specification: section 3.1, page 12)
你可以在Zcash protocol specification: section 4.2.3, page 36了解这些Key的计算方式。
Zcash protocol specification: section 3.2, page 14)
在Zcash的协议中,因为隐私的需求,note是不能公开的,因此,需要计算对应的commitment来代表这个note,计算方式如下:
Zcash protocol specification: section 3.2, page 15)
Zcash protocol specification: section 4.6, page 41)
隐私输入是:
证明statement为:
Zcash protocol specification: section 4.17.1, page 40)
• 花费的note的完整性,和noteplaint唯一绑定
• 花费的note的有效性,cm tree的存在性证明
• Value承诺的完整性,和rcv, old value, new value唯一绑定
• Nullifier的完整性,防止double spend,维护一个花费的note set
• 花费的note的合法性
• 地址的完整性
• 新note的完整性
• flag的合法性
Zcash protocol specification: section 7.1, page 119)
整个交易结构包含四个部分:
• Public info (1 - 5)
• Transparent transactions info (6 - 9)
• Sapling transactions info (10 - 16)
• Orchard transaction info (17 - 25)
2.5.2 从 transparent 到 shield
Orchard协议里包含两种地址, transparent address(TA) 和 shield address(SA)。一般,为了执行隐私交易,需要先从TA往SA转账,此时对应的交易结构应为:
• Public info (1 - 5)
• Transparent transactions info (6 - 9)
ⅰ. tx_in_*:实际值
ⅱ. tx_out_*:默认值
• Sapling transactions info (10 - 16)
ⅰ. All:默认值
• Orchard transaction info (17 - 25)
ⅰ. All:实际值
2.5.3 从 shield 到 shield
Orchard协议里包含两种地址, transparent address(TA) 和 shield address(SA)。一般,为了执行隐私交易,需要先从TA往SA转账,此时对应的交易结构应为:
• Public info (1 - 5)
• Transparent transactions info (6 - 9)
ⅰ. All:默认值
• Sapling transactions info (10 - 16)
ⅰ. All:默认值
• Orchard transaction info (17 - 25)
ⅰ. All:实际值
2.5.4 从 shield 到 transparent
Orchard协议里包含两种地址,transparent address(TA) 和 shield address(SA)。一般,为了执行隐私交易,需要先从TA往SA转账,此时对应的交易结构应为:
• Public info (1 - 5)
• Transparent transactions info (6 - 9)
ⅰ. tx_in_*:默认值
ⅱ. tx_out_*:实际值
• Sapling transactions info (10 - 16)
ⅰ. All:默认值
• Orchard transaction info (17 - 25)
ⅰ. All:实际值
生成的note用cm表示,花费的note用nf表示,nf和cm之间无任何联系,因此,任何人都无法通过这些信息去判断任何一个被生成的note是在哪一笔交易里被花费的。
• Private
ⅰ. Sender address:
交易信息里不包含sender地址且 spendAuthSig为一次性签名(每次都不一样,所以公钥不同,rk)。
ⅱ. Receiver address:
交易里不包含receiver的地址 且 新的Note plaint用的是recevier的公钥加密(接受者的隐私地址也是一次性的)。
ⅲ. Value:
用pedersen commitment形式隐藏Note,且通过bindsig来保证交易的balance属性。
Zcash只能执行基于OUTX模型的隐私交易,不具备可编程性;因此,Aleo和Zcash最主要的区别是隐私可编程性;相同点是都支持隐私属性(交易隐私,不只包含资产类)。
和Zcash的note不同,Aleo里的基本操作单元是record(BTC里的是UTXO),下面让我们看一下两者的主要区别:
Zcash protocol specification: section 3.2, page 14)
Zexe protocol specification: section 3.1, page 17)
虽然具体参数名称不相同,但是从功能角度来看,两者之间具有对应关系:
分别对应note拥有者的地址信息,承诺相关信息, nf/sn相关信息,value相关信息。
所以,两者结构基本类似;主要的区别在于record里的 birth predicate,death predicate。这是两个Boolean类型的函数,代表着,当一个record在birth(generate)和death(spend)阶段,分别需要满足的条件,这一块是支持user-defined,因此具有可编程性。
Zexe protocol specification: section 3.1, page 17)
和Zcash(2.5.1)的交易主要结构相比,仍然相似:
▪ 消费的record对应的序列号sn,在Zcash里用nf表示,都是具有全局唯一性。
▪ 新生成的record对应的承诺。
▪ 新生成record的plaint,包括拥有者信息,对应的birth/death predicate等。
Zexe protocol specification: section 2.4, page 13)
需要证明:
▪ Old record的有效性
▪ Old record的合法性(具备花费record的权利)
▪ New record的有效性
▪ Birth/Death predicate的有效性(类似于Zcash里的Balance校验)
Remark2.3(Zexe protocol specification: section 2.3, page 11)
2. (Aleo)Zexe protocol specification(Figure4/5/6,Remark2.3):
https://eprint.iacr.org/2018/962.pdf
3. 协议升级:https://z.cash/upgrade/
4. zerocash:https://eprint.iacr.org/2014/349.pdf
Sin7y成立于2021年,由顶尖的区块链开发者组成。我们既是项目孵化器也是区块链技术研究团队,探索EVM、Layer2、跨链、隐私计算、自主支付解决方案等最重要和最前沿的技术。
微信公众号:Sin7Y
GitHub | Twitter | Telegram | Medium| Mirror | HackMD | HackerNoon