📜 [專欄新文章] [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.

👏 歡迎轉載分享鼓掌

OSSLab Geek Lab解讀一下最近鬧的滿城風雨的公民實驗室的Zoom安全報告
這是篇非常棒的如何拆解加密封包還原視訊跟音訊資安文...
1. H.264視訊碼流最小單位為NALU
一個NALU = 一組對應於視頻編碼的NALU頭部信息+ 一個原始字節序列負荷(RBSP,Raw Byte Sequence Payload).
這邊nal_unit_type都為0 ,無法判定類型.
不過最後有分析出NAL Payload有後面數據大小,為data slice解密後,組合後為H.264 video stream.

2.對電腦DRAM 做數位鑑識,發現名為conf.skey此為AES 128 key 全部使用者跟會議內容都用此key加密傳送跟接收後解密.

3.錄到封包後,要考慮到一個client都用同個SSRC,另外用時間戳組來拼順序,用key解密再組合成完整視訊raw檔案.

4.音訊一樣加密,推測用啥音訊codec ,是利用RTP間隔時間戳相隔多大來判定.640所以應該為Silk16 codec.

5.在Linux版本Zoom設定proxy上設為自建的mitmproxy, 會報警告說未驗證.從mitmproxy也可得到密鑰AES-128 conf.skey

6.測試中發現在加拿大跟美國通訊用戶 AES-key 是由52.81.151.250位於北京Server配送的
因此最終懷疑,確實有可能.若中國政府要求可取得此密鑰若有測錄封包就可解密還原內容.

7.最後Zoom官方的回應是
中國以外的用戶,會立即將中國大陸的數據中心從服務器中刪除。

圖片引用
UniHub 有你好棒
參考

https://citizenlab.ca/2020/04/move-fast-roll-your-own-crypto-a-quick-look-at-the-confidentiality-of-zoom-meetings/

http://0rz.tw/HOiaK

https://commons.erau.edu/cgi/viewcontent.cgi?article=1174&context=jdfsl

http://blog.gitdns.org/2017/03/14/h264/

#OSSLab #數位鑑識 #拜託國家訂的資安檢測要這樣水準

📜 [專欄新文章] 2019 台北以太坊社群回顧
✍️ Juin Chiu
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

很快地，2019 年過去了，台北以太坊社群（TEM）也滿 3 歲了，過去一年，TEM 完成了許多重大的里程碑：

舉辦台灣最大的區塊鏈技術研討會 Crosslink

主持台灣開源界最大的研討會 COSCUP 的區塊鏈議程

參加世界最大的區塊鏈技術研討會 DEVCON

Medium 專欄累積 30+ 篇優質文章

Youtube 頻道累積 50+ 個技術演講

在這篇文章中，我們首先來審視 2019 年以太坊取得重大進展的技術：以太坊2.0與零知識證明，接著再回顧 TEM 於 2019 的優質專欄文章。

*本文由 Juin Chiu 與 Chih-Cheng Liang 共同整理

以太坊重大進展

以太坊2.0的信標鏈

對一般大眾最重要最能吸收的事情大概是 Eth2.0 的信標鏈有測試網路了。透過儀表板網站 www.beaconcha.in 可以看見 Prysmatic Labs 團隊的測試網路的動態。細節很多，但本文就只談這張圖最上面有出現的東西。

在 Eth2.0 沒有挖礦和礦工了，取而代之的是抵押以太幣的驗證者（Validator）來成為資料的寫入者。因此也沒有「區塊時間」這個詞了，新協定以 12 秒為一個「時段」（Slot），信標鏈隨機分配驗證者在指定的時間點產出區塊。在 32 個時段的時間，稱為一個「時期」（Epoch），約 6.4 分鐘，信標鏈會處理驗證者的賞、罰、進、出。在儀表板的左上角可以看到 Epoch 與 Slot 的數字，代表距離最早最古老的區塊多久了。

要怎麼成為驗證者呢？首先要在以太坊 1.0 主網路的抵押合約上，送出一筆交易（在信標鏈測試網路則是送到 Goerli 測試網路）。這筆交易會註冊驗證者的公鑰，並且存入押金（在正式網路是 32 ETH ，測試網路則是 3.2 ETH）。送完之後就排隊等待信標鏈激活驗證者，驗證者就需要開始執行信標鏈分配的任務了。在畫面中間可以看到左邊是 27539 個活躍的驗證者，右邊則是有 4623 個排隊進入的。

在這種基於押金的網路，系統的威脅來自於攻擊者買通大量驗證者，送出矛盾訊息，致使於系統不同節點無法取得共識，鏈資料不可挽回的分叉為兩條。因此系統累積的總押金越多，代表攻擊者成本越高。畫面最右上角左邊即為總押金，右邊為平均一個驗證者的餘額。

假期間和親朋好友一起跑一個驗證者節點，是個活絡氣氛的好活動。要做到這件事，目前 Prysm 客戶端有最友善的介面，請點 連結。程式也用 Docker 包好了，免煩惱安裝。

也記得 Eth2.0 協定有 9 個團隊 用不同程式語言實作。例如：有 Python 語言的客戶端 Trinity ，以及 Rust 語言客戶端 Lighthouse。基本上不用擔心找不到自己喜歡的程式語言的實作。

零知識證明

2019 年，零知識證明的理論與應用也突飛猛進，Kimi Wu 剛好寫了一篇很棒的文獻調查。

前年底提出的 zk rollup，目前由 Matter Labs 在開發，Matter Labs更在上個月（2019/12）發表了 ZK Sync，解決了因為產生證明（proof）而延伸的延遲問題。

此外 Iden3 跟 ConsenSys 也有 zk rollup 的專案。在以太坊研究論壇有基於 zk rollup 的一個提案，是可以達到 匿名性的 zk rollup。

Semaphore是一個基於零知識證明的一個訊號系統，發送者可以不揭露身份的狀況下廣播任何訊息(an arbitrary string)。 Semaphorejs 延續 Semaphore 的核心概念，並將整個概念更加完整化，從前端網頁到後端服務。

這兩年才發表的 zk-STARKs，也在去年年初跟 0x 合作，推出基於 zk-STARKs 的 去中心化交易所。

在技術上，去年下半年有新的論文，使用 DARK compiler 可以讓 SNARKs 達到公開性（Transparent）。還有 MARLIN, SONIC, PLONK 等可通用且可更新的可信設定（trusted setup）。STARKs 的 FRI 驗證方式也默默地跟 SNARKs 做結合。（東西越來越多，根本看不完 QQ）

零知識證明在區塊鏈的重要用途就是「擴展」和「隱私」。技術上的進展，一般可以觀察證明方產出證明的時間、證明的資料大小、驗證方驗證的時間、需不需要可信設定、可信設定有什麼限制、以及抵抗量子電腦的能力。

社群專欄優質文章

Crossslink 2019

Crosslink 2019 Taiwan｜以太坊 2.0 的未來藍圖及挑戰

Crosslink Recap: Design pattern: build your first profitable DApp and smart contract

Private key security and protection / 私錀的安全與保護 — Tim Hsu

Crosslink 2019 Taiwan｜LibraBridge: 橋接 Libra 與 Ethereum

Aragon Fundraising：下一代的去中心化募資平台

The next generation Ethereum Virtual Machine — Ewasm VM

libp2p — 模組化的點對點網路協議

教學（Tutorial）

一分鐘做出自己的代幣購買App

Web3 Java 開發：用 Geth、Ganache 及 Infura 測試和 Smart Contract 互動

Let’s Capture The Flag! Etheruem CTF Tutorial 從零開始破解智能合約漏洞！

Your First Transaction on Facebook Libra — 動手玩 Libra

ELI5! 區塊鏈到底在幹嘛？

共識協定（Consensus）

Casper FFG：以實現權益證明為目標的共識協定

Casper FFG 與 Casper CBC 的瑜亮情結

若想搞懂區塊鏈就不能忽視的經典：PBFT

密碼學（Cryptography）

Ethereum RNG (RANDAO & VDF)

深入瞭解 zk-SNARKs

瞭解神秘的 ZK-STARKs

隱私性與匿名性（Privacy and Anonymity）

新一代加密貨幣Grin和MimbleWimble區塊鏈解析

Monero.門羅幣 隱匿交易的基礎介紹

隱私、區塊鏈與洋蔥路由

資料可得性（Data Availability）

Data Availability on Ethereum 2.0 Light Node

Fraud and Data Availability Proofs

點對點網路（p2p Network）

連Ethereum都在用！用一個例子徹底理解DHT

針對DHT的花式攻擊與精簡對策

智能合約（Smart Contract）

深入解析Solidity合約

Upgradable Smart Contracts using zos

Reason Why You Should Use EIP1167 Proxy Contract. (With Tutorial)

去中心化金融（DeFi）

DeFi 項目《Uniswap》完整解析（一）Uniswap 是什麼？

解析 DeFi 項目《Uniswap》（二）Uniswap 如何使用？

去中心化身份（DID）

我們與「身份自主」的距離

其他（Miscellaneous）

論言論自由

作為負債的控制

0x 黑客松 — 獲獎作品回顧與分析

技術解析台灣交易所BitoPro駭客攻擊

總結

2019 是個樸實無華但充實的一年，除了在底層技術方面有所進展，在應用方面，例如去中心化金融（DeFi）與去中心化身份（DID），也逐漸獲得大眾的興趣，期待 2020 年區塊鏈能為這世界帶來更多驚奇！

2019 台北以太坊社群回顧 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌