Kimi的筆記

    本篇不會牽涉到數學公式或是算法，只是簡單解釋格式上的差異     在我們應用中，會有兩個場景需要對訊息做簽章的動作，一個是簽章完送到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...