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.000000000000000000000000000000000000373 % to happen randomly.       那

  之前的文章有聊過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 worker that runs periodically to query if a tran

每次看完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