Kimi的筆記

ZK Rollup不是一個新的提案，大約在一年前被 Barry Whitehat 所提出，同時間Vitalik在以太坊研究員的論壇有一篇比較 完整的文章 解釋，現在由 Matter Lab 在開發。研究完zk-SNARKs之後，一直沒空來看，直到最近才有機會來深入瞭解。除了ZK Rollup，也會簡單帶一下前陣子在 Plasma Group 所提出的 Optimistic Rollup 。 ZK Rollup一開始提出來的時候，是被定義為layer 2的解決方案，年初的時候一度以Plasma Ignis這個名稱作為發表。應該是因為去年Plasma很紅，一直不斷有新的提案跟進展，加上這當時也被定義為layer 2的解決方案，這些種種原因，開發者就冠上了Plasma的名稱，不過因為這項技術跟Plasma的精神完全不一樣，被社群抗議，後來就恢復到Rollup這個名稱（ 開發者的聲明 ），所以搜尋 'Plasma Ignis'會找不到什麼東西。到最近，Rollup被更名為semi-layer 2的解決方案，就是有一點layer 2但又沒這麼layer 2... XD 簡單一句話解釋ZK Rollup就是， 資料放在鏈上的layer 2解決方案 。在瞭解ZK Rollup之前，先來解釋原本layer 2有什麼問題。以Plasma為例，Plasma鏈只把Plasma區塊的hash放上Ethereum主鏈上做公正（欲瞭解Plasma可以參考 這裡 ），也就是在鏈下交易了數百或數千筆的交易，最後上鏈只有幾十個bytes，這是鏈下交易的精神，但也是設計上最麻煩的地方 - 資料的可取得性 。 就是當有人要離開這個鏈時，需要一個額外的遊戲規則，在Plasma叫做挑戰期（因為鏈上沒有資料，需要側鏈參與者的提供證據），這衍生了有資料才能挑戰，所以大家都要存一定數量的資料，相較於跟主鏈的互動，只需要裝一個錢包，並不需要下載區塊資料，使用者體驗上差異很大。挑戰期的另一個問題是，使用者需要保持上線狀態，不然錯過挑戰期，就代表默認了交易（因為是採用詐欺證明並非是有效性證明）。簡單來說，因為資料的可取得性問題，衍生了  1.使用者需要常在線上  2. 需下載部分資料 而造成使用者體驗很糟（當然現在的Plasma設計已經改進了不少） ...

本來是要展開一個叫做「與大神(C.C. Liang)共筆系列」，無奈C.C.太忙，最終還是只能自幹，不過依舊感謝 C.C. Liang 提供素材跟觀念釐清 data availability（資料可取得性） 跟 fraud proof （詐欺證明）對於區塊鏈交易量擴展，是很重要的兩項因素。當交易量大意味著資料量就變大（無論是分片或是加大區塊大小），而資料量越大，能夠運行全節點的人就會越少（因為硬體跟維護成本越高）。舉例來說，Ethereum 2.0 有1024 條鏈，不可能每個人都把1024條的資料都下載下來，更何況，這樣也失去分片的意義，但若某節點做分片A的validator，此時，需要跟分片B有所互動，不太可能把分片B的所有區塊都下載下來，太耗時也太佔空間，而且若如此設計，最終也會把全部的鏈都下載下來....。但是，若沒有全部的區塊那要怎麼驗證交易呢？！這就是「資料可取得性」的重要性。 資料可取得性簡單來說就是拿不拿得到資料，但不代表拿到的資料的有效的/正確的。那在討論資料可取得性問題之前，先來認識詐欺證明。 在區塊鏈世界中，驗證資料方式可以分為有效證明(validity proof) 跟詐欺證明兩種。有效證明就是現在區塊鏈的運作方式-「驗證資料是正確的，才能上鏈」，也就是當你需要轉帳時，礦工需要先驗證你的餘額是否足夠，確認你餘額是夠的（驗證資料是正確的）才會打包。而詐欺證明則是相反，驗證者收到交易之後，經過一段時間若沒有人提出異議/挑戰，那就代表你送出的交易是沒問題的，這種方式驗證成本相對較低，也因此大部分L2方案選擇使用詐欺證明作為資料驗證的方式。 而輕節點只下載部分的資料（通常是block header），要如何能在運作上幾乎跟全節點一樣可靠呢（'幾乎' 是因為輕節點需要額外的一些假設）？就必須借助資料可取得性跟詐欺證明的的合作。 Fishermen 漁夫（fishermen）機制是一種很直覺的設計方式，就是漁夫們觀察著網路上的無效資料，發現後送出詐欺證明以得到獎勵。 基本的獎懲機制如下， 1. 若有人提出無效的詐欺證明，則沒收押金， 2. 若有人提出有效的詐欺證明，送出無效資料的人會被沒收押金，而押金部份當作挑戰者（提出詐欺證明的人）的獎勵。 但是，這種機制在這個情境會有問題。我們來...

smart contract跟一般程式最大的差異，就是smart contract上了鏈就不能改了（這是區塊鏈的特性也是優點，但是如果真的有bug，麻煩就大了...）。所以今天要介紹的是，如何用 ZeppelinOS 來實作upgradeable smart contract，可升級的smart contract。 版本  - zos: 2.1.0  - Truffle: 5.0.1 OpenZeppelin 對smart contract的開發者一定不陌生，提供相當多smart contract的範例程式。Zeppelin部落格有介紹如何使用proxy contract實作可升級的contract，這是他們 proxy patterns的設計 ，之後有機會再深入介紹proxy pattern。本篇主要在介紹如何使用 zos 部署可升級的contract。（本篇需要有使用過truffle的經驗） Deploy contracts 環境部分，先安裝Node.js跟npm，跟Ganache（或Ganache-cli）。 Deploy your first project 有詳細地介紹如何使用zos部署。 先安裝ZeppelinOS npm install --global zos 再來建立專案 mkdir MyProject cd MyProject 初始化專案 npm init zos init MyProject npm install zos-lib 這個時候，資料夾內容就跟下過 truffle init 一樣，有 contracts , migrations 資料夾， truffle-config.js 等。以上環境就都建置完成了，再來就是寫contract了，這裡直接用官方的範例 pragma solidity ^ 0.4 .24; import "zos-lib/contracts/Initializable.sol" ; contract MyContract is Initializable { uint256 public x; string public s; function initialize(uint256...

RNG 是 Random Number Generator ，也就是亂數產生器 在現實世界中要產生真正的隨機數，其實不容易，各個語言的library所提供的隨機數，都是偽隨機數，是可以預測的，不過在大部分的應用場域，都是可以應付的。區塊鏈的世界，面對的是全世界的人，怎麼產生不可預測的隨機數，就很重要，不然就可以被有心人所操作。例如Ethereum Beacon chain(POS chain)中的validator/attester(產塊跟驗證的角色)，若是可以被預測，那大概就沒有人會相信這條鏈了。而這也是Ethereum Serenity(Eth-2.0)，所遇到的問題之一。目前隨機數的產生，就由RANDOA + VDF所產生，以下就分別介紹 ＲＡＮＤＡＯ RANDAO是利用經濟模式（獎勵跟處罰）的方式，促使在公共場域中能產生隨機變數 原理很簡單，想參加的人把拿錢來抵押，需要產生隨機數的人要付錢。所以參加者就可以從中分潤，當然不守規矩抵押的錢也就會被沒收，利用獎勵跟處罰的方式迫使大家都守規矩。詳細步驟如下： 首先，會有個收集seed的時間，例如6個block的時間。接著，想參與的人，投入某個數量的ETH到RANDAO這個smart contract（作質押），然後附上secret（某個只有你知道的值s，然後作sha3）。 等收集時間結束，就是驗證時間。此階段所有參與著需要把s傳入smart contract做驗證，smart contract會把s作sha3，去驗證是不是跟第一階段傳進來的一致。最終會把驗證過的s當作seed去產生隨機數。 最後，就是產生隨機數，然後把隨機數傳給之前有請求過的contract。然後歸還質押的ETH跟利潤分給參與者。 此外有幾個附加條件 第一階段若收集到數筆一樣的secret，只接受第一筆 第一階段會規定基本人數，若結束後未到達人數門檻，則此次的產生就失敗 若第二階段需提供s 若未提供，則質押的ETH會被沒收 若此階段有一個以上參與著未提供s，則此次產生失敗，並且把沒收的ETH分給有提供s的參與者。且退還請求者所支付的ETH。 ＶＤＦ VDF  全名為 Verifiable delay functions ，從字面上有點難懂在幹嘛，從運...

Ethereum 2.0 已經正式改名為Ethereum Serenity 原本預計在今年(2018)上線的Hybrid POS(Casper FFG)跟sharding，因為遇到一些技術上的困難，所以把Hybrid POS改成單純POS，然後因為sharding跟POS有部份技術是重疊的，所以把POS跟sharding併在一起做（本來是分成兩個team作開發） Beacon Chain 在Ethereum Serenity的規劃中，在原本的POW chain之外多一個鏈叫做 Beacon chain ，是一個POS chain。在Beacon chain中有兩種角色 proposer 跟 attester ，proposer就是產塊的人，attester是驗證的人。而在POW chain上存入32 ETH，可以成為Beacon chain上的 validator ，而validator有權利產塊(proposer)，也會有機會被選attester。此外，延續了Casper FFG finality這個概念，也就是在finality之後的狀態就是正確的狀態（不可回復），不像POW一般需要6個塊的時間才能確認交易是不會被更改的（POW的狀態確認是機率，六個塊之後有"很高的機率"是無法被改變的，而finality就像是0跟1一樣，沒有中間）。 聽到這，好像覺得很簡單，但是在實作上會遇到幾個問題，首先，怎麼決定誰是proposer誰是attester，如果亂數的隨機性不夠，就很容易被遭到操控。接下來是，每次驗證都需要做一次簽名，因為32個ETH就可以當validator/attester，每次驗證可能會有10~20幾萬的簽章（ 簽章數量的預估方法 ），驗完簽章天都黑了 ＸＤ。 ＲＮＧ 針對亂數產生（ RNG , Random Number Generator），使用 RANDAO 跟 VDF ，RANDAO是個利用經濟獎勵的機制來產生亂數，原始的設計是在smart contract上，而在Beacin chain會直接實作這個邏輯。而VDF是一個delay function，因為速度的關係，基金會打算自己開發ASIC晶片。關於這RNG之後會再寫一篇 詳細解釋 。 Signature Aggregatio...

" We finally hit the peak of the mountain！ "  這是Ethereum Foundation researcher, Karl在Devcon 4 所說的。用這句話作為開場，代表著Plasma Prime離最終目標已經不遠了。 Plasma Prime是什麼呢?其實在 Ethereum Research 上找不到這個主題，Plasma Prime是Plasma Cash延伸的提案。Plasma Cash有一個很大的問題就是交易的歷史紀錄過於龐大（每個coin每年大約有1-3GB的歷史紀錄），如果沒有這些歷史紀錄，就沒辦法驗證作challenge 的動作。而Plasma Prime就是利用質數跟因式分解的特性，解決歷史紀錄過於龐大的問題。 Plasma Prime利用RSA accumulator來取代原本的驗證需要整個Merkle tree branch的方式。這邊用的概念很簡單，直接看範例不看數學式，假設有3, 5, 11這三個質數，可以得到 $A = g^{3*5*11}$ ，若要證明3是$Ａ$的一部分（比較精確的說法應該是$g^3$是$Ａ$的一部分），只要可以在 ${(g^3)}^x$ 中求得整數$x$，就代表3是$Ａ$的一部分，以這個例子來說，可以得到整數 $x=55$ ，因此3是$Ａ$的一部分。但是實際應用上$x$可能會很大（因為coin數很多），所以會需要更有效率的確認方式，這部分牽涉到的數學比較多，就不在這裡討論，有興趣可以參考 Wesolowski的論文 跟 Benedikt  Bünz 的演講 。 回過頭來解釋這個範例，$g$是generator（代表了初始的accumulator），$Ａ$是accumulator，然後每產出一個block，accumulator就會累加上一個block的accumulator，也就是一開始accumulator $A = g^v$ ，下一個block就accumulator $A` = A^y$ ，以此類推，一直累加上去。所以每個block就不需要帶著整個交易的Merkle tree，只需要多一個accumulator就可證明是否有交易過。 接下來，證明沒有交易過，代表要證明某數 $v$ 不是$Ａ$的一部分，很直覺會...

看完上篇 Plasma MVP跟Plasma Cash的介紹 ，感覺Plasma MVP目前還處於是概念上的階段，正式上線好像還有段距離。Plasma Cash每個coin都是不可分割的，在實際上的使用上有點困難。而本篇是要接續介紹Ethereum researcher 們更新的提案- Plasma Debit 跟 More Viable Plasma 。 Plasma Debit Plasma Debit要解決的就是Plasma Cash 每筆進帳不可分割的問題。Plasma Cash的帳戶裡只有一個值（而且值等於1），在Plasma Debit改成兩個值a跟v，    v  代表這個帳戶最多可以擁有多少錢（也就是存了多少ETH進Plasma chain）    a  是目前帳戶裡的錢 舉例來說， 1. 甲存了5 ETH進入Plasma chain後，v=5, a=5 2. 甲轉2 Plasma token給乙，v=5, a= 3 可以想作是信用卡的 最高額度(v) 跟還 可以使用的額度(a) 。 但是，這裡有個問題，在最一開始大家的a跟v的值都一樣，代表著大家不能相互轉帳。什麼意思呢? 舉例來解釋一下   1. 甲,乙各存了5ETH, 7ETH進Plasma chain，此時甲：(v=5, a=5), 乙：(v=7, a=7)   2. 甲想轉帳給乙，但因為乙的v=a，若甲轉給乙則會造成乙的 a>v 的狀況，這在設計上是不允許的（信用卡公司給你5萬的額度，總不能刷超過5萬吧） 為了要有流動性，operator可以透過不同的function存錢進你的帳戶（也就是某個coin），也就意味著你的v值會變被增加（當然會需要付一些手續費給operator），以上例來說   3. operator提供2ETH的額度給乙（v=9, a=7）   4. 甲就可以轉2ETH給乙（甲：(v=5, a=3), 乙：(v=9, a=9)） 目前Plasma Debit的設計類似payment channel，每個 coin的擁有者 跟 operator 建立一個雙向的payment channel（提案中多處都在類比Lightning Net...

前幾天，因緣際會地得知ERC725，是一個跟identity有關的EIP，提案人是Fabian Vogelsteller，ERC20跟web3js的創始人（大神等級  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的欄位，可以讓認證方去指定這個認證是屬於哪個類別的，可以讓認證的內容更加彈性，例如是生物辨識的資料，或是住家地址，不...