📜 [專欄新文章] 類 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.
👏 歡迎轉載分享鼓掌
web3實作 在 Taipei Ethereum Meetup Facebook 的精選貼文
📜 [專欄新文章] 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.
👏 歡迎轉載分享鼓掌
web3實作 在 Taipei Ethereum Meetup Facebook 的精選貼文
📜 [專欄新文章] Ethereum Identity — ERC725/735
✍️ Kimi Wu
📥 歡迎投稿: https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium
Ethereum Identity — ERC725/735
前幾天,因緣際會地得知 ERC725,是一個跟 identity 有關的 EIP,提案人是Fabian Vogelsteller,ERC20 跟 Web3.js 的創始人(大神等級 XD),這篇就來介紹一下 ERC725 還有附屬的 ERC735!(本篇主要是介紹 ERC725,讓在做identity 相關的開發者可以有多一點的資訊,所以不會提到太多介面或實作上的細節)
ERC725 於 2017 年 10 月提出,目的是為了要建立區塊鏈上的數位身份。簡單來說,有兩個主要功能 Key Management 跟 Identity Usage(Identity Verification 稍後再提)。
Key Management
目前的定義有:MANAGEMENT, ACTION, CLAIM, ENCRYPTION
可以想作是每個身份的權限管理,不同的 key 能做不同的事。例如擁有MANAGEMENT 就代表你可以管理這個身份,是這個身份的擁有者,你要加key 或是移除 key 也都需要這個權限。ACTION 的 key 代表能夠執行某些動作。ERC725-Key-Management 有每個 key 的介紹。
Identity Usage
ERC725 在設計上是 proxy contract,也就是可以經由這個 identity contract 去執行其他 contract 的 function,透過 execute 這個 function 去執行。例如transfer ether。
除了執行的部分,Identity Usage 還有 approve 的功能,簡單來說,就是支援multisig 的功能,需要多人簽章,要執行的 function 才會執行。
ERC735 / Identity Verification
Identity 在實際場景中會有一個問題,就是身份怎麼「認證」,而作者把認證這塊獨立提了另一個EIP,也就是ERC735。
ERC735 的內容也相當簡單,就是增加跟移除認證(Claim)而已。在提案中沒有限制 Claim issuer(也就是發認證者)的身份,可以是 smart contract 或是外部的帳號都可以。
特別提一下,設計中有個 topic 的欄位,可以讓認證方去指定這個認證是屬於哪個類別的,可以讓認證的內容更加彈性,例如是生物辨識的資料,或是住家地址,不過這部分的細節尚未決定。
ERC725 DEMO有 web UI 可以讓大家更瞭解 ERC725 實際運作的樣子。
再回過頭來看 Key Management 在權責劃分的部分,Identity Usage 中的執行,會需要 ACTION 權限的 key,而 Identity Verification 則需要 CLAIM 的權限。也就是這個 identity contract 是可以由多人共管,有權責劃分,所以這不只是個人的 identity 是可以延展團體或是組織的 identity contract。
概念上 ERC725/735 還滿簡潔的,看完我的介紹應該像是跟沒看一樣 XD,有在做相關主題的,大概都想得到這些內容,identity 做得可大可小,我覺得厲害的是,作者可以把所有的需求最小化,卻又符合大部分的需求,然後提出一個這麼精簡的 EIP,跟 ERC20 一樣(對!我就是有大神崇拜症 XDD)。
ERC725 有成立一個 ERC725 Alliance,有興趣的可以上去看看跟瞭解。
Originally published at kimiwublog.blogspot.com.
Ethereum Identity — ERC725/735 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.
👏 歡迎轉載分享鼓掌