【完全保存版】Solanaのトランザクションの仕組み（５つの構成）を理解しよう！
この記事はこちらのHeliusの記事の一部を翻訳・編集したものです。
０ はじめに
バリデーターのトランザクション処理ユニット（TPU）は、トランザクションを受信し、署名を検証して実行し、その後、ネットワーク内の他のバリデーターと共有します。
TPUは、5つの異なる段階でトランザクションを処理します。
１ フェッチステージ（Fetch Stage）
フェッチステージは、トランザクションを受信する役割を担います。
トランザクションは、以下の3つのポートに応じて分類されます。
１ tpu
トークン転送、NFTミント、およびプログラム命令などの通常のトランザクションを処理します。
２ tpu_vote
投票トランザクションを専用に処理します。
３ tpu_forwards
現在のリーダーがすべてのトランザクションを処理できない場合、未処理のパケットを次のリーダーに転送します。
パケットは128のグループにまとめられ、SigVerifyステージに転送されます。
２ SigVerifyステージ
SigVerifyステージは、パケットの署名を検証し、検証に失敗したものを取り除きます。
投票と通常のパケットは、2つの別々のパイプラインで処理されます。
ソフトウェアの視点では、受信したパケットにはメタデータが含まれていますが、それらがトランザクションであるかどうかはまだ不明です。
翻訳者注
これは、「Fetchステージ」の話だと思いました。
不明であるからこそ、この「SigVerify」ステージで検証が必要だと思いました。
GPUがインストールされている場合は、署名の検証に利用されます。
翻訳者注
GRUがある場合には、それを使った方が高速に処理できるからですね。
さらに、高トラフィック時に過剰なパケットを処理するロジックがあり、これにはIPアドレスを利用してパケットをドロップする機能があります。
翻訳者注
つまり、特定のIPアドレスが大量に送ってきた際は、そのIPアドレスからのパケットを優先的にドロップ（処理をせずに捨てる）するなどができるのだと翻訳者は考えました。
３ バンキングステージ（Banking Stage）
このステージは、トランザクションをフィルタリングして処理する役割を担います。
現在、このステージは6つの独立したワーカースレッドで構成されており、そのうち2つは投票用、4つは非投票用のスレッドです。
通常のトランザクションは、非投票用のスレッドに追加されます。
各スレッドには、最大64の非競合トランザクションを優先順位キューで保持できるローカルバッファがあります。
翻訳者注
非競合トランザクションとはその名の通り、競合しないトランザクションです。
例えば、あるアカウントに対して、書き込みを行う２つのトランザクションがある場合、それは同時に処理できないので、競合しています。
そのような競合がないトランザクションです。
これらのトランザクションは、Sealevelによって並行して処理されます。
バンキングステージの詳細については、このビデオを参照してください。
４ プルーフ・オブ・ヒストリーサービス（Proof of History Service）
PoHサービスモジュールは、ティックの経過を記録します。
各ティックは時間の単位を表し、1スロットには64ティックが含まれます。
ハッシュは、バンキングステージからレコードが受信されるまで繰り返し生成されます。
翻訳者注
バンキングステージからレコードが受信された場合、それを取り込んだ上で、ハッシュ化します。
next_hash = hash(prev_hash, hash(transaction_ids))
これらのレコードは、エントリに変換され、ブロードキャストステージを介してネットワークにブロードキャストされます。
５ ブロードキャストステージ（Broadcast Stage）
PoHサービスからのエントリはシュレッドに変換されます。
これはブロックの最小単位を表し、Turbineと呼ばれるブロック伝播技術を使用してネットワークの残りの部分に送信されます。
Turbineは、ブロックを小さな部分に分割し、ノードの階層構造を通じて配布します。
ノードは他のすべてのノードと連絡を取る必要はありません。
選択されたいくつかのノードと通信するだけで十分です。
Turbineの詳細とその仕組みについては、この記事を参照してください。
いいなと思ったら応援しよう！
