アルゴリズムとかオーダーとか

仕事で勉強したことなどをまとめてます

gethのsyncingについてのソース解析メモ　その２

前回の続きとして、今回は特にReceiptsの取得処理周りを見ていく。Receiptの取得処理はfast syncの時に呼ばれ、full syncでは呼ばれないというコメントがあるが、そこの動きがよくわかっていないので、該当コードがどうなっているかを解析する。

ReceiptsPacket パケット受け取ってから

ReceiptsPacketを受け取ると以下を経て、最終的にchannelに対して配信される。
https://github.com/ethereum/go-ethereum/blob/v1.10.2/eth/downloader/downloader.go#L1964-L1967
https://github.com/ethereum/go-ethereum/blob/97d11b0187b4695ccf44e3b71b54155fe405a36f/eth/downloader/downloader.go#L2000-L2022

で、この後は非同期な処理になるためコードジャンプで追えない。なので、receiptChからメッセージを受け取っている部分を探してみると、どうやら以下のあたりで処理を行っているぽい。

https://github.com/ethereum/go-ethereum/blob/97d11b0187b4695ccf44e3b71b54155fe405a36f/eth/downloader/downloader.go#L1298-L1322
で、結局戻ってくるが、どうやらこの中のd.queue.DeliverReceipts(pack.peerID, pack.receipts)が受け取ったReceiptsパケットを保存している処理っぽい。

func (d *Downloader) fetchParts について

同Downloader内のfetch処理の以下の3つから呼ばれている。

リモートピアからデータを受け取るためには、どのブロックのデータが欲しいのか？応答が正常化？タイムアウトしていないか？ユーザがキャンセルしていないか？などなどを処理しないといけない。
それらの処理を共通化しているのが、このfetchParts関数の様だ。

実際のデータパケットを受け取った時にそれをqueueにためておくのが、deliver func(dataPack) (int, error) となる。そのため、上記3つについて、それぞれこのdeliverに指定されている関数を見ていけば、具体的に何のデータを受け取って保存しているかがわかる。

が、今回はfull syncの場合にReceiptsの取得が呼ばれない仕組みを調べたいのでその部分を探す。

Receipts要求メッセージを送っている部分

Downloader#fetchReceiptsからコードを辿っていくと、Receiptsの要求メッセージを送っている部分は、以下の関数の部分となる。
https://github.com/ethereum/go-ethereum/blob/v1.10.2/eth/downloader/peer.go#L178-L196
最終的には、以下が呼ばれる。が、ここにはsyncModeによる切り替え処理は見当たらない。
https://github.com/ethereum/go-ethereum/blob/v1.10.2/eth/protocols/eth/peer.go#L500-L510


ということで、戻って、Downloader#fetchPartsの処理を詳しく見ていく。

func (d *Downloader) fetchParts のfetchReceipts処理

FetchRecipts関数はfetchPartsのfetch引数として話されている。なので、fetchが呼ばれている箇所を探すと以下となる。
https://github.com/ethereum/go-ethereum/blob/v1.10.2/eth/downloader/downloader.go#L1502
で、その少しうえで、requestがnullの場合はfetchが呼ばれてないことがわかる。
https://github.com/ethereum/go-ethereum/blob/v1.10.2/eth/downloader/downloader.go#L1490-L1492


では、そのrequestをどうやって取得しているのかというと、そのまた少しうえで、reserveから取得していることがわかる。
https://github.com/ethereum/go-ethereum/blob/v1.10.2/eth/downloader/downloader.go#L1482
また、このreserverが何者こについては、FetchReceiptsを見ると、d.queue.ReserveReceiptsであることがわかる。
https://github.com/ethereum/go-ethereum/blob/v1.10.2/eth/downloader/downloader.go#L1316-L1318

ReserveReceiptsの実態

d.queue.ReserveReceiptsからコードを追っていくと、最終的に、func (q *queue) reserveHeadersに行き着く。
で、この関数の中で*fetchRequestでnilを返している箇所を探すと以下の3つが見つかる。
https://github.com/ethereum/go-ethereum/blob/v1.10.2/eth/downloader/queue.go#L487-L489
https://github.com/ethereum/go-ethereum/blob/v1.10.2/eth/downloader/queue.go#L490-L492
https://github.com/ethereum/go-ethereum/blob/v1.10.2/eth/downloader/queue.go#L557-L559

三番目のsendについては、taskQueueのうち、以前に取得失敗した分を取り除いたリストなので、いずれにしてもtaskQueueのサイズが関係していることがわかった。このtaskQueueとはつまり、q.receiptTaskQueueのことなので、Queue#receiptTaskQueueに値を詰めている箇所を探す。

q.receiptTaskQueueにitemをpushしている箇所

receiptTaskQueueを探してみると以下の箇所が見つかった。
https://github.com/ethereum/go-ethereum/blob/97d11b0187b4695ccf44e3b71b54155fe405a36f/eth/downloader/queue.go#L320-L328
コードにある様に、syncModeがFastSyncの場合だけreceiptTaskQueueにセットしているのでここで正解っぽい。

なお、もう一つpushしている箇所が見つかったが、Revoke関数なのでここは関係ないと思う。
https://github.com/ethereum/go-ethereum/blob/v1.10.2/eth/downloader/queue.go#L618

まとめ

FastSyncの時だけ、Receiptsの取得処理が走るのは、そもそもReceiptsを要求するメッセージを送るための、receiptTaskQueueが他のモードの場合は常に空になっているから。