Kimi的筆記

在做區塊鏈應用的時候，最常碰到的一個問題就是，怎麼保管私鑰，怎麼讓使用者方便，但又同時是安全的。第一個想法就是備份金鑰（不論是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的欄位，可以讓認證方去指定這個認證是屬於哪個類別的，可以讓認證的內容更加彈性，例如是生物辨識的資料，或是住家地址，不...

Vitalik大約在一年前(2017/08)提出了Plasma這個概念以解決Ethereum交易速度及成本的問題，不過提出的內容太概念性，沒什麼人知道該怎麼實作，在今年初Vitalik提出了 Plasma MVP(Minimal Viable Plasma) ，最小可行性的Plasma，而目前大家也是遵循這個規範來實作。 Plasma屬於layer 2的solution，就是在主鏈之外做運作(也就是離線交易)。Plasma簡單來說就是鏈中鏈，每個鏈都可以有自己的鏈，自己的鏈還可以再有鏈，就像是tree一樣的概念。舉例來說，往後交易所就可以創造自己的鏈，在自己鏈內交易，速度快而且無手續費。而目前MVP的設計是在主鏈外多一層而已，還沒有多層的概念。上個月的COSCUP有Plasma的開發者的分享， 影片連結在這 （是中文，大家不用害怕 ＸＤ）。 Plasma MVP 在每個Plasma chain會有一個operator，operator負責產塊（可以想像是中心化的管理者），以目前來說，operator實作成Restful API server，而產塊可以想作是在ＤＢ insert一筆紀錄，跟我們以往中心化的系統一樣。而你要進入到這個Plasma chain需要先在主鏈上的smart contract作存款（deposit）才能進入。然後Plasma chain每產一個塊，就必須跟主鏈作回報（回報Merkle root），這樣Plasma chain這邊的塊才算被confirm。每個Plasma chain是獨立的，所以不能跨鏈交易，必須先轉回到主鏈。 可以這樣想像，一個Plasma chain是一間賭場，你要進入一間賭場要先去把新台幣換成賭場的籌碼（deposit），接著你就可以在這間賭場做任何交易，那如果你要去隔壁賭場下注呢? 你要先換成新台幣，然後再換成隔壁賭場的籌碼。而在賭場的每一筆交易，都會被記載在賭場的帳本上(可以想像是Excel表格)，而這個帳本要定期地跟政府報備，報備通過了，在帳本上的交易紀錄，才會被承認。Plasma chain的概念大概就像這樣。 那安全問題呢? operator是中央式的，如果被攻擊或是原本就是惡意的呢?接續上面的例子，其實要把籌碼換成新台幣，沒有這麼簡單。首先，要七天後才能領出...

這篇會著重在erc20 smart contract實作mint跟burn的部分，所以需要先了解erc20喔！ erc20 token在設計上可以a.預先產生，b.產生部分然後部分用挖的(mint)或是c.都用挖的。當然在應用上跟token屬性有關，例如是屬於security token或是utility token。簡單來說，像是股票可以獲利或是配息概念的算是security token，需要受各國法令監管，那utility token就比較像是點數的概念，至於細節怎麼分不是本篇重點。 mint的使用時機，例如在crowd sale時，每一筆進入crowd sale的錢，crowd sale 的contract 就會呼叫token contract去產生某個數量的token，這個動作就可以稱作mint。也有不用挖的，一開始就產生好，例如秘銀（MITH），從etherscan可以看到token contract怎麼寫的，這裡可以看到 MITH的contract 。當然你想產多少就多少，不過就看有沒有人買單 ＸＤ 回到正題，要"挖"聽起來，就覺得很複雜，但其實smart contract的本質就是記帳，所以其實就只是數字上的加減而已，下面是範例程式 function mint(address _to, uint256 _amount) public { totalSupply_ = totalSupply_.add(_amount); balances[_to] = balances[_to].add(_amount); emit Mint(_to, _amount); } 其實就只是把 增加個人的token的數量 ，然後增 加整個contract token的總數 而已。當然，這種function需要做權限的控管，不然大家都可以自己產，token就會沒價值了。講完"挖"應該很好想像怎麼burn吧?! 就是把數量減掉就好了！(當然這也需要做權限控管) function _burn(address _who, uint256 _value) public { balances[_who] = balances[_who].sub(_value); totalSu...