📜 [專欄新文章] 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.
👏 歡迎轉載分享鼓掌
github packages 在 iThome Security Facebook 的最讚貼文
GitHub近日宣布幾項重大進展,不只是GitHub Actions與GitHub Packages正式版發布,更引人注目的是,提出了「北極程式碼保險櫃」(GitHub Arctic Code Vault),目的是讓重要程式碼的保存能長久延續下去,同時也公布一項封存專案GitHub Archive Program
github packages 在 Taipei Ethereum Meetup Facebook 的精選貼文
📜 [專欄新文章] A Secure State Channels Framework for Ethereum by Liam Horne 解析以太坊上的安全狀態通道
✍️ 田少谷 Shao
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
Crosslink 第二天早上由 Liam Horne,狀態通道的主要開發團隊 L4 共同創辦人開場。本以為這場會提到筆者前一天晚上還看得霧煞煞的 Counterfactual ,沒想到這次的演講較為科普、以分享開發近況為主,也被以太坊基金會研究員 Chih-Cheng Liang 稱為最接地氣的一場!
何謂狀態通道?
比特幣的支付通道
若熟悉閃電網路,比特幣的支付通道是一個記錄支付行為的通道,只有開關通道時會接觸到區塊鏈。
假設A公司與B公司有頻繁的交易需求,兩方各自把 10 元放入支付通道中:
19:00 交易開始,兩方所擁有的錢: (10,10)
19:15 A->B 3元: (7,13)
20:10 B->A 7元: (14,6)
20:30 A->B 13元: (1,19)
21:45 B->A 4元: (5,15)
到了 21:45 時,交易結束,此時可以將交易結果 (5,15) 寫到區塊鏈上並分配結餘,而區塊鏈上有的紀錄就只有以下兩筆。
19:00 交易開始,兩方所擁有的錢: (10,10)
21:45 交易結束,兩方所擁有的錢: (5,15)
這代表著交易的結果能被記錄到區塊鏈上,卻大幅減少了要和區塊鏈互動的次數,不只可以降低交易雙方等待區塊鏈回應的次數與時間,也讓區塊鏈要處理的交易數量減少 。
以上只是提供一個很粗淺的例子,可以參考以下連結,精美圖示有助理解:
【動區專題】五分鐘看懂:圖說閃電網路 Ligntning Network
狀態通道 State Channel
由於狀態通道是在以太坊上,和比特幣的環境不同,所以實作方法不盡相同 (提示:UTXO),但本質上是相同的概念:只要牽涉到「狀態轉換 state-altering」,我們就能開一個通道讓交易參與者在通道中任意次數改變「狀態的值」,而最終將結果寫回區塊鏈上就好。
這邊我引用 Pelith 創辦人 Ping Chen 對於狀態通道精闢的解釋:
狀態通道通常是有別種邏輯疊在上面的通道 — 陳品
也就是說,相對於支付通道的邏輯就只是參與者虛擬貨幣的數量,狀態通道通常指的是該應用場景有自身的邏輯/規則。
舉例來說,在一遊戲中,玩家所擁有的虛寶就可以被視為是許多種狀態:遊戲中金幣及等級的是數值、但同時也是狀態;而 (0,1) 可以用來代表道具的擁有狀態 (沒有,有)。
假設一玩家 A 在遊戲中的起始狀態為 (電卷, 金牌, 鞍切, 金幣, 經驗值) = (0, 0, 0, 300, 1),隨著遊戲進行,虛寶/狀態的改變:
A 花費 100 金購買了金牌: (0, 1, 0, 200, 1)
A 首殺獲得 200 金、升兩等: (0, 1, 0, 400, 3)
A 花費 300 金用金牌合成了鞍切: (0, 0, 1, 100, 3) # 其實好像還要妖刀?xD
A 擊殺了 B 玩家,升一等: (0, 0, 1, 100, 4)
當玩家要登出、暫停遊戲時,最後的 (0, 0, 1, 100, 4) 就可以被更新到區塊鏈上,而下次登入時就會讀取這個區塊鏈上的狀態讓玩家繼續遊玩。
若了解了此例,就不難想像為什麼狀態通道被提出之時,遊戲以及虛擬貨幣的支付被視為最適合運用的兩個場景:給定參與者=玩家,在限定的場域中=遊戲,進行狀態的更新。
更多細節可以參考此一概念的提出人 Jeff Coleman 的解釋:點我
決策者 Mover
每一個狀態都有一位決策者,由通道中所有參與者輪流擔任。決策者透過對一狀態進行「簽署」來表達是否同意此狀態,也就是說狀態的正當性取決於當前的簽署是否來自正確的決策者。
狀態確認 Valid Transaction
狀態的先後順序是驗證狀態是否有效的方法。取決於應用的場景,有不同的實作方式。若簡單以一個計數器 counter 來實作,只要要求新狀態的計數值為舊狀態 +1,即可驗證。
state(N).counter + 1 == state(N+1).counter
關閉通道與終結性 Finality
當沒有更多交易或有參與者決定要結束交易時,只要全部參與者皆同意就可以關閉通道,ex: 給一 boolean 變數 isFinal,全部人都把自己的 isFinal 皆設為 true 就可以將通道關閉。
萬一有參與者半途消失了?Finality 終結性指的就是「每一個狀態都可以是最終的狀態」。假設部分參與者消失,只要有搭配的機制,例如:計時器,就一定會輪替到仍在線的人;即使參與者全部消失,當前的狀態因具備終結性,所以也能被提交為最終的狀態。
狀態通道實作的規劃與開發進程
Liam 將實作狀態通道的規劃劃分成上圖的六層:
Protocol & Contracts:
- State Progression Protocol
這邊就是上方的「決策者、狀態確認、關閉通道與終結性」。
除了以上所提及的內容,目前團隊也正在開發更方便的協議 Protocol Hardening:有別於交易的結束需要所有參與者的同意,目標是想做到「在特定時間內,任一參與者都能自行決定交易的推進或結束而不受其他參與者影響」。
- Channel Funding Protocol
此處是系統設計的另一個協議 Nitro Protocol,也就是如何開「子通道」,可以參考以下連結:
Nitro Protocol
Client & Hub:
- Client & Protocol Engine
這部分是講 Client 端彼此之間會傳送什麼訊息來進行溝通。
https://specs.counterfactual.com/en/latest/protocols/install-virtual-app.html#the-installvirtualappparams-type
- Client API & Wire Protocol
以下的 Github 專案就是將上方三部分的協議內容實作到網頁端:
counterfactual/monorepo
目前第一版的狀態通道已正在運行了,詳見下方額外學習資源的 Connext。Liam 列出了一些實作第二版時必須納入考量的點:
Robustly store states (i.e., guarantee no accidental money loss)
Automatic detection and responding to challenges
Ability to launch challenges directly with in-browser hooks
Go-to production quality hub software for apps and businesses to use
Browser Wallet UX:
- Wallet Integrations
這些是將狀態通道實作於現存的各種 Wallet 時,需要新增的內容:
https://github.com/counterfactual/monorepo/blob/d3b06b42710c0b7dd93839033cb43da9ac6e0a28/packages/types/src/node.ts
- Wallet UI
最後則是區塊鏈、也是所有新技術能否被廣泛使用的大哉問:該如何設計才能讓使用者有良好的體驗?
在此 Liam 提出實作 Wallet 時可以考慮的要點:
How should a user interact with a state channel?
What are the best patterns for acquiring user consent?
How much does the user have to trust the app?
To what extent can your channel wallet protect you?
What policies should a channel wallet be able to enforce?
額外學習資源
Liam 在本場演講及 Panel Discussion 中,都很鼓勵大家一起跳進來當開發者。他的大致建議如下:看懂相關文章、開發的要求 specs,就可以試著做做看。卡住的時候就到以下連結的討論區詢問他們,包含 Liam 在內的開發人員都會在上面回答問題:
State Channels - A community of state channels researchers from bitcoin, ethereum, and other blockchains
狀態通道的 Github:
State Channels
已成功實作第一版狀態通道的 Connext 專案:
Where will I be able to use v2.0 of Connext?
讓筆者看得霧煞煞的 Counterfactual ,可以進一步提升狀態通道的效率:
Counterfactual: Generalized State Channels on Ethereum
結語
本次演講實為筆者綜觀 Liam 在 Youtube 上的影片後,他對狀態通道最簡單、親民的一次演講,主要著重於介紹開發的進程、應注意的要點,也提供了初探此議題的新手很多學習資源、推坑大家加入開發的建議!
其實陳昶吾博士也曾於 Taipei Ethereum Meetup 詳細介紹過此議題(閃電網路為主),有興趣者可以看以下影片來得到更完整的認識:
最後,如果我的文章有幫助到你/妳,可以看看我的其他文章,歡迎大家一起交流 :)
田少谷 Shao - Medium
一如往常,感謝 Yahsin Huang 及 Chih-Cheng Liang 幫忙審稿,辛苦了!也特別感謝 Ping Chen 耐心回答素未蒙面的我的問題!!
A Secure State Channels Framework for Ethereum by Liam Horne 解析以太坊上的安全狀態通道 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌