Wie nutzt Ethereum Bloom-Filter?

Wie es im gelben Papier heißt:

Transaktionsbeleg. Um Informationen über eine Transaktion zu verschlüsseln, für die es nützlich sein kann, einen Zero-Knowledge-Beweis oder einen Index und eine Suche zu erstellen, verschlüsseln wir eine Quittung jeder Transaktion, die bestimmte Informationen über ihre Ausführung enthält. Jede Quittung, die für die i-te Transaktion mit BR[i] bezeichnet wird, wird in einen mit einem Index versehenen Trie platziert, und die Wurzel wird im Header als He aufgezeichnet.

Die Transaktionsquittung ist ein Tupel aus vier Elementen, die den Zustand nach der Transaktion umfassen, R, das kumulative Gas, das in dem Block verwendet wird, der die Transaktionsquittung enthält, unmittelbar nachdem die Transaktion stattgefunden hat, Ru, den Satz von Protokollen, die durch die Ausführung der Transaktion erstellt wurden , Rl und der Bloom-Filter, der sich aus Informationen in diesen Protokollen zusammensetzt, Rb:

R = (R;Ru;Rb;Rl)

Kann jemand mehr Details darüber geben, wie diese Rl(Protokolle) strukturiert sind und wie die Rb(Bloom-Filter) daraus aufgebaut sind?

Ich habe einige Nachforschungen über Bloom-Filter angestellt und Broder und Mitzenmacher geben an, dass:

Überall dort, wo eine Liste oder ein Satz verwendet wird und der Speicherplatz knapp ist, sollten Sie die Verwendung eines Bloom-Filters in Betracht ziehen, wenn die Auswirkungen von Fehlalarmen abgeschwächt werden können.

Wie verhält sich das also zum rationalen Design von Ethereum?

Antworten (1)

Ereignisse im Ethereum-System müssen einfach gesucht werden, damit Anwendungen Ereignisse, einschließlich historischer Ereignisse, ohne übermäßigen Overhead filtern und anzeigen können. Gleichzeitig ist Speicherplatz teuer, daher möchten wir nicht viele doppelte Daten speichern – wie etwa die Liste der Transaktionen und die von ihnen generierten Protokolle. Um dieses Problem zu lösen, gibt es den Log-Bloom-Filter.

Wenn ein Block generiert oder verifiziert wird, werden die Adresse eines Protokollierungsvertrags und alle indizierten Felder aus den Protokollen, die durch die Ausführung dieser Transaktionen generiert wurden, zu einem Bloom-Filter hinzugefügt, der im Block-Header enthalten ist. Die eigentlichen Protokolle sind aus Platzgründen nicht in den Blockdaten enthalten.

Wenn eine Anwendung alle Protokolleinträge aus einem bestimmten Vertrag oder mit bestimmten indizierten Feldern (oder beiden) finden möchte, kann der Knoten schnell den Header jedes Blocks scannen und den Bloom-Filter überprüfen, um festzustellen, ob er möglicherweise relevante Protokolle enthält. Wenn dies der Fall ist, führt der Knoten die Transaktionen aus diesem Block erneut aus, generiert die Protokolle neu und gibt die relevanten an die Anwendung zurück.

danke =]. Wissen Sie, wo ich Material finden kann, das definiert, wie dieser Bloom-Filter erstellt wird und wie Ethereum mit Fehlalarmen umgeht?
@HenriqueBarcelos Die Erstellung des Bloom-Filters wird im Yellowpaper in und direkt nach dem von Ihnen zitierten Abschnitt beschrieben. Die Notation ist leider etwas unklar. Falsch positive Ergebnisse werden behandelt, indem die Liste der Ereignisse gefiltert wird, die durch die erneute Ausführung der Transaktionen anhand der ursprünglichen Filterkriterien generiert wurden.
Ja, das ist das Problem. Ich kann aus der Definition aus dem gelben Papier keinen Sinn ableiten. Ich war auf der Suche nach etwas "für Dummies". Wie auch immer, ich werde weiter graben. Vielen Dank!
@HenriqueBarcelos Es ist ziemlich einfach: Keccac-256 hasht sie für die Adresse und jedes der indizierten Themen und nimmt dann die ersten 11 Bits von jedem der drei niederwertigsten Bytepaare des Hashs. Dies sind die Indizes der 3 Bits im Bloomfilter, die Sie setzen sollten.
Ich habs. Aber Bloom-Filter sollen kHashes verwenden, mit k>=1, aber wenn k=1, verhält es sich genau wie ein Hash. Wenn wir nur Keccac-256 verwenden, was sind die Vorteile?
@HenriqueBarcelos k Hashes und k verschiedene Teilmengen eines größeren Hashs sind einander äquivalent, da alle Bits eines Hashs unabhängig sind.
@NickJohnson: Kennen Sie einen einfachen Code, der eine Adresse und den Bloom-Filter aus dem Blockkopf nimmt und wahr/falsch zurückgibt, wenn sich die Adresse im Bloom-Filter befindet?
@NickJohnson Sie sagen oben: "Für die Adresse und jedes der indizierten Themen hasht Keccac-256 sie und nimmt dann die ersten 11 Bits von jedem der drei niederwertigsten Bytepaare des Hashs." Ich bekomme seine bis auf den ersten Teil. Bedeutet dies, die Adresse und jedes nicht leere Thema zu verketten und sie dann zu sha3? Ich bin mir ziemlich sicher, dass es das bedeutet, aber ich dachte, ich würde fragen.
@NickJohnson Auch - wenn ich "die ersten 11 Bits der drei niederwertigsten Bytepaare nehme", was mache ich damit. Verwirrt durch 3 * 11 Bits beim Verketten wären 33 Bits - aber wohin geht das in dem 2048 Bit langen Filter? Irgendetwas muss mir fehlen.
Sie verketten sie nicht – Sie nehmen sie einzeln, hashen sie und fügen sie in den Bloom-Filter ein. Verwenden Sie dann die 11 LSBs des Ergebnisses als Index für den Bloomfilter.
Werden relevante Protokolle nicht unter jedem Block ohne Ausführung heruntergeladen (Miner haben bereits die Ausgabe der Tx-Ergebnisse generiert)? Wird Bloom Filer auch für andere Versuche (Status, Transaktion und Quittung) verwendet? @ NickJohnson