Kimi的筆記

最近重新追了一下Ethereum Casper的進展，發現到好多新東西（應該是之前看得太表面 ＸＤ），Casper跟sharding會綁一起，然後又有個beacon chain，zk-STARK（zk-SNARK的升級版）也來湊一腳，短時間有點難消化，有興趣的人可以google上面幾個keyword。 不過，今天想要介紹的是BLS signature（這又是什麼？？？？？），這個新的簽章方式讓Casper往前再邁進一步！ BLS是Boneh–Lynn–Shacham的縮寫，有興趣的可以參考 wiki 。這個簽章方式厲害的是，可以把所有signature加起來，然後驗證。如果以現今的ECDSA簽章，100個人簽同一個message，那訊息量就是乘以100倍，以Ethereum官方估計，Casper的validators約有30萬，每一個finality都需要2/3的節點做投票，光是驗證signature這件事，大概就要花到一天，所以以現行的ECDSA簽章方式根本不可行。這也是之前Casper的bottleneck之一，Ethereum的researcher, Justin Drake提出了這個 方案 ，當然也不是拿了就可以用的，BLS的介紹可以參考 BLS signatures: better than Schnorr ，寫得非常清楚也好懂。下面會簡單介紹一下。 首先，就是要找到一個特殊的橢圓對稱曲線可以達到以下的算式     e(a x P, b x Q) = e(P, ab x Q) = e(ab x P, Q) = e(P, Q)^(ab) 也就是某種的交換律 用上面那邊文章的圖做解釋     pk ：私鑰     P ：公鑰     H(m) ：可以看作是hash過的message     S ：簽章 驗證簽章會滿足     e(P, H(m)) = e(G, S) 也就是 signature 可以用 P（公鑰） 跟 H(m)（hash過的message） 做 驗證，跟我們以往的認知是一致的。從公式看BLS在sign跟verify都很簡潔，資料量的部分也小了許多（好像是33 bytes）。而...

版本 - truffle 4.1.11 一不小心，就寫到了III...沒有偷文章數的意思阿~~~ 不過我在這邊先破題，truffle的debug功能，還在發展中，其實沒有想像中的方便跟powerful，例如在debug的過程還滿常會發生exception的（這還滿常發生的）、 無法得知 global變數內容...等等。官方一樣有很詳細的解說，可以看 這裡 。 要debug其實很簡單，先複製你要debug的transaction hash，然後 $ truffle debug 0x1d8791c26e7aa941c295bed8ed81a3d5fb4790ed9f84a76e2d4341c6c4b09131 接著會看到指令 Commands: (enter) last command entered (step next) (o) step over, (i) step into, (u) step out, (n) step next (;) step instruction, (p) print instruction, (h) print this help, (q) quit (b) toggle breakpoint, (c) continue until breakpoint (+) add watch expression (`+:<expr>`), (-) remove watch expression (-:<expr>) (?) list existing watch expressions (v) print variables and values, (:) evaluate expression - see `v` o/i/u/n：一般有在用IDE debug的都知道，就不做解釋 +：可以加觀察的變數 v：就是顯示目前變數的值（global目前都是空值） 一步一步debug就會看到在哪行source code，像是這樣 Token777.sol: 277 : if (_to== address ( 0x00 )) return ; 278 : TokenReceiver x; 279 : if ( doesContractIm...

版本 - truffle 4.1.11 延續 上篇 ，繼續講測試的部分 寫test case有兩個方式，一個是用 solidity 另一個是用 javascript ，官方文件寫得還滿清楚的。記得你寫的test case的檔案，要放在 test/ 下 先介紹solidity的寫法，要先import下面這兩個smart contract，當然也要記得import你自己的smart contract import "truffle/Assert.sol" ; import "truffle/DeployedAddresses.sol" ; import "../contracts/Token777.sol" ;  再來是命名規則，contract要以  Test   為開頭，測試function要以  test  為開頭 contract TestTaroToken { function testMint () public { Token777 token = Token777 (DeployedAddresses. Token777 ()); address user = 0x2849f61e08B66A3b0eC2512613092174Df19Db1e ; uint base = token. balanceOf (user); uint incremental = 30000000000000000000 ; token. mint (user,incremental, "" ); Assert. equal (token. balanceOf (user), base+incremental, "balance is not equal" ); } } test case看起來相當直覺，就是先取得contract object後，呼叫mint（你想測試的function）這個function，最後用Assert確認結果，跟我們一般寫UT很相似。當然也有提供 beforeAll , beforeEach , afterAll 跟  afterEach...

今天來介紹一下truffle。 版本 - truffle 4.1.11     在我一開始踏入這個圈子的時候，是truffle是出testrpc這個工具，當時google了一下，有人說不好安裝設定，所以就選用了parity。parity對於初期開發還不錯用，有圖形化的介面，寫完的code直接部署，呼叫function有下拉式選單可以直接使用，event log也很清楚顯示。其實也滿推的，不過一開始不懂的時候，genesis 設定檔也是搞了一陣子（不過現在也沒多懂 XD）。     那parity既然這麼好用，幹嘛用truffle？truffle後來出了Ganache，一個圖形化的介面，會有transaction的列表，裡面會有input data （我覺得可惜的是沒有output event），還有log，可以看實際呼叫了哪個rpc call等一些資訊。但重要的安裝完後，點兩下直接就可以用，不需複雜的設定檔，對於單純只要開發smart contract的人來說，才是最方便的。     但是！這些都不是重點， 重點是truffle可以跑test cases跟逐步debug 。對！逐步，我跟同事分享，同事眼睛都亮起來了，因為在寫smart contract在debug部分其實挺麻煩的，雖然Remix也可以做到debug，但是class越多source file越多，在Remix上需要一個一個copy過去，就沒這麼方便。此外，寫test case這部分 對公司產品開發的流程上有很大的幫助，不用像我之前還傻傻的用web3j自己寫testing framework.....     這偏廢話有點多，接下來就介紹怎麼 寫test cases 跟 debug （安裝就不用講了吧，下載下來點兩下，下一步下一步下一步....我是用Windows XD），細節可以參考 這篇 ，官方說得滿清楚的，懶得看英文的可以繼續往下看     首先， 在Windows上不要使用Windows的cmd ，會有名稱問題，我是用Git的bash shell，然後下 truffle init 會在目錄下長出這些東西，其中Mirgrations.sol跟1_initial_migratio...

    本篇不會牽涉到數學公式或是算法，只是簡單解釋格式上的差異     在我們應用中，會有兩個場景需要對訊息做簽章的動作，一個是簽章完送到smart contract裡用ecrecover做身份確認，另一個是單純把訊息（例如：個人資料）做簽章，確保訊息確實是本人的（就像簽名一樣）。     我們產品中會有iOS, Android或是後端的C#或JAVA，每種語言對ECDSA的使用方式都有所不同，有原生也有third party library，加上Web3也有提供sign message的功能，一開始大家一知半解，不太知道差異，所以在開發的時候，搞得人仰馬翻。 本篇就是針對標準ECDSA跟Web3提供的sign message做一點“ 簡單” 的解釋 。     首先，你要先知道 r s v，不用知道他背後的意義（因為我也不清楚 ＸＤ），但是你需要知道sign（本篇的sign都是指ECDSA）過的message可以被分解為 r s，咦？！ 說好的 v 勒？？ 先破題， 這就是標準ECDSA跟Ethereum用來可以recover signed message的差異 （其實Ethereum是沿用Bitcoin的）。     在ECDSA sign完的訊息可以分解成 r 跟 s ，不過只靠rs所反解的public key會有四組，不過實際上大家都只看兩組，因為另外兩組出現機率很低， 這篇解答 中的推文有解釋。 27 = lower X even Y. 28 = lower X odd Y. 29 = higher X even Y. 30 = higher X odd Y. Note that 29 and 30 are exceedingly rarely, and will in practice only ever be seen in specifically generated examples. There are only two possible X values if r is between 1 and (p mod n), which has a chance of about 0.0000000000000000000000...

  之前的文章有聊過Transaction Manager，當時對於一個參數TransactionReceiptProcessor 不太能了解，這次因為一些需求，找到了這個物件，剛好可以解決我們的問題。所以這邊要聊聊Web3中，TransactionReceiptProcessor 的運用。      在我們實際開發的場景中，在smart contract的function最後會留下一個event，作為紀錄，方便當下的驗證，在未來的稽核跟調閱歷史紀錄也比較方便。最一開始，我們選擇了web3j wrapper裡提供的event observable去對event做註冊的方式，如何使用可以參考 這篇文章 的How to monitor events。     不過，在實際的應用上會發現，observable回來的物件，資訊不太足夠，只有單純event的參數內容，還是會希望有transaction receipt會比較方便作後面的應用。但是也不希望每次送transaction都等在那邊，或是用aync放到queue再開thread做polling。簡單來說，就是希望簡單用，不要只是送個交易，還要做這麼多管理。     此次我們的應用，是要把前端資料，藉由後端sign過再push到鏈上，所以原則上是send raw transaction的方式，這次單純使用 RawTransactionManager 這個物件。在 RawTransactionManager 預設是使用 PollingTransactionReceiptProcessor ，根據官方解釋： is the default processor used in web3j, which polls periodically for a transaction receipt for each individual pending transaction.  此時發現另一種process叫做， QueuingTransactionReceiptProcessor has an internal queue of all pending transactions. It contains a...

每次看完raw transaction的組法，都會忘記，所以紀錄一下 使用Web3元件呼叫smart contract的function，就我所知有兩個方法 ，一個是自己組成raw transaction，另一個是用web3j產生的 java wrapper呼叫（不過最終還是組成raw transaction）。在這邊就是要介紹raw transaction到底是怎麼組成的 首先，會先對function做encoding的動作，encoding完會長得下面這樣，一堆hex字串 以上圖來說，我對 addMember(address, bytes, bytes...) （參數太多，所以做省略）這個function做encoding，最前面是function的symbol，作sha3然後取前四個bytes keccak256("addMember(address,bytes,bytes,...)") // 0x 9400062b 56b462ed4e31c3f26b13ce3523a3881b5c19480da8856142e9b687d0 後面緊接著的就是參數了，這個很容易理解。更詳細的解釋可以參考 Inside an Ethereum transaction ，解釋得很清楚 接下來，就是把encoded function組成raw transaction了 組完的結果會像這樣 在原本的hex字串，頭尾加上一堆不知道幹嘛的字串， 本篇的重點就是在解釋這個字串 。 如果，讀者有看完上面那篇Inside an Ethereum transaction，就可以知道，其實transaction的組成是由 var rawTx = { nonce, gasPrice, gasLimit, to, value, data, signature }; 這裡的data就是encoded function，所以前面還有nonce, gas price, gas limit跟送給誰的地址，最後是加上signature。不過，如果你直接看，一定會納悶，感覺對但好像又不對，中間似乎穿插了莫名的值，這是因為Ethereum在做serialize的時候，選用RLP做enc...