引言

從論文的角度看，Aleo的可編程隱私設計所採用的的隱私設計和早期的Zcash的白皮書（ zerocash ）更為相近，類似的Key結構，類似的Note結構，類似的稱呼（nf在zerocash裡稱為sn, serial number）。本文是基於Zcash最新的論文和Aleo的ZEXE做的比較，雖然在具體的細節上有所不同，比如Key結構，具體使用的密碼學方法；但是在high-level的設計上大體相同。

除了前面所講述的技術細節外，仍然存在一些其他的技術細節暫未涉及，比如delegate prover方案，零知識證明算法，遞歸/聚合方案等，有興趣的同學可繼續研究。

Zcash

1. 關於Zcash？

一個簡短的視頻了解Zcash，大概需要2分鐘。

https://zcash.readthedocs.io/en/latest/rtd_pages/basics.html

特點：

• 匿名版的BTC，類UTXO模型

• 只能做支付場景，不具備可編程性

2. 主要概念

注意： Zcash經過多次協議升級，我們只關注最新版本。主要介紹Zcash裡的各個核心概念。

2.1 Key components

從Zcash和Aleo的技術出發，理解隱私交易的設計原理

圖片來源

（ Zcash protocol specification: section 3.1, page 12 ）

• sk：支出密鑰，統一生成

• ask：支出授權密鑰

• ak：支出驗證密鑰

• nk：無效衍生密匙

• rivk：Commit ivk隨機性

• dk：分散密匙

• ivk：KA Orchard私人密鑰/ 輸入查看密匙

• ovk：輸出查看密匙

• pkd：傳輸密匙

• 支出密鑰：密鑰

• 全面查看密匙：解密交易背景

• 輸入查看密匙

• 輸出查看密匙

• 屏蔽支付地址：每次都應不同

你可以在Zcash protocol specification: section 4.2.3, page 36了解這些Key的計算方式。

2.2 Note

note是Zcash 協議中的基本單元，類似於BTC中的UTXO；在Zcash中，所有交易的輸入和輸出都是notes。當然，Zcash也支持非匿名的交易，這樣和BTC的交易模式一樣。

所以，要想更深入的了解Zcash，得先需要了解note的數據結構：

從Zcash和Aleo的技術出發，理解隱私交易的設計原理

圖片來源

（ Zcash protocol specification: section 3.2, page 14 ）

• {d′pk d }：note所有者的地址信息

• v：note對應的金額

• {ρ 'ψ}：計算nullifier的隨機數

• rcm：用於計算note commitment 的隨機數

在Zcash的協議中，因為隱私的需求，note是不能公開的，因此，需要計算對應的commitment來代表這個note，計算方式如下：

從Zcash和Aleo的技術出發，理解隱私交易的設計原理

圖片來源

（ Zcash protocol specification: section 3.2, page 15 ）

2.3 Action transfer

一筆交易裡，可能包含多個action transfer，每個action transfer 會花費老的note，生成新的note，其數據結構如下：

從Zcash和Aleo的技術出發，理解隱私交易的設計原理

圖片來源

（ Zcash protocol specification: section 4.6, page 41 ）

• cv net ：用於action transfer的balance校驗，通過binding signature實現，不包含在zk proof裡

• rt Orchard ：上一個區塊對應的狀態跟，用於校驗花費的note的有效性

• nf：花費的note的標識，用於防止雙花

• rk：用來驗證spender具有花費的note的權利，通過spendAuthSig簽名驗籤的形式

• cm x ：生成新的note的承諾

• epk：臨時公鑰，用來解密新note得noteplaint信息

• C enc ，C out ：新note被加密後的密文

• enbaleSpends，enableOutputs：指示當前action transfer的類型

• π：zk proof

2.4 Action statement

公共輸入是：

{rt Orchard ,cv net ,nf old ,rk,cm x ,enbaleSpends,

enableOutputs}

隱私輸入是：

{path,pos,g old d ,pk old d ,v old ,ρ old ,φ old ,rcm old ,cm old

α,ak P ,nk,rivk,

g new d ,pk new d ,v new ,φ new ,rcm new ,rcv}

證明statement為：

從Zcash和Aleo的技術出發，理解隱私交易的設計原理

圖片來源

（ 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的合法性

2.5 交易結構和示例

2.5.1 交易結構

從Zcash和Aleo的技術出發，理解隱私交易的設計原理

圖片來源

（ 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：實際值

2.6 如何實現隱私？

• Unlinkable

生成的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屬性。

Aleo

1. 和Zcash的異同

Zcash只能執行基於OUTX模型的隱私交易，不具備可編程性；因此，Aleo和Zcash最主要的區別是隱私可編程性；相同點是都支持隱私屬性（交易隱私，不只包含資產類）。

2. Aleo VS Zcash

2.1 Unit

和Zcash的note不同，Aleo裡的基本操作單元是record（BTC裡的是UTXO），下面讓我們看一下兩者的主要區別：

從Zcash和Aleo的技術出發，理解隱私交易的設計原理

圖片來源

（ Zcash protocol specification: section 3.2, page 14 ）

從Zcash和Aleo的技術出發，理解隱私交易的設計原理

圖片來源

（ Zexe protocol specification: section 3.1, page 17 ）

雖然具體參數名稱不相同，但是從功能角度來看，兩者之間具有對應關係：

從Zcash和Aleo的技術出發，理解隱私交易的設計原理

分別對應note擁有者的地址信息，承諾相關信息, nf/sn相關信息，value相關信息。

所以，兩者結構基本類似；主要的區別在於record裡的birth predicate，death predicate。這是兩個Boolean類型的函數，代表著，當一個record在birth(generate)和death(spend)階段，分別需要滿足的條件，這一塊是支持user-defined，因此具有可編程性。

2.2 交易結構

從Zcash和Aleo的技術出發，理解隱私交易的設計原理

圖片來源

（ Zexe protocol specification: section 3.1, page 17 ）

和Zcash(2.5.1)的交易主要結構相比，仍然相似：

▪ 消費的record對應的序列號sn，在Zcash裡用nf表示，都是具有全局唯一性。

▪ 新生成的record對應的承諾。

▪ 新生成record的plaint，包括擁有者信息，對應的birth/death predicate等。

2.3 Prover statement

從Zcash和Aleo的技術出發，理解隱私交易的設計原理

圖片來源

（ Zexe protocol specification: section 2.4, page 13 ）

需要證明：

▪ Old record的有效性

▪ Old record的合法性（具備花費record的權利）

▪ New record的有效性

▪ Birth/Death predicate的有效性（類似於Zcash裡的Balance校驗）

3. 其他

3.1 為什麼都是utox-based，不是account-based?

Remark2.3（ Zexe protocol specification: section 2.3, page 11 ）

參考

1. (Zcash)Zcash protocol specification（文中前6張圖片來源）：

https://zips.z.cash/protocol/protocol.pdf

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：Sin7Y

Twitter：@Sin7Y_Labs

Medium：Sin7Y

Mirror：Sin7Y

HackMD：Sin7Y

HackerNoon：Sin7Y

Email：contact@sin7y.org