今回も引き続き、福岡ブロックチェーン勉強会#29 エキスパートコースでQ&A形式で発表した、EIP-1679についてまとめていきます。
github.com
本記事は連載記事となっております。よろしければ前回の記事もご覧ください。
y-nakajo.hatenablog.com
このEIP-1679は次のEthereum1.0のアップデートであるIstanbulで導入されるEIPについてまとめたものです。EIP-1679は現在はまだ導入される候補(Proposal)EIPをリストアップしたものであり、この中から期限までに実装可能で十分にテストされたものだけが、最終的にIstanbulとしてEthereumに導入されます。
リストをみてわかる通り、多くのEIPが候補に上がっており、また似たようなEIPも多数含まれています。引き続きこれらのEIPをカテゴライズしながら紹介します。
今回は、先日の福岡ブロックチェーン勉強会#29 エキスパートコースでQ&A形式で発表した、EIP-1679についてまとめていきます。
github.com
このEIP-1679は次のEthereum1.0のアップデートであるIstanbulで導入されるEIPについてまとめたものです。EIP-1679は現在はまだ導入される候補(Proposal)EIPをリストアップしたものであり、この中から期限までに実装可能で十分にテストされたものだけが、最終的にIstanbulとしてEthereumに導入されます。
リストをみてわかる通り、多くのEIPが候補に上がっており、また似たようなEIPも多数含まれています。今回の記事ではこれらのEIPをカテゴライズしながら紹介します。
今回は、次期updateの提案、EIP-1679 Hardfork Meta: Istanbulで導入候補に上がっている、EIP-615について解説します。
eips.ethereum.org
今回はDefiでおなじみのdydxのv2 protocolである、soloで遊ぶためにローカルでsoloを構築する手順を説明します。
dydx.exchange
マージントレード、デリバティブトレードとして有名なdydxですが、最近プロトコルがバージョンアップされv2 soloとなりv1 expoとは大幅にコントラクトの様相が変わっております。特にマージントレードの幅広い戦略をサポートするために考案されたActionsのプロトコルは非常にメタ化された概念であり、ソースコードからその実態を掴むのは容易ではありません。
そのため、本記事ではdydx soloで追加されたActionsを実際に動かしながら体験するために、dydx soloをローカルに構築する手順を解説します。
なお、本記事ではdydx soloに関する詳しい説明やActionsを利用したマージントレード戦略の具体的な記述方法については解説しないのでご注意ください。
今回はEthereumでDappsを開発した経験のある人は1度は目にしたことがある、「ABI」について解説します。
ABIの仕様は以下のSolidityのドキュメントにまとめられています。
solidity.readthedocs.io
ABI仕様の技術的な説明は上記ドキュメントに譲るとして、本記事では、ABIの目的やABIがどのように参照・利用されているか？に焦点を当てて解説します。
今回はEthereumで発行されたTransactionがPending状態である場合にどの様にpoolに保持されているのか。また、Transaction Poolはどの程度のtransaction数を保持するのか？などのTransaction poolの動きについて調べたことをまとめていきたいと思います。
今回の説明はgo-ethereumのソースを参考にしております。
github.com
transaction poolの仕様についてはyellowpaperで特に定義されているわけではないっぽいのでnode実装ごとに若干異なる可能性があります。
※2021/09/19にgo-ethereumのソースコードのリンク先をv1.10.8のものに修正
Ethereum nodeがTransactionを受信したときは次の様に処理されます。
nodeでは、常に新しいTransactionを受け取るたびに、1.および2.の処理が実行されます。また、定期的および新しいBlockを受け取るたびに、3.と4.の処理が実行されます。新しいTransactionはそれが問題のないものか検証してpoolに追加され、その後、定期的にpoolの状態をお掃除する。という感じの動作になります。
これらの動作についてそれぞれ詳しく見ていきます。
まず、poolに以下の全てのチェックに合格したものが有効なTransactionと見なされます。
これら、9つの検証に全て合格したTransactionがpoolに追加されます。
次は、これらの検証に合格し、正当と見なされたTransactionがpoolにどの様に格納されていくかを説明します。
検証に合格したTransactionであれば、poolに空きがある場合はpoolに追加されます。poolに空きがない場合は、ある条件を満たしたTransactionのみがpoolに追加されます。
上記の動作を詳しく説明するために、まずはTransaction Poolの容量について説明します。
Transaction Poolの容量としては4つの種類が設定されています。
となっています。non-executable transactionについては後述します。上記の容量区分からもわかる通り、poolにはまず大きく2つの箱が用意されています。1つ目はpending transactionが入る箱（これを以降はpending listと呼ぶ）。そして、もう一つはnon-executable transactionの入る箱（これを以降はqueueと呼ぶ）です。
受信したTransactionは全てまず、queueに入れられます。その後すぐに定期loop処理でnonceがチェックされて、nonceの条件を満たすものがqueueからpending listに移されます。
受信したTransactionを他のnodeに伝搬するのはこのタイミングになります。つまりqueueからpending listに移すと同時にそのtransactionが他のnodeへ伝搬されます。
これらの容量の定義とdefault値の設定が書いてあるソースの箇所は以下になります。
次は上記で説明を割愛したnon-executable transactionについて説明します。
non-executable transactionとは、現在のblockに格納されているTransactionのnonceに+1した値よりもより大きなnonceを持ったTransactionのことです。とあるアカウントを 、あるアカウントAが発行したTransactionを
、現在のblockに格納されているアカウントAのTransactionを
、Transactionのnonceを
とした場合、次の式を満たすものがnon-executable transactionです。
また、pending transactionは上記の定義を用いると下記の式を満たすものになります。
nonceはあるアカウントから発行されたTransactionの数であり、blockに格納する順番を示すものです。Ethereumでは現在blockに格納されているtransactionが持つnonceの+1したnonceを持つtransaction（つまりpending transaction）が次のブロックに格納されます。nonceの値は常に1つずつインクリメントされるため、より大きな値を指定した場合は、間の値を埋めるnonceを持つtransactionが発行されるまで、それらのtransactionはblockに格納されません*1。つまり、すぐには実行ができないtransactionであるため、non-executable transactionと呼ばれます。
漸く、poolが一杯の場合にTransactionがpoolに格納される条件についての説明に入ります。
poolで指定されている前述した4つの容量制限のどれかに引っかかった場合は、Transactionは以下の条件を満たす場合にのみ、poolに格納されます。
受信したTransactionが上記条件を満たしていた場合、poolの中にある最小のgasPriceを持つTransactionと受信したTransactionが入れ替えられることになります。上記条件を満たさない場合は、エラーとなり受信したTransactionは捨てられます。
nonceに関するより詳しい説明は次の記事を参照ください。
kb.myetherwallet.com
ちなみに、localなアカウント（多分geth node自体が管理しているaddress）から発行されたTransactionについては上記の条件は無視され、優先的にpoolに格納されます。
これまでは、受信した、もしくはlocalで発行されたTransactionがどの様にpoolの中のqueueの領域に格納されるのかを見てきました。ここからは、queueに格納されたTransactionがpending listに昇格する処理、および、定期的に行われるpoolの整理の処理を説明します。
Ethereumのnodeでは定期的にpoolの中身であるpending listとqueueの状況を監視・管理しています。定期的に実行される処理は以下の3つになります。
1.と2.の処理はそのままなので特に詳しくは説明しません。ここでは3.の処理について詳しく見ていきたいと思います。
pending transactionはある意味、いつかはblockに格納されることがわかっているので特に時間制限は設けられていません。逆に、non-executable transactionについては、間のnonceを埋めるTransactionが発行されるまで絶対にblockには格納されません。そのため、アタックベクターとなり得るので、queueに格納されたTransactionは時間制限によって削除される様になっています。
queueからは以下の条件に合致する古いTransactionを削除します。
該当ソースは以下を参照ください。
queueから古いtxを削除する処理(tx_pool.go#L374-L381)
古いTransactionを削除する場合は、Transactionごとに個別の発行時間を見るのではなく、アカウントごとに、最後にTransactionを発行した時間を元に判断されます。
最後に、新しいBlockを受け取った時のpoolの整理の処理について説明します。基本的には定期的なloop処理と同じ処理が行われますが、新しいBlockを受け取った場合は追加として以下の処理も行われます。
となります。ここも特に複雑な処理はしていないため詳細な説明は割愛します。簡単にまとめると、新しいBlockのデータを適用させることで、無効となったTransactionを削除するという処理が行われます。
該当ソースは以下を参照ください。
demoteUnexecutablesの処理(tx_pool.go#L1474-L1532)
nonceの扱いによって、すぐにblockに格納されないTransaction(non-executable transaction)が生成できることは知っていましたが、non-executable transactionがどの様に扱われるのかがよく分かっていなかったので今回調べてみました。
また、transaction poolの処理を調べたことで以下のことも新たに知ることができました。
そのほかにも、poolを埋め尽くす様な攻撃を仕掛けてきたアカウントをblacklistに入れたり、64block以上のreorgが起きた時に同期を諦めるwなども実装されていることがわかりました。
この辺りの基本的なことは興味のある人は少ないかもしれませんが、特に詳しく説明しているブログなども見当たらないので、何かの助けになればと思いまとめてみました。
自分もまだ完全に理解できてはいないので、何かしら疑問点などありましたらぜひ質問してください。
*1:Ganacheを使っているのに、MetaMaskでsignしたTransactionがなかなかblockに入らないという経験をしたことがある人はそこそこいるはず。。。
*2:該当ソース：https://github.com/ethereum/go-ethereum/blob/v1.10.8/core/tx_pool.go#L1305-L1313
*3:該当ソース：https://github.com/ethereum/go-ethereum/blob/v1.10.8/core/tx_pool.go#L658-L669
今回は、いよいよ来週の2019/01/16にupdateされるConstantinopleで導入されるEIPのうちの一つである、EIP-1014について解説します。
eip-1014.mdにも書かれているとおり、これはstate channelに対して非常に重要な機能であり、個人的にConstantinopleで導入される機能の中でも一番注目しています。
では早速EIP-1014について解説していきます。
続きを読む