📜 [專欄新文章] Tornado Cash 實例解析

✍️ Johnson

📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

Tornado Cash 是一個使用 zk-SNARKs 建立的 Dapp，它實現了匿名的代幣交易，這篇文章就用一些程式碼片段，來分享它是怎麼運作的。

本文為 Tornado Cash 研究系列的 Part 3，本系列以 tornado-core 為教材，學習開發 ZKP 的應用，另兩篇為：

Part 1：Merkle Tree in JavaScript

Part 2：ZKP 與智能合約的開發入門

Special thanks to C.C. Liang for review and enlightenment.

我們知道在以太坊上的交易紀錄都是公開的，你可以在 etherscan 上看到某個地址的所有歷史交易紀錄，當然地址是合約的話也是一樣。

也許創建一個新的錢包和地址就好了？假設一個情境是 Alice 想要匿名傳送 1 ETH 給 Bob，Alice 原本的錢包是 A，但她不想讓 A 地址傳給 Bob 的交易紀錄被看到，所以 Alice 創建另一個錢包 B，顯然 B 錢包是空的，Alice 必須把 A 錢包的 1 ETH 傳到 B 錢包，再用 B 錢包的地址傳給 Bob。

但問題就在於，只要追蹤 B 錢包的地址，就能看到 B 的歷史交易紀錄中 A 錢包曾經打幣給 B 錢包，於是到頭來交易還是被追蹤到了。

Tornado Cash 的解決方案，簡單來說，它是一份合約，當你要匿名傳送代幣時，就把一定數量的幣丟進合約裡 (Deposit)，此時你會拿到一個 note，長得像這樣：

tornado-eth-0.1-5-0x3863c2e16abc85d72b64d78c68fca5936db2501832e26345226efdfb2bc45804977f167d86b711bb6b4095ddaa646ec93f0a93ac4884a66c1d881f4fc985

note 就是一串字串，擁有這字串的人，就能提領 (Withdraw) 剛剛傳入合約的代幣。握有 note 就代表擁有提款的權利，所以 note 一旦被別人知道，別人就可以把錢給提走。

其中，後面那段亂碼，本篇文章就以「秘密」來稱呼，這個秘密是由 secret 與 nullifier 組成，而這兩個都是在鏈下隨機產生的亂數。

因此 Tornado 的合約基本上會有兩個函式：

Deposit

Withdraw

有興趣的人可以先到 Dapp 上先玩一次看看，使用 Goerli 測試網，這裡可以領 Goerli 的代幣：https://goerli-faucet.slock.it/

Deposit

我們就從 Deposit 開始說起，簡單來說， Deposit 是將資料儲存到合約的 Merkle Tree 上。

剛剛提到的秘密，它是在鏈下產生，由 secret 跟 nullifier 組成，合在一起之後也稱作 preimage，因為我們要對這個 preimage 進行 hash，就會成為 commitment。

合約中 Deposit 如下：

deposit 除了傳送代幣到合約之外，需填入一個參數 _commitment。

我們對 preimage 使用 Pedersen 作為 hash function 加密後產生 commitment，以偽代碼表示如下：

const preimage = secret + nullifier;const commitment = pedersenHash(preimage);

這個 commitment 會成為 Merkle Tree 的葉子，所以合約中的 _insert(commitment) 來自 MerkleTreeWithHistory.sol 的合約，將我們的資料插入 Merkle Tree，然後回傳一個 index 給你，告訴你這個 commitment 在 Merkle Tree 上的位置，最後一起發布成公開的 Deposit 事件。

我們知道 MerkleTree 是將一大筆資料兩兩做雜湊後產生一個唯一值 root，這個 root 就是合約上所儲存的歷史資料。

root 的特性就是只要底下的資料一有更動，就會重新產生新的 root。

所以只要一有用戶 deposit ，就會插入新的葉子到 Merkle Tree 上，於是就會產生新的 root，所以在合約中有一個陣列是用來儲存所有的 root 的 roots：

bytes32[ROOT_HISTORY_SIZE] public roots;

roots 是用來紀錄每個 deposit 的歷史，每一次 deposit 都會創造新的 root，而所有 root 都會被儲存進 roots 裡，於是當你要提領的時候，就要證明你的 commitment 所算出的 root 曾經出現在 roots 裡，代表曾經有 deposit 的動作，因此才可以進行提領。

Withdraw

在 Deposit 之前 Tornado Cash 就會在鏈下產生秘密後交給使用者，擁有這個秘密的人等於擁有提款的權利。

提領的時候，秘密會在鏈下計算後產生 proof，proof 是 withdraw 需要的參數，所以只要確保這個 proof 能夠被驗證，那麼代幣的接收地址 (recipient) 就可以隨便我們填，只要不填上當初拿來 deposit 用的地址，基本上就做到匿名交易的效果了。

也就是說，產生這個 proof 並提交給合約，能夠證明此人知道秘密，但卻不告訴合約秘密本身是什麼。

function withdraw(bytes calldata _proof, bytes32 _root, bytes32 _nullifierHash, address payable _recipient, address payable _relayer, uint256 _fee, uint256 _refund) external payable nonReentrant;

我們可以清楚看到 withdraw 函式裡沒有接收有關秘密的任何資訊作為參數，也就是秘密不會與合約有所接觸，也不會暴露在 etherscan 上。

回顧 ZKP 所帶來的效果：

鏈下計算

隱藏秘密

在 Tornado Cash 的例子中，我們用秘密來產生證明，完成的鏈下計算包括：

將秘密 hash 成 commitment

算出 Merkle Tree 的 root。

以下是簡化後的 withdraw.circom：

template Withdraw(levels) { signal input root; signal input nullifierHash;

signal private input nullifier; signal private input secret; signal private input pathElements[levels]; signal private input pathIndices[levels];

component hasher = CommitmentHasher(); // Pedersen hasher.nullifier <== nullifier; hasher.secret <== secret; hasher.nullifierHash === nullifierHash;

component tree = MerkleTreeChecker(levels); // MiMC tree.leaf <== hasher.commitment; tree.root <== root; for (var i = 0; i < levels; i++) { tree.pathElements[i] <== pathElements[i]; tree.pathIndices[i] <== pathIndices[i]; }}

component main = Withdraw(20);

從上述代碼就可以看出這份 circuit 的 private 變數有：

secret

nullifier

pathElements

pathIndices

而 public 變數有：

root

nullifierHash

如同我們一開始說過的，秘密就是指 secret 與 nullifier。這裡進行的鏈下計算就是對 secret 與 nullifier 雜湊成 commitment。而使用的 hash function 叫做 Pedersen。

在進行 Merkle Tree 的計算之前，我們還檢查了 nullifier 雜湊後的 nullifierHash 跟 public 變數 nullifierHash 是不是一樣的。

hasher.nullifierHash === nullifierHash;

接下來，開始計算 Merkle Proof，用意是確認經過雜湊後的 commitment 有沒有出現在 Merkle Tree 上，所以我們的 private input 還有 pathElements 與 pathIndices（詳情參考 Part 1 Merkle Tree in JavaScript），讓它跑一趟 Merkle Proof 的計算，最後就能夠算出一個 root，再確認計算後的 root 與我們的 public 變數 root 是否一樣。

tree.root <== root;

於是我們就能產生一個 ZKP 的證明 — 證明 private 變數：secret, nullifier, pathElements, pathIndices 可以計算出 public 變數：root 與 nullifierHash。

把這個證明提交給合約，合約透過 Verifier 驗證 proof 是否正確，以及必須事先確認：

public 變數 root 有在合約的 roots 裡面。

public 變數 nullifierHash 在合約中是第一次出現。

以下附上完整的 withdraw 原始碼：

必須注意 ZKP 是向合約證明使用者填入的 secret 和 nullifier 可以計算出某個 root，但無法保證這個 root 曾經在合約的 roots 歷史上。

所以合約的 withdraw 中，除了 verifyProof 之外，還要事先檢查 ZKP 算出來的 root 是不是真的在歷史上發生過，所以需要 isKnownRoot 的檢查：

function isKnownRoot(bytes32 _root) public view returns(bool)

必須先檢查 isKnownRoot 後才能進行 verifyProof。

經過 verifyProof 驗證成功後，合約就開始進行提款的動作，也就會將代幣傳到 recipient 的地址，最後拋出 Withdrawal 的事件。

nullifier 與 nullifierHash

為什麼我們的秘密不是只有 secret 還要額外加一個 nullifier？

簡單來說，這是為了防止已經提領過的 note 又再提領一次，也就是所謂的 double spend。

require(!nullifierHashes[_nullifierHash], "The note has been already spent");

可以看到 withdraw 需要填入參數 nullifierHash，跟 isKnownRoot 一樣的狀況，我們需要對電路的 public 變數先經過一層檢查之後，才能帶入到 verifyProof 裡面。

nullifierHash 可以理解為這個 note 的 id，但它不會連結到 deposit，因此可以用來紀錄這個 note 是否已經被提領過。

所以當 verifyProof 驗證成功之後，我們要紀錄 nullifierHash 已完成提領：

nullifierHashes[_nullifierHash] = true;

有關為什麼需要事先檢查 public 變數後，才能帶入 verifyProof ，可以參考 Part 2：ZKP 與智能合約的開發入門 提到的 publicSignals 的部分。

附上 Tornado Cash 的架構圖：

簡化版的 tornado-core

tornado-core 的程式碼很簡潔漂亮，所以我模仿該專案自己實作一遍：

simple-tornado：https://github.com/chnejohnson/simple-tornado

這份專案只完成了 tornado-core 的核心部分，不一樣的是我的開發環境使用 hardhat 與 ethers 寫成，而 circom 與 snarkjs 使用官方當前的版本，合約用 0.7.0，測試使用 Typescript 。

比起兩年前的 tornado-core ，simple-tornado 使用的技術更新，可能更適合初學者理解這份專案，但是它有 bug…我在 issues 的地方有紀錄說明。

在開發的過程中，我的順序是先從最小單位的 MiMC hash function 開始玩，發現必須 javascript 算一次 hash、solidity 算一次、circom 再算一次，確保這三個語言對同一個值算出同樣的 hash 之後，才能放心去做更複雜的 Merkle Tree。

總結

我們可以看到 Tornado Cash 簡單的兩個函式：Deposit 與 Withdraw，透過將代幣送入合約後再提領到另一個地址的流程，應用 ZKP 達成匿名的交易。

除了斷開 Deposit 與 Withdraw 的地址關聯性之外，Tornado Cash 還有做了一層「藏樹於林」的隱私防護，這部份的解釋就請參考 ZKP 讀書會 Tornado Cash。

網路上很多關於 ZKP 的文章或專案都是在 2019 年後出產的，經過許多人對這項技術的嘗試，讓我們對 ZKP 有了更清晰的理解，如今兩年後，開發工具也變得更加成熟，期待未來在 web 隱私議題上能看到更多 ZKP 大放異彩的應用。

原始碼

tornado-core

simple-tornado

參考資料

ZKP 讀書會 Tornado Cash

Tornado Privacy Solution Cryptographic Review

Tornado Cash 實例解析 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

#科語錄 你知道現在電路的運算基礎是怎麼打下的嗎？
　
邏輯設計的運算採用布林代數，但是第一個將布林代數應用於電路上的，卻是被稱為「資訊理論之父」的夏農 (Claude Elwood Shannon)。
　
而他的碩論《繼電器與交換電路的符號分析》，更被後世譽為資訊時代的大憲章。
_
從小就喜歡搞電子實驗的夏農，自密西根大學畢業時已取得數學與電機雙學位，接著便進入MIT電機研究所就讀，並在科學巨擘凡納爾・布希 (Vannevar Bush) 教授的實驗室當研究助理。
　
當時，夏農的主要工作是協助調整布希所設計的分析儀，需要掌握近百個控制電動馬達的繼電器。
　
繼電器的開關掌控著電流進出，串成迴路後，就能以特定的順序開開關關，讓微分分析儀解出各種微分方程式。
_
第二年暑假，夏農到了正在開發「縱橫式自動交換機」的美國電話電報公司（AT&T）貝爾實驗室實習。
　
雖然和夏農過去操作的微分分析儀不同，但聰明的夏農卻能看出兩者在運作上的共通點。
　
兩個繼電器在一條電路上前後串聯，必須打開電流才能通過。若電路一分為二，各經一個繼電器再並聯，其中只要有一個是開的，電流就能繼續往前了。
　
領悟這其中奧妙的夏農，從這組實體電路聯想到了抽象的邏輯關係，更看出電子迴路與布林代數的關聯。
_
在夏農眼中，繼電器的開、關兩種狀態，恰可用布林代數中的 1 與 0 兩種數字表示。
　
不只如此，他還將繼電器的串聯看作邏輯運算的「且」(AND)，並聯則當成「或」(OR)，就這樣一彈指，將所有的迴路都用布林代數來描述。畢竟如果可以簡單誰想要複雜對吧XD
　
回到學校，夏農以此做為碩論題目。沒多久，便在 1937 年完成碩士論文──《繼電器與交換電路的符號分析》(A Symbol Analysis of Relay and Switching Circuits)。
　
而論文更是開宗明義地宣告：「任何電路都可以用一組方程式表示，……。事實證明，其計算方式完全等同於符號邏輯所用的命題運算。」
_
這篇碩論公開後立即引起巨大迴響，甚至被譽為「應該是本世紀最重要、最值得注意的碩士論文」；原本複雜的電路圖改用布林代數表示後，就能在機器實際建造前先計算出執行的結果，找出更精簡的方案，錯誤成本大幅降低。
　
科技產品也因為設計效率提升、製造成本下降，得以更迅速推陳出新，往後計算機、電腦的發展也受惠於他的創見。
　
很快地，打造現代電腦的各路好漢，也將在這條計算機路上一個個出現。
_
本文改寫自泛科學文章《獨自搞定電腦與通訊的理論基礎，卻罕為人知的天才——夏農│《電腦簡史》數位時代（四）》
https://pansci.asia/archives/191130
_
延伸閱讀：
夏農誕辰│科學史上的今天：4/30
https://pansci.asia/archives/140465
人工智慧憑什麼叫做人工智慧？AI的名稱政治學──《科學月刊》
https://pansci.asia/archives/139201

#電源設計 #功率器件 #智慧功率模組IPM #寬能隙WBG #碳化矽SiC #氮化鎵GaN #閘門驅動器

【高壓、大動力系統，SiC 撐場】

當人們將 SiC 與 GaN 相提並論時，除了高效率、低損耗、小型化等共通優點外，就功率器件而言，現階段在應用取向仍有分野：SiC 多用於消耗大量二極體的功率因素校正 (PFC)、尤其是上千伏特 (V) 的高壓電源產品；而 GaN 多用於高功率密度 DC/DC 電源的高電子遷移率電晶體 (HEMT) 以及 600V 以上的 HEMT 混合串聯開關。

SiC 在相同尺寸下可帶來更高的電壓擊穿性能，在失效前可承受更高的溫度，即使在高溫或低電流下也能實現「低導通損耗」，使得 SiC 器件能耐受 200℃ 工作溫度，也可避免低負載或空載時的無謂浪費，因而成為太陽能和汽車的新勢力；SiC SBD 常用於太陽能，而 SiC MOSFET 則用於高功率電源、驅動電子開關、智慧工控和車輛電氣化等。

SiC 功率器件的較高 dV/dt 額定值也帶動「隔離」需求，意在更好地控制電磁干擾 (EMI) 標準。利用電容隔離技術大幅延長絕緣層 (insulation barrier) 的使用壽命、簡化設計並實現更高的系統可靠度，大幅節省能耗、監控高壓系統，並對過電流事件提供有效保護。值得留意的是，SiC 在 PFC、UPS、消費電子和電動汽車等 900V 以下低電壓產品正面對 GaN 的強悍搶市，轉攻 1200V 以上市場；為彌補成本並最大化利潤，供應商正努力提供系統級解決方案、而非單純組件。

高性能材料亦會導致印刷電路板 (PCB) 佈局變得更加困難，「虛擬原型」的佈局後分析是管理這一挑戰的理想選擇，但前提是須具備複雜的通用電磁場解算專業。為簡化開發工作，量測廠商將開關模式電源 (SMPS) 設計的效果予以「可視化」，讓工程師無需花費時間建構和測試原型。

延伸閱讀：
《碳化矽：損耗低、導熱佳，支撐 kV 等級的高壓應用》
http://compotechasia.com/a/feature/2019/0409/41525.html
(點擊內文標題即可閱讀全文)

#科銳Cree #Wolfspeed #羅姆半導體Rohm #英飛凌Infineon #意法半導體ST #通用電氣GE #富士電機FujitsuElectronics #電裝Denso #豐田汽車ToyotaMotor #豐田中央研究所CRDL #三菱Mitsubishi #松下Panasonic #住友電氣SumitomoElectric #日立Hitachi #世紀金光半導體CenturyGoldray #株洲中車時代電氣CRRCTimesElectric #中國國家電網SGCC #電子科技大學Uestc #瀚薪科技HestiaPower #亞德諾ADI #UnitedSiC #德州儀器TI #是德科技Keysight