📜 [專欄新文章] [ZKP 讀書會] Tornado Cash
✍️ Jerry Ho
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
Disclaimer: 本人與Tornade Cash專案及其員工無任何利益往來。
Tornado Cash是一個Ethereum上的原生隱私轉帳解決方案，使用zk-SNARK+Merkle Tree的路徑證明作為其核心隱私保護機制。
你知我知，Ethereum上的交易記錄是公開的，這使得任何一個人只要知道你的address，便可以在https://etherscan.io/ 之類的網站上查出有多少人和這個位置進行過交易，你做過什麼消費行為或是交易行為等。
或許這聽來不像是個問題，而想要隱藏自己的交易記錄甚至聽起來反而像是不法分子的銷贓行為。
但試想下開情境：因為我曾經使用ethereum捐款給一個政治不正確的專案/組織，而我在接受dd/kyc/reference check的時候因為我的ethereum address就寫在自己的blog上而被查了個底朝天，因而被拒絕入職/拒絕開戶/拒絕服務。
這並不是一個很遙遠的情境…
Tl;dr
解決交易隱私問題分為兩個層次，Assuming你的目的是讓自己的金錢流向無法被追蹤。
層次一：我的錢「丟進了」Tornado Cash的contract，我要如何在不使用與轉入時同一個address的情況下— 若是同一個address就沒有隱私可言了 — 取出我的錢？contract如何知道我存過錢，餘額還夠，所以現在我來領錢了他讓我領？
層次二：就算層次一成立，我的隱私如何達成？到底有多隱私？到底有多不隱私？
技術上來說（細節下文詳談），層次一使用zero-knowledge的set-membership proof來證明，透過預先在Merkle Tree中「登記」一個自己的entry/leaf，tornado cash稱為note，爾後在提款時提出該leaf之zk proof，來解決這個提款時的認證問題。
層次二則是所謂的藏樹於林。既然轉出和轉入無法被連結在一起，那麼只要使用Tornado Cash的人數夠多，總轉出和總轉入的交易總筆數就會太多，以致無法輕易重新關聯轉入與轉出地址背後的真人。
使用界面
https://tornado.cash/
當然你也可以直接和合約地址互動啦
上圖左方紅框為存入幣種與金額大小，右方紅框為該額度對應之帳戶內有多少顆「樹」。
記得藏樹於林嗎？右方的 Anonymity set 就是告訴你現在森林的規模有多大。數量一大，跑資料分析試圖重新關聯某筆特定存款到某筆特定提款就變得更為困難。
提款界面如上。
值得注意的是，提款時的以上兩個選項(Wallet/Relayer)，是在目前Account Abstraction尚未實現時的一個折衷方案。
這裡有個死循環：既然我提款的時候需要支付gas，那麼我的gas從哪裡來？是不是勢必得從交易所或是其他帳號來？簡言之，若是無法直接新建立一個地址然後直接將其作為Tornado Cash提款用，達到的隱私強度就大打折扣。
Relayer就是針對這個問題所設計的。透過付出一些手續費來提供社群架設relayer node的誘因，提款時該筆轉帳的gas費用，便可以讓relayer node來負責先出。relayer node收到使用者的zk proof後將其轉交給tornado cash的合約，合約就會會將應有的relayer手續費與扣除手續費+gas後的款項分別轉給relayer與使用者。
社群治理
Tornado Cash天生是一個比較沒有銅臭味的專案 — 社群治理和funded的味道相當強烈。
透過預先設計好的proxy contract與staking/locking機制，任何一個Tornado Cash的使用者都能夠提出對合約實行的改動建議，並交由社群來投票決定是否要執行該改動。
技術細節可以參照此篇，同時Tornado Cash的第一輪社群治理提案也剛投票過關，回顧可參考此處之討論。
誘因設計
本文作者比較任性不在意錢，請移駕此處閱讀官方如何設計Anonymity Mining來確保以下兩點：
機制能讓使用者願意加入存錢，提供流動性同時也讓樹林變大，增加隱私程度。
產生TORN(ERC20 token)與領取TORN的機制，透過在原本的tornado cash上面再加一層，來避免TORN激勵層錯誤的設計導致下一層之隱私洩漏（激勵層出事不影響核心隱私之意）。
技術細節
首先本文不打算解釋何為zero-knowledge proof，請接受以下描述：
若有一NP statement分類上是satisfiability problem(例：merkle tree中的hash chaining H(H(H(a,b),c),d) )，則我們可以設計出一個arithmetic circuit來確保能夠有效率的產生proof, 有效率的驗證, 無法產生假的且能說服人的proof…且其電路驗證的statement是我們想要的，像是此例中的merkle tree opening.
存款
存款者透過送出C = H(k, r) 以及存入之數額給tornado cash的合約來進行存款的動作。其中k在之後會成為存款者領錢的憑證，稱為nullifier，r則是增加randomness而已，此二值需要記下。此時合約端會將這個C(commitment)丟入Merkle Tree上其中一個空的leaf，並更新root hash。存款者還需要記下自己的C對應之leaf index。
產生proof，用此proof作為提款憑證
用一段話來概括，若是我
知道Merkle Tree上某個leaf的commitment的preimage, 代表我能在電路中證明我知道H(k, r) 中的 k, r, 同時不洩漏k, r到底是多少（zk特性, magic）。
我知道該leaf至root的路徑上會經過哪些點，我也提供了一個可以讓電路驗證root hash的hash chaining過程，代表我知道他是從哪個leaf開始走的。因而，這證明了我提出的1.中的commitment確實屬於某顆公開的、大家都知道的merkle tree中的特定leaf（就是我之前存款對應到的leaf）。
就可以在不需要提供像是原本存款地址的簽章之類的驗證機制情況下，透過zk proof，亦能正確做permission control讓unlinkable的提款能夠成真。
另，讀者可以看到在proof中已然預設了relayer的存在。這使得上開所提到之「使用者提款, 拜託relayer執行=>relayer預付gas發起transaction，將內容送給tornado cash合約=>合約處理proof並將款項拆成兩份給relayer與使用者」這個行為得以成立，且relayer無法得知或假造proof內容。
提款流程
基本上在上方的產生證明都講過一次了，這邊就是pseudo code順過一次提款流程而已，大家自己看啊。
值得一提的是，使用者除了需要提出上一部分提到的證明之外，還需要將k的部分額外拿出來再做一次H(k)，將值一併傳給contract。
這裡的設計哲學，簡單來講是這樣的：zero-knowledge太強了，強到就算證明了我知道H(k, r)的k跟r, 收到的驗證者並沒有辦法知道H(k)是什麼東西。為了讓同一筆款項不會被提領兩次，在提款流程中合約會將「每一筆成功提款中的H(k)」記錄下來，另外開個表存著。爾後若是其他提款交易中的H(k)與表中的重複了，這就代表有人試圖想要騙合約重複提款，自然該提款嘗試就不會成立。
洗錢失敗例
工程師都知道使用者從來不看說明書，看了可能也不會懂。
Koh Wei Jie分析了Kucoin的駭客事件。Kucoin的駭客使用Tornado Cash來洗錢，但忽略了Tornado Cash官方一直三令五申的使用需知，因而讓款項在進入Tornado Cash跑了一輪之後還是能夠被追蹤，哈哈UCCU。
簡單來說，hacker為了節省多次使用relayer的手續費，而將大多數的提領過程都變成直接提領到wallet。雖然該wallet的位置是全新產生的沒有gas，但是透過只讓第一次的提款使用relayer，hacker便能從第一次提款中取得手續費並分發給其他全新產生的wallet address。
那問題在哪？還要問？
要達到隱私需要保持藏樹於林原則，同時使用者不應自己破壞tornado cash幫你達成的address unlinkability。這位hacker因為愛省手續費，所以違背了後者；同時他因為太心急又愛省手續費，太快、分太少次提領、每次提領的數額又太大了，所以side-channel去給他做簡單的traffic analysis就能夠用虛無假設推出：「綜觀歷史上所有的存款位置與數額，扣掉駭客存錢的那些位址之後，我們還需要14個unique address/user共謀，才能有能力一次提這麼多錢。」
這看起來可能嗎？自然是不可能的。
所以這位駭客就是錯誤的沒有遵守藏樹於林的原則，才導致自己的金流重新被和帳號聯繫在一起。
提供一些延伸閱讀，圈子內的”名人”對這種不看說明書的使用者的看法：
tornado * Gavin Andresen
如何避免洗錢失敗
我自己的投影片，我自己翻譯：
打開你的VPN 打開你的TOR 打開你的無痕瀏覽器分頁 用上你全新的VM PC VPS instance 最好連data-link layer安全都顧到 產生全新的地址不要懶惰 自己跑一個fullnode 乖乖用relayer付手續費提款 領錢之後記得把C(k,r)的記錄刪掉 不要急一次存或提領大額 時間拉長數目減少…..
簡而言之：要設計相對安全但又讓使用者可以直覺上手的安全系統真的很他媽難 - 使用者永遠會想辦法抄近路，然後系統的security assumption就爆炸了。
結論上來講，你想要多安全取決於你在臺大水源校區的腳踏車平常都上幾個大鎖=想付出多少成本。只要不要學Kucoin Hacker那樣連鎖都不鎖車還是新的，大部分時間都沒啥問題 lol。
參考資料與文中出現過的連結，不按先後順序：
https://tornado.cash/Tornado.cash_whitepaper_v1.4.pdf
https://tornado.cash/audits/TornadoCash_cryptographic_review_ABDK.pdf
https://tornado.cash/audits/TornadoCash_circuit_audit_ABDK.pdf
https://torn.community/t/whats-next-for-tornado-cash-governance/250
https://weijiek.medium.com/deanonymising-the-kucoin-hacker-418fa5e9911d
https://tornado-cash.medium.com/tornado-cash-governance-proposal-a55c5c7d0703#2084
https://eips.ethereum.org/EIPS/eip-2938
http://gavinandresen.ninja/private-thoughts
[ZKP 讀書會] Tornado Cash was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
account for導致 在 [請益] account for 的用法- 看板Eng-Class - 批踢踢實業坊 的推薦與評價
最近在看一部犯罪影集
其中一段是探長懷疑死者是pizza店的員工，
所以就要求手下，去盤查員工名單
回報的時候手下說：
"we got through to all their employees.
everybody's accounted for."
字幕上的翻譯是說：「他們都還活著 」
(也就是說死者不是員工之一)
想請問的是 在這裡使用account for的意思是什麼?
怎麼能解釋翻譯成「都還活著」?
先謝謝各位了!
(我事先查了字典，account for 的解釋為
1.說明 (原因、理由) 2.導致、引起 3.占(多少) 4.對...負責
好像都沒辦法直覺聯想
看了例句，也沒有相關的表達方式，我可能需要更多的慧根orz)
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.160.222.15
※ 編輯: fxckingugly 來自: 118.160.222.15 (09/04 08:39)
... <看更多>