トランザクションツリーとレシートツリー
ブロックがパブリッシュされるたびに、ブロック内のトランザクションによってトランザクション ツリーが形成されます。さらに、イーサリアムは、各トランザクションが実行された後に領収書を形成してトランザクション関連情報を記録する領収書ツリーも追加します。つまり、トランザクションツリーとレシートツリー上のノードは1対1に対応します。
なぜレシートツリーを増やすのでしょうか?
イーサリアムスマートコントラクトの実行はより複雑であるため、レシートツリーを追加することで、実行結果を素早くクエリすることができて便利です。
BTCでは通常のMT（マークルツリー）が使用されるのに対し、トランザクションツリーとレシートツリーはいずれもM（マークル）PTです。(イーサリアムはなぜマークル ツリーを使用しないのでしょうか?シャオ氏は、イーサリアムの 3 つのツリー コードを統一するためだけに設計されたのではないかと考えています。) MPT の利点は、検索操作をサポートしていることです。MPT は、ツリーに沿って検索できることです
。重要な値。状態ツリーの場合、ルックアップ キーの値はアカウント アドレスであり、トランザクション ツリーとレシート ツリーの場合、ルックアップ キーの値はパブリッシュされたブロック内のトランザクションのシーケンス番号です。
トランザクション ツリーとレシート ツリーの目的:
1. ライトノードにマークルプルーフを提供します。
2. より複雑な検索操作 (例: 過去 10 日間のトランザクションの検索、過去 10 日間のクラウドファンディング イベントなど)。
ブルームフィルター (ブルームフィルター)
ブルーム フィルターは、要素がコレクション内にあるかどうかのより効率的な検索をサポートします。
ブルーム フィルターを使用しない場合、最も原始的な方法は、O(n) の複雑さですべてを走査することです。ライトノードにはすべての要素を格納するのに十分なスペースがなく、完全なトランザクション リストがないため、次の方法が使用されます。ブルート フォース トラバーサルは、ライト ノードでは使用できません。
ブルームフィルターの検索アイデア
以下の図に示すように、データセットが与えられると、意味要素 a、b、c がハッシュ関数 H() によって計算され、初期値がすべて 0 である 128 ビットのベクトルの特定の位置にマッピングされます。ビットを 1 に設定します。すべての要素が処理された後、元のコレクションの「概要」と呼ばれるベクトルを取得できます。「要約」が元のコレクションよりもはるかに小さいことがわかります。
H(d) がベクトルにマッピングされる位置が 0 (d がセット内にあってはいけないことを示す) であると仮定し、要素 d がセット内にあるかどうかをクエリするとします。ベクトルが 1 にマッピングされている場合、コレクション内に実際に d が存在する可能性があります。あるいは、ハッシュの衝突による誤検出が存在する可能性があります。
偽陽性
ブルーム フィルターを使用する特徴の 1 つは、コレクション内にあるべき要素が正しくブロードキャストされ、コレクション内にない要素もコレクション内にあるものとしてブロードキャストされる可能性があることです。
したがって、ブルーム フィルターにはいくつかのバリエーションがあり、たとえば、ハッシュをマッピングする場合、ハッシュの衝突を効果的に回避するために、ベクトル マッピングに一連のハッシュ関数が使用されます。
コレクションから要素を削除したい場合はどうすればよいですか?
ブルームフィルターを使用したい場合、それは簡単ではありません。実際、単純に 1 を 0 に変更した場合、この操作によって変更が必要な 1 が変更されたのか、それともハッシュの衝突によって生じた 1 が変更されたのかを判断する方法はありません。削除操作をサポートしたい場合は、レコード数を 0 と 1 からカウンターに変更する必要があります (カウンターがオーバーフローするかどうかを考慮する必要があります)。
イーサリアムにおけるブルームフィルターの役割
各取引が完了すると、取引の種類、住所、その他の情報を記録するためのブルーム フィルターを含む領収書が生成されます。ブルーム フィルターもブロック ヘッダーに含まれており、ブロック内のすべてのトランザクションのブルーム フィルターを結合したものになります。
したがって、検索するときは、ブロック ヘッダーにブルーム フィルターが含まれている場合は、まずブロック ヘッダー内のブルーム フィルターを検索します。次に、ブロックに含まれるトランザクションのブルームフィルターを確認し、存在する場合はトランザクションを確認し、存在しない場合は「衝突」が発生したことを意味します。
利点は、ブルーム フィルターの構造により、たとえばライト ノードの場合、ブロック ヘッダーを使用して多数の無関係なブロックを迅速に除外できるため、検索効率が向上し、フル ノードに問い合わせることができることです。詳細については。
要約する
イーサリアムの実行プロセスはトランザクション駆動のステートマシンとみなすことができ、現在のブロックに含まれるトランザクションを実行することで、駆動システムは現在の状態から次の状態に移行します。もちろん、BTC はトランザクション駆動のステート マシンとみなすこともでき、その状態は UTXO です。
特定の現在の状態および特定のトランザクションのセットについて、次の状態に決定的に移行することが可能です (システムの一貫性を保証します)。
A が B に送金しますが、その受取口座が状態ツリーに含まれていない可能性はありますか?
可能。Ethereum のアカウントはノード自体によって生成できるため、トランザクションが生成されたときにのみシステムによって認識されます。
各ブロックの状態ツリーを変更して、ブロック内のトランザクションに関連するアカウントの状態のみを含めることはできますか? (状態ツリーのサイズを大幅に縮小し、トランザクション ツリーおよびレシート ツリーとの一貫性を保ちます)
いいえ。まず第一に、この設計ではアカウントのステータスを見つけるのが不便です。すべてのステータスを含むブロックがないため、前のブロックを 1 つずつたどって、アカウントの以前のステータスが含まれているかどうかを確認する必要があります。必要。
最も厄介な状況は、新しく作成したアカウントに送金する場合です。金額を追加する前に、受信アカウントのステータスを知る必要がありますが、新しく作成されたアカウントであるため、そのアカウントを見つける必要があります。 Genesis ブロックは、アカウントが新しく作成されたことを常に認識します。アカウントはシステムに保存されず、ブロックチェーンは継続的に拡張されます。