📜 [專欄新文章] Optimistic Rollup 就這樣用(2)
✍️ Juin Chiu
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
ERC721 的儲值、轉移與提領
TL;DR
本文會跳過 Optimistic Rollup 的介紹而直接實際演示,關於 Optimistic Rollup 的概念與設計原理筆者將在日後另撰文說明,有興趣的讀者可以先參考下列三篇文章(由淺入深):1. OVM Deep Dive 2. (Almost) Everything you need to know about Optimistic Rollup 3. How does Optimism’s Rollup really work?
本文將演示一個 Optimism Rollup 的 ERC721 範例,程式碼在這裡。
本演示大量參考了以下範例:Optimistic Rollup Example: ERC20。
本演示所使用的 ERC721 Gateway 合約來自這個提案,目前尚未成為官方標準。
環境設置
Git
Node.js
Yarn
Docker
Docker-compose
筆者沒有碰到環境相容問題,但是建議都升到最新版本, Node.js 使用 v16.1.0 或以上版本
Optimism 服務啟動
有關 Optimisim 的所有服務,都包裝在 Optimism 這個超大專案當中了,直接使用原始碼進行組建:
$ git clone git@github.com:ethereum-optimism/optimism.git$ cd optimism$ yarn$ yarn build
組建完成後,就可以在本機啟動服務了:
$ cd ops$ docker-compose build$ docker-compose up
這個指令會啟動數個服務,包括:
L1 Ethereum Node (EVM)
L2 Ethereum Node (OVM)
Batch Submitter
Data Transport Layer
Deployer
Relayer
Verifier
Deployer 服務中的一個參數要特別注意: FRAUD_PROOF_WINDOW_SECONDS,這個就是 OPtimistic Rollup 的挑戰期,代表使用者出金(Withdraw)需等候的時長。在本篇演示中預設為 0 秒。
如果有需要重啟,記得把整個 Docker Volume 也清乾淨,例如: docker-compose down -v
Optimism 整合測試
在繼續接下來的演示之前,我們需要先確認 Optimism 是否有順利啟動,特別是 Relayer 是否運作正常,因此我們需要先進行整合測試:
$ cd optimism/integration-tests$ yarn build:integration$ yarn test:integration
確保 L1 <--> L2 Communication 相關測試通過後再繼續執行接下來的演示內容。
啟動服務及部署合約需要花費一些時間,運行一段時間(約 120 秒)之後再執行測試,如果測試結果全部皆為 Fail,可能是 Optimism 尚未啟動完成,再等待一段時間即可。
ERC721 合約部署
Optimism 啟動成功並且完成整合測試後,接下來進行 ERC721 合約的部署。筆者已將合約及部署腳本放在 optimistic-rollup-example-erc721 這個專案中:
$ git clone git@github.com:ethereum-optimism/optimistic-rollup-example-erc721.git$ cd optimistic-rollup-example-erc721$ yarn install$ yarn compile
接下來我們需要部署以下合約:
ERC721,部署於 L1
L2DepositedEERC721,部署於 L2
OVM_L1ERC721Gateway,部署於 L1
OVM_L1ERC721Gateway 只部署在 L1 上,顧名思義它就是 L1 <=> L2 的「門戶」,提供 Deposit / Withdraw 兩個基本功能,使用者必須透過這個合約來進出 L2。
雖然 OVM_L1ERC20Gateway 是 Optimistic Rollup 官方提供的合約。但是開發者也可以依需求自行設計自己的「門戶」。
OVM_L1ERC20Gateway 目前沒有 Optimism 的官方實作,本演示所使用的 ERC721 Gateway 合約來自這個提案,目前尚未成為官方標準。
接下來,我們直接用腳本進行部署:
$ node ./deploy.jsDeploying L1 ERC721...L1 ERC2721 Contract Address: 0xFD471836031dc5108809D173A067e8486B9047A3Deploying L2 ERC721...L2 ERC721 Contract Address: 0x09635F643e140090A9A8Dcd712eD6285858ceBefDeploying L1 ERC721 Gateway...L1 ERC721 Gateway Contract Address: 0xcbEAF3BDe82155F56486Fb5a1072cb8baAf547ccInitializing L2 ERC721...
ERC721 鑄造、儲值、轉移與提領
鑄造(L1)
初始狀態如下,所有帳戶皆尚未持有任何代幣:
接下來,我們將鑄造 2 個代幣以進行接下來的演示。首先,進入 ETH(L1) 的 Console:
$ npx hardhat console --network ethWelcome to Node.js v16.1.0.Type ".help" for more information.>
取得 Deployer / User 帳戶:
// In Hardhat ETH Console
> let accounts = await ethers.getSigners()
> let deployer = accounts[0]
> let user = accounts[1]
取得 ERC721 及 OVM_L1ERC721Gateway 合約物件,合約地址可以從部署訊息中取得:
// In Hardhat ETH Console
> let ERC721_abi = await artifacts.readArtifact("ExampleToken").then(c => c.abi)
> let ERC721 = new ethers.Contract("0xFD471836031dc5108809D173A067e8486B9047A3", ERC721_abi)
> let Gateway_abi = await artifacts.readArtifact("OVM_L1ERC721Gateway").then(c => c.abi)
> let Gateway = new ethers.Contract("0xcbEAF3BDe82155F56486Fb5a1072cb8baAf547cc", Gateway_abi)
鑄造兩個 ERC721 代幣:
// In Hardhat ETH Console
> await ERC721.connect(deployer).mintToken(deployer.address, "foo")
{ hash: "...", ...}
> await ERC721.connect(deployer).mintToken(deployer.address, "bar")
{ hash: "...", ...}
只有合約的 Owner(deployer) 可以進行鑄造的操作。
確認 Deployer 餘額:
> await ERC721.connect(deployer).balanceOf(deployer.address)
BigNumber { _hex: '0x02', _isBigNumber: true } // 2
確認代幣的 TokenID 與 Owner:
> await ERC721.connect(deployer).ownerOf(1)
'0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266' // deployer
> await ERC721.connect(deployer).ownerOf(2)
'0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266' // deployer
儲值(L1 => L2)
完成以上步驟後,目前的狀態如下:
接下來,授權 OVM_L1ERC721Gateway使用 TokenID 為 2 的代幣:
// In Hardhat ETH Console
> await ERC721.connect(deployer).approve("0xcbEAF3BDe82155F56486Fb5a1072cb8baAf547cc", 2)
{ hash: "...", ...}
在 OVM_L1ERC721Gateway 合約呼叫 Deposit,儲值 TokenID 為 2 的代幣:
// In Hardhat ETH Console
> await Gateway.connect(deployer).deposit(2)
{ hash: "...", ...}
我們可以到 Optimism (L2) 的 Console 確認入金是否成功:
$ npx hardhat console --network optimismWelcome to Node.js v16.1.0.Type ".help" for more information.>
取得 Deployer / User 帳戶:
// In Hardhat Optimism Console
> let accounts = await ethers.getSigners()
> let deployer = accounts[0]
> let user = accounts[1]
取得 L2DepositedERC721 合約物件,合約地址可以從部署訊息中取得:
// In Hardhat Optimism Console
> let L2ERC721_abi = await artifacts.readArtifact("OVM_L2DepositedERC721").then(c => c.abi)
> let L2DepositedERC721 = new ethers.Contract("0x09635F643e140090A9A8Dcd712eD6285858ceBef", L2ERC721_abi)
確認入金是否成功:
// In Hardhat Optimism Console
> await L2DepositedERC721.connect(deployer).balanceOf(deployer.address)
BigNumber { _hex: '0x01', _isBigNumber: true } // 1
> await L2DepositedERC721.connect(deployer).ownerOf(2)
'0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266' // deployer
ERC721 轉移(L2 <=> L2)
完成以上步驟後,目前的狀態如下:
接下來,我們在 L2 從 Deployer 轉移代幣給 User:
// In Hardhat Optimism Console
> await L2DepositedERC721.connect(user).balanceOf(user.address)
BigNumber { _hex: '0x00', _isBigNumber: true } // 0
> await L2DepositedERC721.connect(deployer).transferFrom(depoyer.address, user.address, 2)
{ hash: "..." ...}
> await L2DepositedERC721.connect(user).balanceOf(user.address)
BigNumber { _hex: '0x01', _isBigNumber: true } // 1
> await L2DepositedERC721.connect(user).ownerOf(2)
'0x70997970C51812dc3A010C7d01b50e0d17dc79C8' // user
ERC721 提領(L2 => L1)
完成以上步驟後,目前的狀態如下:
接下來,我們用 User 帳戶提領資金,在 L2DepositedERC721 合約呼叫 Withdraw:
// In Hardhat Optimism Console
> await L2DepositedERC721.connect(user).withdraw(2)
{ hash: "..." ...}
> await L2DepositedERC721.connect(user).balanceOf(user.address)
BigNumber { _hex: '0x00', _isBigNumber: true }
最後,檢查在 L1 是否提領成功:
// In Hardhat ETH Console
> await ERC721.connect(user).balanceOf(user.address)
BigNumber { _hex: '0x01', _isBigNumber: true } // 1
> await ERC721.connect(deployer).balanceOf(deployer.address)
BigNumber { _hex: '0x01', _isBigNumber: true } // 1
> await ERC721.connect(user).ownerOf(2)
'0x70997970C51812dc3A010C7d01b50e0d17dc79C8' // user
由於挑戰期為 0 秒,因此提領幾乎無需等待時間,頂多只需數秒鐘
做完上述所有操作,最終狀態應該如下:
總結
本文演示了:
Optimistic Rollup 相關服務的本機部署
ERC721 L1 => L2 的儲值(Deposit)
ERC721 L2 帳戶之間轉移(Transfer)
ERC721 L2 => L1 的提領(Withdraw)
筆者未來將繼續擴充此系列的教學內容,例如支援其他標準的合約如 ERC1155,以及如何運行 Optimistic Rollup 生態系中最重要的驗證者(Verifier),敬請期待。
參考資料
OVM Deep Dive
(Almost) Everything you need to know about Optimistic Rollup
How does Optimism’s Rollup really work?
Optimistic Rollup Official Documentation
Ethers Documentation (v5)
Optimistic Rollup Example: ERC20(Github)
Optimism (Github)
optimism-tutorial (Github)
l1-l2-deposit-withdrawal (Github)
Proof-of-concept ERC721 Bridge Implementation (Github)
Optimistic Rollup 就這樣用(2) was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
「erc20 address」的推薦目錄:
- 關於erc20 address 在 Taipei Ethereum Meetup Facebook 的最佳貼文
- 關於erc20 address 在 Taipei Ethereum Meetup Facebook 的最佳貼文
- 關於erc20 address 在 Taipei Ethereum Meetup Facebook 的最佳解答
- 關於erc20 address 在 openzeppelin-contracts/ERC20.sol at master - GitHub 的評價
- 關於erc20 address 在 How to mint ERC20 with it's address - Stack Overflow 的評價
- 關於erc20 address 在 How to use ERC20 tokens in Trezor Suite. - YouTube 的評價
- 關於erc20 address 在 Send ERC20 token from a forwarder contract address to ... 的評價
- 關於erc20 address 在 ERC-20 - Hyperledger FireFly Docs 的評價
erc20 address 在 Taipei Ethereum Meetup Facebook 的最佳貼文
📜 [專欄新文章] Optimistic Rollup 就這樣用(1)
✍️ Juin Chiu
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
ERC20 的入金、轉帳與出金
TL;DR
本文會跳過 Optimistic Rollup 的介紹而直接實際演示,關於 Optimistic Rollup 的概念與設計原理我將在日後另撰文說明,有興趣的讀者可以先參考下列三篇文章(由淺入深):1. OVM Deep Dive 2. (Almost) Everything you need to know about Optimistic Rollup 3. How does Optimism’s Rollup really work?
本文將演示一個 Optimism Rollup 範例,程式碼在這裡。
本演示大量參考了以下這兩個官方範例:optimism-tutorial、l1-l2-deposit-withdrawal。
環境設置
Git
Node.js
Yarn
Docker
Docker-compose
筆者沒有碰到環境相容問題,但是建議都升到最新版本, Node.js 使用 v16.1.0 或以上版本
Optimism 服務啟動
有關 Optimisim 的所有服務,都包裝在 Optimism 這個超大專案當中了,直接使用原始碼進行組建:
$ git clone git@github.com:ethereum-optimism/optimism.git$ cd optimism$ yarn$ yarn build
組建完成後,就可以在本機啟動服務了:
$ cd ops$ docker-compose build$ docker-compose up
這個指令會啟動數個服務,包括:
L1 Ethereum Node (EVM)
L2 Ethereum Node (OVM)
Batch Submitter
Data Transport Layer
Deployer
Relayer
Verifier
Deployer 服務中的一個參數要特別注意: FRAUD_PROOF_WINDOW_SECONDS,這個就是 Optimistic Rollup 的挑戰期,代表使用者出金(Withdraw)需等候的時長。在本篇演示中預設為 0 秒。
如果有需要重啟,記得把整個 Docker Volume 也清乾淨,例如: docker-compose down -v
Optimism 整合測試
在繼續接下來的演示之前,我們需要先確認 Optimism 是否有順利啟動,特別是 Relayer 是否運作正常,因此我們需要先進行整合測試:
$ cd optimism/integration-tests$ yarn build:integration$ yarn test:integration
確保 L1 <--> L2 Communication 相關測試通過後再繼續執行接下來的演示內容。
啟動服務及部署合約需要花費一些時間,運行一段時間(約 120 秒)之後再執行測試,如果測試結果全部皆為 Fail,可能是 Optimism 尚未啟動完成,再等待一段時間即可。
ERC20 合約部署
Optimism 啟動成功並且完成整合測試後,接下來進行 ERC20 合約的部署。筆者已將合約及部署腳本放在 optimistic-rollup-example-erc20 這個專案中:
$ git clone git@github.com:ethereum-optimism/optimistic-rollup-example-erc20.git$ cd optimistic-rollup-example-erc20$ yarn install$ yarn compile
接下來我們需要部署以下合約:
ERC20,部署於 L1
L2DepositedEERC20,部署於 L2
OVM_L1ERC20Gateway,部署於 L1
其中,ERC20 與 L2DepositedERC20 是由上面的範例專案編譯的,可以直接在範例專案中直接取得 ABI;而 OVM_L1ERC20Gateway 則是由 Optimism 編譯的,屬於 Optimistic Rollup 協定的一部分,無法直接在範例專案中取得 ABI。
因此在部署以上三個合約前,我們需先手動將 OVM_L1ERC20Gateway 編譯後的生成品 (Artifacts)——即 ABI,複製到此專案中:
$ cp -r ~/projects/optimism/packages/contracts/artifacts/contracts/optimistic-ethereum/OVM/bridge/tokens/OVM_L1ERC20Gateway.sol ~/projects/optimistic-rollup-example-erc20/artifacts/contracts/
OVM_L1ERC20Gateway 只部署在 L1 上,顧名思義它就是 L1 <=> L2 的「門戶」,提供 Deposit / Withdraw 兩個基本功能,使用者必須透過這個合約來進出 L2。
雖然 OVM_L1ERC20Gateway 是 Optimistic Rollup 官方提供的合約。但是開發者也可以依需求自行設計自己的「門戶」。
接下來,我們直接用腳本進行部署:
$ node ./deploy.jsDeploying L1 ERC20...Deploying L1 ERC20...L1 ERC20 Contract Address: 0x1429859428C0aBc9C2C47C8Ee9FBaf82cFA0F20fDeploying L2 ERC20...L2 ERC20 Contract Address: 0x67d269191c92Caf3cD7723F116c85e6E9bf55933Deploying L1 ERC20 Gateway...L1 ERC20 Gateway Contract Address: 0xB0D4afd8879eD9F52b28595d31B441D079B2Ca07Initializing L2 ERC20...
ERC20 入金、轉帳與出金
ERC20 入金(L1 => L2)
目前餘額:
在合約部署完成後,Deployer 是目前唯一有資金的帳戶,接下來我們就進行入金(Deposit),將 Deployer 的資金從 L1 搬到 L2。
首先,進入 ETH(L1) 的 Console:
$ npx hardhat console --network ethWelcome to Node.js v16.1.0.Type ".help" for more information.>
取得 Deployer / User 帳戶:
// In Hardhat ETH Console
> let accounts = await ethers.getSigners()> let deployer = accounts[0]> let user = accounts[1]
取得 ERC20 及 OVM_L1ERC20Gateway 合約物件,合約地址可以從部署訊息中取得:
// In Hardhat ETH Console
> let ERC20_abi = await artifacts.readArtifact("ERC20").then(c => c.abi)> let ERC20 = new ethers.Contract("0x1429859428C0aBc9C2C47C8Ee9FBaf82cFA0F20f", ERC20_abi)> let Gateway_abi = await artifacts.readArtifact("OVM_L1ERC20Gateway").then(c => c.abi)> let Gateway = new ethers.Contract("0xB0D4afd8879eD9F52b28595d31B441D079B2Ca07", Gateway_abi)
先授權 OVM_L1ERC20Gateway 花費 ERC20:
// In Hardhat ETH Console
> await ERC20.connect(deployer).approve("0xB0D4afd8879eD9F52b28595d31B441D079B2Ca07", 10000)> await ERC20.connect(user).approve("0xB0D4afd8879eD9F52b28595d31B441D079B2Ca07", 10000)
注意:Deployer 及 User 都需要對 OVM_L1ERC20Gateway 進行授權,否則在接下來的出金步驟時 Relayer 會出錯
接著,在 OVM_L1ERC20Gateway 合約呼叫 Deposit:
// In Hardhat ETH Console
> await Gateway.connect(deployer).deposit(1000)
我們可以到 Optimism (L2) 的 Console 確認入金是否成功:
$ npx hardhat console --network optimismWelcome to Node.js v16.1.0.Type ".help" for more information.>
取得 Deployer / User 帳戶:
// In Hardhat Optimism Console
> let accounts = await ethers.getSigners()> let deployer = accounts[0]> let user = accounts[1]
取得 L2DepositedERC20 合約物件,合約地址可以從部署訊息中取得:
// In Hardhat Optimism Console
> let L2ERC20_abi = await artifacts.readArtifact("L2DepositedERC20").then(c => c.abi)> let L2DepositedERC20 = new ethers.Contract("0x67d269191c92Caf3cD7723F116c85e6E9bf55933", L2ERC20_abi)
確認入金是否成功:
// In Hardhat Optimism Console
> await L2DepositedERC20.connect(deployer).balanceOf(deployer.address)BigNumber { _hex: '0x03E8', _isBigNumber: true } // 1000
ERC20 轉帳(L2 <=> L2)
完成以上步驟後,目前的餘額如下:
接下來,我們在 L2 從 Deployer 轉移一部分資金給 User:
// In Hardhat Optimism Console
> await L2DepositedERC20.connect(user).balanceOf(user.address)BigNumber { _hex: '0x00', _isBigNumber: true } // 0> await L2DepositedERC20.connect(deployer).transfer(user.address, 1000){ hash: "..." ...}> await L2DepositedERC20.connect(wallet_1).balanceOf(user.address)BigNumber { _hex: '0x03E8', _isBigNumber: true } // 1000
ERC20 出金(L2 => L1)
完成以上步驟後,目前的餘額如下:
接下來,我們用 User 帳戶提領資金,在 L2DepositedERC20 合約呼叫 Withdraw:
// In Hardhat Optimism Console
> await L2DepositedERC20.connect(user).withdraw(1000){ hash: "..." ...}> await L2DepositedERC20.connect(user).balanceOf(user.address)BigNumber { _hex: '0x00', _isBigNumber: true }
最後,檢查在 L1 是否提領成功:
// In Hardhat ETH Console
> await ERC20.connect(user).balanceOf(user.address)BigNumber { _hex: '0x03E8', _isBigNumber: true } // 1000
由於挑戰期為 0 秒,因此提領幾乎無需等待時間,頂多只需數秒鐘
做完上述所有操作,餘額應該如下:
總結
本文演示了:
Optimistic Rollup 相關服務的本機部署
ERC20 L1 => L2 的入金(Deposit)
ERC20 L2 帳戶之間轉帳(Transfer)
ERC20 L2 => L1 的出金(Withdraw)
筆者未來將繼續擴充此系列的教學內容,例如 ERC721 / ERC1155 的使用方式,敬請期待。
參考資料
OVM Deep Dive
(Almost) Everything you need to know about Optimistic Rollup
How does Optimism’s Rollup really work?
Optimistic Rollup Official Documentation
Ethers Documentation (v5)
Optimism (Github)
optimism-tutorial (Github)
l1-l2-deposit-withdrawal (Github)
Optimistic Rollup 就這樣用(1) was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
erc20 address 在 Taipei Ethereum Meetup Facebook 的最佳解答
📜 [專欄新文章] [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.
👏 歡迎轉載分享鼓掌
erc20 address 在 How to use ERC20 tokens in Trezor Suite. - YouTube 的推薦與評價

This video explains how to use ERC20 tokens in Suite. ERC20 tokens run on ETH blockchain and you need to use your ETH address to receive and ... ... <看更多>
erc20 address 在 openzeppelin-contracts/ERC20.sol at master - GitHub 的推薦與評價
* - the caller must have a balance of at least `amount`. */. function transfer(address to, uint256 amount) ... ... <看更多>