📜 [專欄新文章] 類 Python 的合約語言 Vyper 開發入門:與 Solidity 差異、用 Truffle 部署、ERC20 賣幣合約實做
✍️ 田少谷 Shao
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
有鑒於個人近期關注的 Uniswap 及 Curve 皆用 Vyper 實作,索性瀏覽了官方文件並嘗試一些開發工具,希望此文能減少一些讀者初嘗 Vyper 會遇到的麻煩!
Vyper and Solidity
Outline
一. Vyper 極簡介二. 與 Solidity 語法差異三. 開發、開發環境設置 1. 語法高亮 2. 本地 Vyper compiler 安裝 3. 使用 Truffle 操作 ERC20 - 安裝 Truffle - 發幣 - 寫個簡易賣幣合約四. 已知 Remix 問題 五. 結語
一. Vyper 極簡介
Vyper 是除 Solidity 外,以太坊上的另一智能合約 (Smart contract) 語言。其語法和 Python 相近,但畢竟也是寫合約的語言,邏輯差異不大,所以若熟悉 Solidity 應該不難理解用 Vyper 寫出的合約!
Vyper 主要被設計和 Solidity 的區別是安全性及可讀性,這部分會在下一段落及後方的實作中舉例說明。
二. 與 Solidity 語法差異
Vyper 與 Solidity 的差異有許多,在本段只就個人認為感受較深的三點進行說明,其他差異只進行翻譯,有興趣的讀者可以到官方文件詳細了解:https://vyper.readthedocs.io/en/latest/index.html
1. 沒有 modifier
Solidity 常見的 onlyOwner() modifier; 由於 gist 沒有 Solidity 的語法高亮,故截圖
在 Vyper 中單純用 assert 及 assert_modifiable 來進行條件檢查,兩者差別為若要檢查函數執行後的返還值,要用後者,如下圖:
Vyper 寫法
2. 沒有 Class inheritance 繼承
繼承是物件導向程式設計 (OOP) 的核心概念,但各種繼承關係有時候確實很複雜。Vyper 沒有繼承,這無疑大幅地增加了程式可讀性及安全性,以及降低審計程式碼的難度。在此提供一個例子供不熟悉 OOP 複雜之處的讀者有個概念:
source: https://consensys.github.io/smart-contract-best-practices/recommendations/#multiple-inheritance-caution
在上例中,contract A 的 fee 值 (因繼承自 contract B 和 C,故有 fee 一值) 是 5、a 值也是 5 (因繼承自 contract Final,故有 a 一值)。原因是 A 先繼承 B 再繼承 C,因此 contract A 中的 setFee() 是使用了 contract C 的 setFee(),而 a 值是由於 C(5),這代表 contract C 的 constructor (舊版本中即 function C(),函式名稱同 contract 名稱) 被傳入的值為 5。
稍微延伸一下以上概念,將 contract A 改成:contract A is C, B。如此一來,a 值還有 fee 值都會是 3,因為這次 A 先繼承 C 再繼承 B,因此最終吃到的值是 contract B 的。
以上就是 OOP 繼承的複雜之處的簡單範例說明,應該能稍微感受到爲什麼除去繼承後會大幅提高可讀性及安全性,畢竟即使是熟悉 OOP 的人有時頭腦一混亂也會開始懷疑自己寫的程式碼繼承結構是否正確 …
3. 沒有 dynamic array 動態陣列
這應該是目前 Vyper 設計中爭議最大的部分。沒有動態陣列代表在宣告陣列時需要宣告其長度,也就是說 Solidity 中的寫法 uint[], bool[] 等等,這些是不會出現在 Vyper 的。在 Vyper 中只能出現諸如:
# Vyper 的變數宣告方式為 變數名稱: 存取範圍(變數型態(若為陣列給長度))
values: uint256[10]participants: public(address[20])
可以看到上方的 uint256 及 address 兩陣列皆需要宣告長度,不能不宣告而使其動態地配置空間。
沒有動態陣列固然可以確保執行運算的範圍、次數,但一來動態陣列真的很方便、二來在 Solidity 有此功能而 Vyper 卻沒有的情況下可能會造成麻煩,詳見此一討論串:點我。
4. 沒有 inline assembly,程式碼中不會有組合語言
5. 沒有 function overloading,函式不會因傳入的參數數目不同而結果不同
6. 沒有 operator overloading,運算符號不會有不同於預設的自定義功能
7. 沒有無限迴圈,可免於 gas limit attack
8. 十進位定點數 decimal fixed point 而非二進位 (binary) 定點數,詳見:點我
三. 開發、開發環境設置
結論先講
開發 Vyper 的最佳姿勢目前個人認為是在本地裝上 Vyper compiler、用 Truffle 部署,並在撰寫時將檔名後加上 .py 就能有 Python 的語法高亮👌
1. 語法高亮 (syntax highlighting)
有語法高亮絕對是舒服地寫程式的第一步。
Remix 有 Vyper 的語法高亮,但一來個人目前不推薦使用 Remix 來撰寫 Vyper,原因詳見下方 4. 已知 Remix 問題;二來 Remix 的語法高亮其實也沒有很清楚,因此個人推薦:在本地開發,將檔名後加上 .py 就會有 Python 的語法高亮。
2. 本地 Vyper compiler 安裝
照官方說明使用 Python 的虛擬環境 virtualenv:
source: https://vyper.readthedocs.io/en/latest/installing-vyper.html#installing-vyper
簡單兩點提醒:
如果中間那行報錯但確實已經有 Python,則可能是版本問題。依照自己電腦上的版本改成相應的即可,ex: python3.6 改成 python3
進入虛擬環境後(檔案路徑前方應有 vyper-venv 的提示),使用此指令: vyper {檔案名稱}.vy,即可編譯 .vy 檔;使用完畢後輸入 deactivate 即可退出
3. 使用 Truffle 操作 ERC20
安裝 Truffle
Truffle 雖有冗餘的 migration 但也別無他法,畢竟 Remix 目前仍不完善 :(
下載流程可以照官方文件,使用 vyper-example:
source: https://github.com/truffle-box/vyper-example-box
由於我們會接上測試網 Ropsten,因此還要下載 truffle-hdwallet-provider:
source: https://github.com/trufflesuite/truffle-hdwallet-provider
接者就可以開始使用 Vyper 寫合約了!
發幣
由於 Vyper 的官方文件中已經有許多優質範例,因此本文希望來點不一樣但大家卻又很熟悉的…以 ERC20 為例(這千篇一律的主題xD):
用 Curve 的 ERC20 程式碼為範本,發一個幣(又要發…)
寫一個簡易賣幣合約
選擇這個主題一方面畢竟 ERC20 是以太坊的最大宗應用之一,二來有興趣的讀者可以透過讀 ERC20 的程式碼來熟悉 Vyper,並在看過本文的流程後對於用 Vyper+Truffle 來操作 ERC20 有完整的概念!
好的,首先複製一份 Curve 的 ERC20 程式碼(看到就順手拿來用),並複製到 Truffle 所在路徑的 contracts 資料夾中:https://github.com/curvefi/curve-contract/blob/pool_compound/vyper/ERC20.vy
由於第一點希望著重在跑一次流程,因此不改動合約的程式碼。
將 ERC20.vy 複製到 contracts 資料夾中後,到 migrations 資料夾開啟 2_deploy_contracts.js,首先將 require() 中的參數改為 ERC20.vy 的檔名 ERC20,再來依照自己喜好決定幣的名稱、代號、小數點位數及發行總量,輸入於 deployer.deploy() 中。
接著,為了和測試網 Ropsten 互動,需要將以下程式碼寫入 truffle-config.js。
第二行的 privateKeys 是帳號的私鑰。以下實作需要兩個帳號來操作,因此請從錢包匯入兩組私鑰(並非助憶詞)。
在第 13 行中 HDWalletProvider 此函式的第三個參數代表要用第幾個帳號最為預設帳號(部署合約等),第四個函數代表總共匯入幾組帳號。而第二個參數則是需要至 Infura 申請一個 project 來得到串接 Ropsten 的連結。這兩步驟並非本文重點,因此不詳細解說步驟,Google 搜尋關鍵字應該就會找到方法!
接著,就可以輸入以下指令來將代幣發佈到 Ropsten:
truffle deploy --network ropsten
有進入虛擬環境才可以編譯 .vy 檔,若忘記就會收到如下的錯誤訊息:
記得打開虛擬環境才能編譯 .vy 檔
成功後就可以在 contract address 中看到代幣發佈的位置,加入到 Metamask 中就可以看到。本文的例子是維尼代幣 Winnie the Coin, WTC ;)
contract address 便是 ERC20 的所在
Winnie the Coin, WTC
好了,到此測試網上又多了一個測試用的垃圾廢幣。
寫個簡易賣幣合約
賣幣合約中我想要簡單有兩個功能就好:付錢買幣 、結束銷售,以下就是程式碼。買幣的部分就不寫太詳細,固定價格為 0.01 Ether 可以買 500 代幣。
簡單說明幾點:
Solidity 的 constructor() 在 Vyper 中為 Python 風的 __init__():
函式的屬性(public, private, payable 等等)放在函式上方,與 Python 的修飾器位置相同
總之寫法跟 Python 很像,次方也一樣是用兩次乘法代表:**
變數前加上 self 代表是當前合約的變數/全域變數,因此非常容易與函式中的變數/區域變數做區隔
由於已經在第一行匯入了 ERC20 那份合約,因此透過將地址傳入合約當參數,就可以呼叫在該地址的合約:ERC20(self.tokenAddress) 。並且,可以將部署的合約存成一個變數 erc20 較方便
寫完合約後一樣要更改 migrations 資料夾中的 2_deploy_contracts.js 如下,將代幣所在的地址作為參數輸入。
由於先前已經部署過一次了,因此要重置才能再部署第二次,輸入以下指令:
truffle deploy --reset --network ropsten
部署成功之後就要來試著買幣啦!輸入以下來進入 console:
truffle console --network ropsten
成功進入後應該會看到 truffle(ropsten)> 的字樣。接著,首先取得部署的兩合約,並查看是否有返回合約資訊:
# ERC20 及 SellToken 是先前在 2_deploy_contracts.js 中的變數名稱,代表被部署的合約
let instance1 = await ERC20.deployed()instance1 # 印出 instance1 的資訊
let instance2 = await SellToken.deployed()instance2 # 印出 instance2 的資訊
再來,為了讓 SellToken 可以賣幣,要先用 ERC20 的合約匯幣到 SellToken 的合約。因此,輸入以下指令:
instance1.transfer(instance2.address, 10000)
# 這裡數字只要設為 > 500 就可以
接著,我們要利用第二個帳號去買幣(第一個帳號為預設帳號,因此就是代幣擁有者)。將帳號的資訊存入變數 accounts 中,再指定送出交易的帳號是第二個帳號。由於我個人匯入私鑰的順序是將第一個帳號存在 truffle-config.js 的 privateKeys[0]、第二個帳號存在 privateKeys[1],因此第二個帳號的地址就會在 accounts[1] 的位置:
let accounts = await web3.eth.getAccounts()
instance2.buyToken({from: accounts[1], value: 10000000000000000})
# value 為 10^16 是因為在 SellToken 的 buyToken 函式中買一次要 0.01 Ether, 即為 10^16 wei
然後應該就會在自己的第二個帳號中看到匯入的幣了~
最後,由於合約中結束銷售就是一個自殺 selfdestruct 函式,因此可以呼叫看看,第一個帳戶錢包中的錢應該會增加,因為第二個帳戶有付款買幣;並且,可以到 Ropsten 上瀏覽,應該能看到相關提示:
中間 contract 的右上角有 Self Destruct 的樣式
四. 已知 Remix 問題
Remix 目前有兩個版本,只有新版有 Vyper 的編譯器。在此整理目前遇到的問題,如果有人也遇到可以對照一下本處,可以省去很多自我懷疑xD
不會報錯
Remix 的編譯結果有時會是錯的、和本地端編譯出來的結果不同
舉上方的 SellToken 合約為例,將其複製到 Remix 中使用左邊的 Remote Compiler 有錯,但又不報錯 q_q (ERC20 的合約有在同檔案目錄)
左方有紅色三角形,代表編譯失敗,但沒有報錯訊息可以看…
getter function 竟然要花錢
用 Solidity 寫的合約,查詢 public 變數的值應該是不用消耗 gas 的,但不知何故查詢 Vyper 寫的合約的 public 變數卻要消耗 gas,如下圖…
可以看到中下方有 22026 gas 的消耗
Local compiler 無法使用
圖中的 Local Compiler 此選項,個人雖照官方文件執行 vyper-serve 但卻失敗,因此若有讀者成功希望能留個言不吝分享!
五. 結語
Vyper 作為一個比 Solidity 更新的合約語言,在寫程式碼的方面沒什麼問題,但相關的開發工具、學習資源等都遠不及 Solidity。
Vyper 主打的兩個特色:可讀性的部分相信看完上面的讀者應該已經有些感覺;安全性…小白如作者我倒是沒有感受到顯著的不同。況且 Solidity 已經發展許久,很多錯誤的寫法、知名的安全漏洞大家應該也很熟悉了,還有 Openzeppelin 提供安全合約寫法的範本,因此有待以後高人解說安全性是否真的是 Vyper 較好。
有興趣者可以查看 Vyper 的安全報告:點我,大意是目前 Vyper 的編譯器仍有許多問題待改進! (感謝 Chih-Cheng Liang 的提供)
本文對 Vyper 的介紹及其與 Solidity 的差異只講了個大概,欲知更詳細的介紹還是要麻煩讀者前往官方文件了:https://vyper.readthedocs.io/en/latest/index.html
最後,如果本文有任何錯誤,請不吝提出,我會盡快做修正;而如果我的文章有幫助到你,可以看看我的其他文章,歡迎一起交流 :)
田少谷 Shao - Medium
類 Python 的合約語言 Vyper 開發入門:與 Solidity 差異、用 Truffle 部署、ERC20 賣幣合約實做 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...
blob 資料 型 態 在 Taipei Ethereum Meetup Facebook 的最佳貼文
📜 [專欄新文章] Crosslink 2019 Taiwan|以太坊 2.0 的未來藍圖及挑戰
✍️ Frank Lee
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
Danny Ryan(source: Crosslink 2019 Taiwan)
十月底於台北矽谷會議中心舉行的 Crosslink 2019 Taiwan,吸引了來自世界各地的區塊鏈愛好者們齊聚一堂。第一天的議程,邀請到了以太坊基金會 (Etherium Foundation, EF) 的核心研究員 Danny Ryan,會中分享了以太坊 2.0 (Ethereum 2.0)目前的研究方向以及遇到的挑戰,演講的內容主要包含了以太坊 2.0 的架構,新的分片提案,執行環境 (Execution Environments, EE)以及雙向橋接 (Two-Way Bridge)等議題。
一、以太坊 2.0 的架構
以太坊 2.0 架構(source: Crosslink 2019 Taiwan)
第零階段(Phase 0)
在 以太坊 1.0 (Ethereum 1.0) 中,使用 工作證明(Proof of Work, PoW) 作為 共識機制 (Consensus),並藉此產生新的區塊。為了要減少工作證明產生新區塊時,所需要的大量算力,以及所花時間過長的問題,以太坊 2.0 將改為 權益證明 (Proof of Stake, PoS) 作為產生新區塊的共識機制,以太坊 2.0 PoS 創世區塊 (Genesis Block) 預計會在 2020 年 1 月 3 日產生。
第零階段會建立信標鏈(Beacon Chain),信標鏈就是以太坊 2.0 系統層級的鏈,當從以太坊 1.0 移轉到以太坊 2.0 時,信標鏈扮演著非常重要的角色,它是整個系統的基礎。
一旦第零階段完成,將會有兩個使用中的以太坊鏈。以太坊 1.0 鏈(目前所使用的 PoW 主鏈)以及以太坊 2.0 鏈(新的信標鏈)。在這個階段,使用者在 1.0 鏈把以太幣鎖到合約裡以註冊公鑰, 2.0 鏈會承認合約內註冊的公鑰。但是,他們無法將該以太幣遷移回去以太坊 1.0 鏈上面,為了要執行信標鏈,你會需要一個信標鏈的客戶端。目前,許多團隊正在開發這些客戶端。
第一階段(Phase 1)
第一階段會加入分片鏈(Shard Chains),在這個階段主要專注於分片鏈的資料結構,以及其有效性(Validity)和共識性(Consensus),分片鏈在這階段只當作資料鏈,並不會指定分片鏈狀態執行(State Execution) 或帳戶餘額(Account Balances)。這比較像是對分片結構進行測試,而不是嘗試利用分片來對信標鏈進行擴展。在這階段,信標鏈會把分片鏈的區塊(Block), 當作沒有結構或意義的位元集合(Collections Of Bits)。以太坊 1.0 和以太坊 2.0 仍將同時存在,並且在以太坊 2.0 鏈上進行測試和遷移。
這個階段分片鏈會與信標鏈交聯(Crosslinks) ,每個分片的當前狀態 — “結合資料根(Combined Data Root)”,會定期記錄在“信標鏈”區塊中,作為交聯。信標鏈區塊完成後,相應的分片區塊(Shard Block)將被視為已完成,其他分片知道它們可以依靠這些區塊進行跨分片交易。
交聯是委員會(Committee)的一組簽名(Signatures),證明了分片鏈中的某個區塊,可以包含在信標鏈中。交聯是信標鏈”理解”分片鏈更新狀態的主要方式。交聯還用作異步跨分片通信的基礎結構。
信標鏈在每個時段(Slot)中的每個分片,隨機選擇分片驗證者(Shard Validators) ,分片驗證者只是用來在每個區塊的內容上達成一致,他們通過交聯證明分片的內容和狀態,分片中包含什麼內容都沒有關係,只要所有委員會都達成共識,並定期更新分片上的信標鏈即可。
第二階段(Phase 2)
第二階段會將所有功能開始結合在一起,在第二階段,會完成分片化,分片鏈從簡單的數據容器過渡到結構化鏈狀態,並將重新引入智能合約。每個分片將管理基於 eWASM(Ethereum flavored WebAssembly) 的虛擬機。它會支援帳戶(Accounts)、合約(Contracts)、狀態(State),以及 Solidity 中我們熟悉的其他抽象化,預計在第二階段之前或第二階段開發時,大家熟悉的工具(例如 Truffle, Solc, Ganache)需要轉換成支持 eWASM 的版本,以太坊 1.0 及以太坊 2.0 可藉由雙向橋接來互通,會有可擴展的 Layer 1 執行,藉由無狀態執行,來提高執行速度。
二、新的分片提案
新的分片提案(source: Crosslink 2019 Taiwan)
以太坊 2.0 原提案所運作的機制,是以每個時期 (Epoch) 為單位,來進行交聯的動作,每個鏈上有1024 個片 (Shards),當需要跨分鏈交易(Tx)時,由於是每個時期進行交聯,會有較大的延遲時間;新提案更新為每個時段都進行交聯的動作,並減少片(Shards)的數量為 64個,來降低跨分片(Cross-Shard)交易時的延遲時間,每個時段都進行跨分片交易。
新提案的優點
對於以太坊 2.0 新提案的優點,首先新提案的片 (Shards)數量由 1024 個降至 64 個,降低了運算的複雜度,因為跨鏈時間從一個 epoch 降到一個 slot ,時間縮短第一個好處是給 DApp 開發者及使用者更好的體驗。第二個好處是以往需要手續費市場(Complex Fee Market) 及樂觀狀態(Optimistic State)這兩種複雜的跨鏈交易解決方案,現在不需要了。
新提案的交易
新提案只需要比之前的提案更少的片 (Shards),就可以啟動交易,可能會有更長的分片時段(12s),更大的分片區塊(Shard Block),目前更新到第零階段 ,第零階段測試網(Testnets)的測試,可能會有所延遲 ,新提案減少了第零階段發布所需的時間。
目前的想法
希望能給開發者及使用者更好的體驗,使用較大的分片區塊(Shard Block),來改進資料可用性,以及要降低開發延遲和第零階段發布所需花費的時間。
三、執行環境
以太坊 1.0 簡易架構圖(source: Crosslink 2019 Taiwan)
在之前設計的以太坊 2.0 和以太坊 1.0 中,狀態在共識機制裡,扮演著非常重要的角色,共識機制會隨時去讀寫所有的狀態,不管是執行的概念、交易的概念、帳戶的概念、樹狀結構的概念、以及所有在資料結構中的概念,都深深地融入共識中。
上圖是以太坊 1.0 的簡易架構圖,在圖中我們可以看到共識機制及一條鏈,共識機制裡包含了狀態及一個執行引擎,狀態裡包含了狀態樹,在這裡的執行引擎使用硬編碼規則,裡面包含了執行交易、帳戶模型和帳戶結構,我們可以看到圖的右邊有一條鏈,鏈上面有交易資料,在以太坊 1.0 中,我們會在交易資料上執行共識機制,去修改和更新狀態。
執行環境是一個單獨的虛擬機器,在以太坊 1.0 中,會有一個特定的帳戶模型(Account Model),以及事先定義好的操作碼 (Opcodes),礦工機制 (Gas Mechanisms)和狀態根(State Root),以太坊虛擬機 (Ethereum Virtual Machine, EVM) 就是一種特定的執行環境。
如果遵循 EIP(Ethereum Improvement Proposals) 的建議,開發者總是在要求新的操作碼,或著是更改礦工成本(Gas Cost)來支援他們的應用,像是 Plasma 和 Zkrollup 這樣的例子有很多,這樣就會需要修改 EVM 1.0 的執行環境 ,才能支援到他們的應用程式(DApp)。
但是在以太坊 2.0 的第二階段中,我們可以支持多個執行環境。 也可以有多個狀態根,不同的帳戶模型等。舉個例子,你可以定義一個臉書幣執行環境 (Libra EE),以便在以太坊 2.0 上運行 Libra。 或者,您可以定義一個比特幣執行環境 (BitCoin EE),這樣就可以在以太坊 2.0 上運行比特幣。
以太坊 2.0 簡易架構圖(source: Crosslink 2019 Taiwan)
在以太坊 2.0 簡易架構圖中我們可以看到狀態根, 它可能是 32 Bytes 的 Blob,上面有 WASM 的執行碼 (Execution Code),可以在使用者層級中去做細部設定。圖片右邊有一個鏈,鏈上有一般的交易資料以及見證(Witnesses),見證實際上顯示在資料庫的區塊中,你需要針對該狀態而不是資料庫執行該筆交易,而且還需要證明資料對於當前狀態根是有效的。舉個例子,如果我們要在帳戶 A 和帳戶 B 之間傳遞數值,假設從帳戶 A 移動 5 以太幣 到帳戶 B ,我們不能直接說帳戶和餘額 (Balance) 是確實可用的,在過程中,我們需要加入見證資料(Witness Data),來證明兩個帳戶當前的狀態,當執行碼正在執行交易資料時, 狀態根可以修改和更新狀態樹。
執行環境並不是共識機制預先定義好的,他可以在使用者層級上去做新增,我們也可以把以太坊 1.0 複製一份到以太坊 2.0 的執行環境中,將現有的狀態根放入EVM 直譯器,用梅克爾見證驗證器(Merkle Witness Verifier)來當作他的執行碼。
在原先的提案中,狀態和共識息息相關,且執行帳戶和共識中包含了狀態樹結構;而在新的提案中,執行環境為無狀態模型(Stateless Model),高度抽象化的,並且它的可擴展性,相較原先的提案高出非常多。
執行環境的優點
執行環境有許多優點,相較於舊系統,它也許可以更快地將產品推向市場,因為我們不必等到核心共識推出之後,才研究並發展這個概念,在 Layer 1 會有更少的阻礙,它可以在各種應用上,使用具高擴展性及資料可用性的執行引擎,所以未來會長期使用這個核心基礎層。
執行環境的設計完成,讓以太坊 1.0 到以太坊 2.0 的遷移,有了更清楚的方向,使用執行環境比較不會有技術隨時間遷移而過時的問題產生。
執行環境交易
對於執行環境交易,開發者及使用者可能會覺得太抽象,對什麼是執行環境感到困惑,像是這一層加了什麼?應該在這一層做什麼?誰應該寫執行環境?而且相關的開發規範會趨向更嚴格的形式。
虛擬機可能會有潛在的碎片化問題,進而影響到交易速度。
目前的想法
目前所有的研究都是正向發展的,還有充裕的時間,嘗試並更好地了解設計空間,未來會多花一些時間,在建立更好的執行環境通訊機制上面。整體來說,現階段的進度,對於未來是重要的里程碑。
四、雙向橋接
最後一個主題,主要討論開發雙向橋接是否是值得的?團隊可能可以在什麼時間點,來去做雙向橋接?
單向橋接示意圖(source: Crosslink 2019 Taiwan)
講者先前提過的提案中,以太坊 2.0 最初有一個單向橋接,所以你可以從以太坊 1.0 轉換到 以太坊 2.0,但是最初的架構不允許回傳,這主要是出於幾個原因,這需要我們將以太坊 1.0 的發展 與 以太坊 1.0 和以太坊 2.0 的硬分叉緊密結合,並把兩個系統置於互相影響的風險之中,因此團隊認為以太坊 2.0 在發布且穩定之前,將兩邊緊密耦合是不明智的。
單向橋接的問題
月初在日本大阪舉行的 Devcon 5 上,橋接的問題受到了廣泛的討論,原提案的單向橋接(One-Way Bridge)模式,會有驗證者流動性的問題,而且更重要的是,它可能會引發以太坊 1.0 和以太坊 2.0 之間的可替代性問題,如果我們允許以太坊 2.0上的流動性,那麼某種形式的轉移機制,就會在將以太坊 1.0 分叉到以太坊 2.0 之前,或著是在雙向橋接之前產生,交易所中很可能會同時有兩個幣,團隊和整個驗證者社區都很擔心這個問題,目前正在找尋減輕這個問題的方法。
另外也希望鼓勵大家,在這些早期階段進行驗證,但是在早期階段進行驗證,肯定會有很高的風險,因為存在未知的鎖定期,因此也希望找到方法減輕這種風險。
雙向橋接
雙向橋接示意圖(source: Crosslink 2019 Taiwan)
雙向橋接目前可能的路線有兩條,一種是在以太坊 1.0 上面,建立以太坊 2.0 的輕節點;另一種是在以太坊 1.0 上運作以太坊 2.0 的全節點。
路線A: 在以太坊 1.0 上,建立以太坊 2.0 輕節點
路徑A示意圖(source: Crosslink 2019 Taiwan)
這個路線需要在實際的 EVM 中支援 BLS-12–381,會花費很多開發時間,而且它只提供輕量客戶端 (Light-Client) 層級的安全性。當驗證者在 2.0 鏈上產生提款交易的收據時,我們會拿到以太坊 2.0 的輕量客戶端證明,一但收收據的區塊在以太坊 2.0 上敲定了,你就可以在以太坊 1.0 的合約上提款。不過,這可能不是團隊最終選擇的路線。
路線B:在以太坊 1.0 上,運行以太坊 2.0 的全節點
路徑B示意圖(source: Crosslink 2019 Taiwan)
第二種路線,會在以太坊 1.0 的節點上,運行以太坊 2.0 的全節點,這個路線允許我們使用敲定性機制,因此,我們不僅可以使用這種機制,來促進以太坊 1.0 和以太坊 2.0 之間的轉移,我們也可以利用驗證者的安全性,來保護以太坊 1.0 鏈,我認為大家對此感到非常興奮,這通常被稱為“敲定性小工具提案(Finality Gadget Proposal)”。
但是還是需要一種機制,去輸出以太坊 2.0 狀態根在以太坊 1.0 上,所以有一些以太坊 2.0 社群的討論,在研究如何實作它,可能會包含礦工機制。
輸出以太坊 2.0 狀態根的另一個優勢,是以太坊 1.0 有穩固的機制可以實現它,以及同時擁有以太坊 2.0 的高擴展性及資料可用性,可以做一些有趣的應用,像是 ZK Rollup 和 Optimistic Rollup。
雙向橋接的優點
如果你在交易所中,列出以太坊 1.0 以太幣和以太坊 2.0 以太幣,它們的價格應該一樣。 如果不一樣,你可以用較低的價格買一個以太幣,把他發送到橋上,然後以較高的價格獲得另一種以太幣,並把它出售。 這種套利會使它們的價格保持不變,這樣會讓用戶,驗證者和開發人員感到困惑,雙向橋接可以防止兩邊的貨幣藉由套利的形式,來互相轉換。
雙向橋接的交易
但是還是有一些權衡在這裏,儘管對以太坊 2.0 的設計非常有信心,團隊還是希望在影響到以太坊 1.0 的安全性和風險狀況之前,先在生產環境中得到驗證。
雙向橋接是一種緊密耦合的共識機制,對於兩邊鏈的攻擊及產生的問題,都會影響到另一邊的鏈,協定的開發勢必會非常煩瑣,我們需要考慮到每個協定的安全性,如果我們越早開發協議,那麼我們實際上的進度就越少,當每個障礙隨著時間發展,它們就會相互阻礙,這讓以太坊 1.0 在這一點上的開發速度比以太坊 2.0 慢得多,因為實際用戶群存在很多擔憂,並且需要大量的協調,才能在我們的生產網絡上獲得硬分叉。
所以,如果我們越早將這些東西連在一起,就可能會減慢以太坊 2.0 的開發和分叉週期,並且這增加了一些額外的開銷,換句話說,驗證我們可以鏈接客戶端的開銷是相對的。
目前的想法
我們應該會在加入驗證人流動性之前啟用橋樑,但是會等到第一階段的產品穩定之後再開放;同樣的,有很多相關的研究都在同時進行,這可能會影響到,何時完成這個操作。
名詞解釋:
EIP(Ethereum Improvement Proposals):EIP 是以太坊平台的標準,其內容包含了核心協議的規範,客戶端 API 以及合約標準。
epoch :在以太坊 2.0 中,epoch 指的是時長 6.4 分鐘的時間單位,每個epoch 包含64個 slots。
Slot(時段):每個時段為 6 秒,不一定每個時段都能產生區塊,而epoch 中最後一個 slot 稱為邊界時段 (Boundary Slot) ,或稱為檢查點 (Checkpoint)。
Solidity:Solidity 是一種合約導向的語言,主要用來開發智慧合約。
Consensus (共識機制):共識機制是區塊鏈為了在各節點間達成共識,所開發的演算法。
Validator 驗證者:驗證區塊的節點,由信標鏈在每個時段(Slot)為每個 片 (Shards)隨機產生。
Gas:交易所需的費用,當 Gas 消耗完時,智慧合約會終止並進行 Rollback。
EVM(Ethereum Virtual Machine):EVM 中文為以太坊虛擬機,是一種輕量級的虛擬機環境,Eth 1.0 中智能合約的運行環境為 EVM。
Dapp(Decentralized App):在以太坊中,基於智能合約的應用都稱為去中心化的應用程序,即 Dapp(Decentralized App)。
ether(以太幣):以太坊的貨幣名稱。
Finality(敲定性):「敲定性」是 Casper 中的概念,是一種透過驗證者投票,在鏈上產生不可回朔(Rollback)的檢查點的機制。
Libra:臉書提出的加密貨幣,預計於 2020 年發行。
Merkle Tree:Merkle Tree 由計算機科學家 Ralph Merkle 所提出,中譯為雜湊樹,因為是由雜湊函式形成的樹。
Reference: [Ethereum Improvement Proposals](https://eips.ethereum.org/)
Reference: [Two-way bridges between eth1 and eth2](https://ethresear.ch/t/two-way-bridges-between-eth1-and-eth2/6286)
Reference: [Ethereum 2.0 (Serenity) Phases](https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/#phase-2-state-execution)
Reference: [ethfans](http://ethfans.org/)
Reference: [eth2 quick update](https://blog.ethereum.org/2019/10/23/eth2-quick-update/)
Thanks to Danny Ryan, Chih Cheng Liang, Juin Chiu, Yahsin Huang, and Jerry Ho
Crosslink 2019 Taiwan|以太坊 2.0 的未來藍圖及挑戰 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌
blob 資料 型 態 在 Taipei Ethereum Meetup Facebook 的精選貼文
📜 [專欄新文章] 參加 Crosslink 2019 Taiwan 一探究竟那些不可錯過的以太坊最新發展 (第二天議程)
✍️ Phini Yang
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
解析以太坊上的安全狀態通道 (A Secure State Channels Framework for Ethereum)— Liam Horne, Co-founder of L4 Ventures & ETHGlobal
#Intermediate
擴展性 Scalability 一直是近年以太坊生態系中重點任務。第二層協定 Layer 2採取的解決方向是用已有容量來處理更多交易,並不是增加以太坊本身容量,而是應用程式流量優化與用戶操作流程簡化等方式達到目的。它不會對基層協議做出任何更改,僅使用智能合約與鏈下應用程式交互。
「狀態通道 State Channel」則是第二層協議的其中之一解法,是一種透過鏈下交易與更新狀態的技術,在重複支付或遊戲加速兩項表現優異。在 L4 Ventures 中,開發人員可透過通用模塊化來快速建構狀態通道。此演講將帶你了解 State Channel 未來整體佈局。
延伸閱讀:Counterfactual: Generalized State Channels on Ethereum By Liam Horne Layer 2: From Payment to Generalized State Channel By 陳品
如何打造一般化的 Layer2 應用服務 (How to Build Generalized Application on Layers2)— Yuriko Nishijima, Developer & Researcher of Cryptoeconomics Lab
#Intermediate
「電漿網路 Plasma」是第二層協議的另一個解法,它創建附加在以太坊主鏈上的子鏈,並運用此技術實現狀態通道效果,特別在支付應用上見長。
Plasma 是 2017 年 Vitalik 跟 Joseph Poon (閃電網路提案人之一) 提出的方案,並於 2018 年有爆炸性成長。Cryptoeconomics Lab 在 Plasma 深耕已久,也正在實作這項協定,透過演講你會瞭解 Plasma 擴容方案將如何實現。
掌控你的私鑰與隱私 (Own Your Private Keys and Privacy) — Hankuan Yu, Head of Engineering & Hank Chiu of Engineering of HTC EXODUS
#Beginner
在區塊鏈世界中,私鑰就是一切。HTC Exodus 是全世界第一款使用硬體保護私鑰的區塊鏈手機,從使用者最根本問題出發。今年 9月 HTC 更提出新一代私鑰還原架構 — SKR 2.0,進一步提升私鑰還原之安全性。接下來,在私鑰安全及區塊鏈隱私上,HTC 將有什麼進一步規劃呢?
模組化的點對點網路協議 (libp2p: Modular Peer-to-Peer Networking Stack) — Raùl Kripalani, libp2p Tech Lead of Protocol Labs
#Intermediate #Eth2.0 #Go Language
在區塊鏈專案的網路層協議之中,近年來最值得關注的為 libp2p project,它是 IPFS 網路協議之延伸,現已另成一獨立網路協議專案,並由 Protocol Labs 團隊來維護。在去中心化場景中,為了解決節點與節點之間訪問的各種問題,libp2p 提供了解決方案,並將節點能在多個網絡中共享,大家亦能受惠於此。況且 libp2p 更提供可讓開發者快速使用的模組化通用包,廣受區塊鏈開發團隊青睞。
延伸閱讀:Why libp2p? By Pierre KriegerUnderstanding IPFS in Depth(5/6): What is Libp2p? By Vasa
剖析以太坊 2.0 客戶端 (The anatomy of a basic Ethereum 2.0 client) — Adrian Manning, Co-founder of Sigma Prime
#Intermediate #Eth2.0 #Rust Language
Lighthouse 是 Sigma Prime 針對 Eth2.0 客戶端所開發的專案,選用新一代語言 Rust 來做開發。Sigma Prime 於早期就參與 Casper 研究跟實作,對 Eth 2.0 核心的共識機制相當熟捻,而共同創辦人 Adrian 更是網路安全跟密碼學的專家。
講者介紹:Adrian Manning, Co-Founder of Sigma Prime▪ PhD in Quantum Field Theory▪ Cyber/Cryptography expert
延伸閱讀:Casper FFG:以實現權益證明為目標的共識協定 By Juin
次世代的以太坊虛擬機 (eWASM VM — The next generation Ethereum Virtual Machine )— Hung-Ying Tai, VP of engineering of Second State
#Intermediate #Eth2.0 #Virtual Machine
以太坊為了迎接下一代的虛擬機 — eWASM VM (Ethereum Flavored WebAssembly Virtual Machine),正如火如荼地開發 Solidity 的 eWASM 後端銜接。「eWASM 虛擬機」顧名思義將不再採用現在黃皮書中的指令集 ,而是使用 EWASM 來取代。EWASM 將會強化以太坊虛擬機的效能與安全性,也可以相容更多工具鏈,可以做到用一般程式語言如 C / C++、Go、Rust 來寫合約。
延伸閱讀:https://github.com/ewasm/design/blob/master/rationale.md
Geth 上的新型 BFT 共識演算法 (New A New 2-Step BFT Consensus Algorithm in geth)— Tung-Wei Kuo, Assistant Professor of National Chengchi University
#Advanced #Academic
傳統的拜占庭容錯 BFT (Byzantine Fault Tolerance) 共識演算法需要三個步驟來完成共識。在這場演講中,Tung Wei 將提出一個兩步驟 TwoStepBFT 的優化算法,在容許錯誤節點下,亦同時保有安全及活性。
使用以太坊 Proof-of-Authority 聯盟鏈進行跨醫院的資料共享 (Ethereum PoA Consortium Chain to Support Inter-Hospital Data Sharing) — Kung Chen, Professor of National Chengchi University
#Intermediate #Academic
目前社會中尚缺乏一套完善的整合系統,可供民眾進行醫療資訊的授權與共享。若病歷能有效地共享與授權,將可強化醫療分級轉診服務等下一代醫療服務。偏偏這些醫療資訊牽涉民眾隱私權等敏感議題,國立政治大學陳恭教授將分享如何透過區塊鏈對資料授權能力,來提升使用者的資料自主權,達成有效進行交換醫療資訊的目標。
更多資訊請直接參考官網議程:https://crosslink.taipei/schedule/2019-10–20
參加 Crosslink 2019 Taiwan 一探究竟那些不可錯過的以太坊最新發展 (第二天議程) was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌