Kimi的筆記

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 ，從字面上有點難懂在幹嘛，從運...

在做區塊鏈應用的時候，最常碰到的一個問題就是，怎麼保管私鑰，怎麼讓使用者方便，但又同時是安全的。第一個想法就是備份金鑰（不論是passphrase/keystore/私鑰），但是如果把使用者金鑰(加密)備份到自己的server，只要server的安全上有個不小心，使用者的金鑰就可能就被盜取了，就算是加密過的，也難保不會被破解。那如果切成好幾部分，有好幾份備份呢? 那怎麼切，才能確保安全呢？這就是本篇的重點啦！ 最直覺的想法就是直接切成Ｎ等份，例如32bytes的私鑰分成四份，然後任三份可以組成完整的私鑰，這樣每份至少需要11 bytes。聽起來問題好像解決了，但要怎麼切分，可以保證4取3可以完整組回私鑰，又是另一個麻煩的問題（自己寫的演算法，如果沒有被完整測試過，屆時使用者的私鑰組不回來，公司的問題就大了）。 ZeroPass 有作切分金鑰並且提供備份的服務，不過找不到他們背後的演算法，後來google到 Shamir's Secret Sharing ，覺得很酷，在概念上用很簡單的數學就解決了這個問題，所以在這裡跟大家分享。 我是參考 這篇 ，淺顯易懂，不介意看英文的可以直接看。 如何拆分 先定義一下要我們接下來要幹嘛 1. 把秘密（ secret ）拆分成Ｎ份，並且只需Ｍ（M < N）份即可組回完整的秘密， 被拆分過的每一份秘密叫做 share 2. 建立一個(M-1)次方程式 假設，我們要傳遞的秘密是數字 3 ，然後希望3份（M=3）就能回復完整的秘密，所以要建立一個一元 二次（Ｍ-1） 方程式， y=ax 2 +bx+c 。 a跟b可以任選，而 c是秘密 （在我們的例子就是 3 ），我們選a=2, b=1，所以方程式為 y=2x 2 +x+3 。 方程式圖如下： 接著，我們任意取三點（因為M=3） ， （1, 6）, （2, 13）, （-2, 9） 而這三個點座標就是三個 share。 最終可以由這三個點座標( share )還原秘密( secret )。 如何還原 目標是，還原(M-1)次方程式。 若取得原本的方程式，即可拿到原本的秘密。我們知道兩點可以成一直線，而三點可以定義一個拋物線。現在，我們有三個點 （1, 6）, （2, 13）, ...

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的欄位，可以讓認證方去指定這個認證是屬於哪個類別的，可以讓認證的內容更加彈性，例如是生物辨識的資料，或是住家地址，不...