Ethereum Merkle Tree Erklärung

Hier ist mein grundlegendes Verständnis darüber, wie Ethereum Transaktionen speichert

  1. Für jede Transaktion wird ein Hash generiert
  2. Dann werden Paare ausgewählt und für jedes Paar ein Hash generiert
  3. Auf diese Weise wird der letzte verbleibende Hash zur Wurzel
  4. Der Block-Header enthält drei Merkle-Bäume
    • Um den Staat zu erhalten
    • Zur Aufrechterhaltung der Transaktionen
    • Um die Belege zu pflegen
  5. Jeder Block bezieht sich auf den Hash des vorherigen Blocks
  6. Ich füge das sehr verbreitete Diagramm bei, das diese Struktur zeigt

Geben Sie hier die Bildbeschreibung ein

Fragen:
1. Die Zustandswurzel von Block 180994 zeigt auf das erste linke Kind von Block 180993 der Zustandswurzel. Was bedeutet es und warum wird es benötigt?
2. Nehmen wir ein Beispiel
– Der erste Block 180993 hat eine Transaktion, bei der Konto 98 30 Ether an Konto 100
weitergibt – Der zweite Block 180994 hat eine Transaktion, bei der Konto 99 20 Ether an Konto 100 weitergibt

Wie wird sich dies im Baum widerspiegeln? Wird es eine ähnliche Art von Cross-Mapping von Merkle-Bäumen geben, wie im Diagramm gezeigt? Bitte erkläre

Mehr Details hinzugefügt

Geben Sie hier die Bildbeschreibung ein

Antworten (3)

Der Staat hat die Informationen aller Konten in der Blockchain, sie werden nicht in jedem Block gespeichert. Der Zustand wird erzeugt, indem jeder Block seit dem Entstehungsblock verarbeitet wird. Jeder Block ändert nur Teile des Zustands.

Wie der Zustand generiert wird, ist im Yellow Paper (pdf) definiert . Es ist so definiert, dass es in jeder Programmiersprache implementiert werden kann, und alle diese Implementierungen erzeugen dieselbe Darstellung.

  1. Dies bedeutet, dass die linke Seite in Block 180994 nicht geändert wurde. Es ist nur eine Darstellung, denken Sie daran, dass nicht der gesamte Status gespeichert wird, sondern nur der Root-Hash .

  2. Es gibt einen Artikel über Merkle Trees in Ethereum , ich kann es wahrscheinlich nicht besser machen. Die Grundidee von Merkle-Bäumen besteht darin, dass für eine einzelne Operation nur die minimale Anzahl von Knoten geändert wird, um den Root-Hash neu zu berechnen.

Danke für deine Antwort! Hier ist mein Verständnis, bitte teilen Sie Ihre Ansichten. 1. Jeder Knoten verwaltet insgesamt drei Bäume. Jeder Block bezieht sich auf eine der Wurzeln in diesem ganzen Baum. 2. Basierend auf der abgebildeten Wurzel könnte der Zustand in diesem Stadium gefunden werden.
3. Nehmen wir an, 180994 hat die Transaktion (A->B 50 eth). Das heißt, wenn ich mich auf Block 180994 beziehe, kann ich basierend auf dem Status-Root-Hash feststellen, dass der Status von Konto A 50 eth und der Kontostatus von B 150 eth ist (da der Anfangsstatus von B 100 war). 4. Wenn ich mich auf 180993 mit einer Transaktion beziehe, bei der die Summe von A 100 eth wird, dann kann ich basierend auf dem Status-Root-Hash feststellen, dass der Status von Konto A 100 eth ist
1) Es wird nur der Zustandsbaum benötigt. Die Transaktions- und Quittungsbäume sollen aus den Blockdaten aufgebaut werden. Es wird nur verwendet, um den Block zu validieren. Es ist notwendig, sie aufzubewahren, da sie nicht wiederverwendet werden. 2. Ja, wenn Ihr Knoten den gesamten Zustandsverlauf speichert, können Sie den Zustand an jedem Punkt des Verlaufs abrufen. Aber einige Knoten können den alten Verlauf beschneiden. 4) y 5) Der Staat zeigt nur den Endsaldo an. Für Block 180993 A: 100, B: 100 und für Block 180994 A: 50, B: 150.
Danke für deine Antwort! Wollen Sie damit sagen, dass alle Transaktions- und Quittungsbäume im Block selbst gespeichert sind und nicht nur ihr Root-Hash? Können Sie sich auch meine andere Frage ansehen, dh "Wie der Ethereum-Transaktionsbaum gebildet wird" und Ihre Ansichten in denselben Zeilen teilen
Ja, jeder Block enthält die vollständigen Transaktionen. Der txs-Root-Hash soll schnell validieren, dass die Transaktionen innerhalb des Blocks nicht geändert wurden.

Ethereum soll eine kontobasierte Blockchain haben. Der Zustand wird nicht direkt in jedem Block gespeichert.

Um ein besseres konzeptionelles Verständnis aufzubauen, können wir sagen, dass sich alle Kontozustände lokal auf dem Ethereum-Knoten in Form von „Statusdaten“ befinden. Dies ist aus Leistungsgründen üblich und es wird davon ausgegangen, dass es in einem Merkle-Patricia-Baum gespeichert wird, aber die Protokollspezifikation erfordert dies nicht. Gelbes Papier besagt,

Der Weltzustand (Zustand) ist eine Zuordnung zwischen Adressen (160-Bit- Identifikatoren) und Kontozuständen (eine als RLP serialisierte Datenstruktur, siehe Anhang B). Obwohl nicht in der Blockchain gespeichert, wird davon ausgegangen , dass die Implementierung diese Zuordnung in einem modifizierten Merkle-Patricia-Baum beibehält

Wir haben es also neben der Blockchain selbst mit einem „ Second State “ zu tun. Zustandsdaten können als implizit bezeichnet werden, d. h. sie können aus den tatsächlichen Blockchain-Daten berechnet werden. Transaktionen enthalten alle geeigneten Felder, um neue Zustandsdaten zu ermitteln. Im Gegensatz zu Bitcoin enthalten Ethereum-Blöcke sowohl eine Kopie der Transaktionsliste als auch den Merkle-Root-Hash des gesamten Zustandsbaums.

Entnommen aus dem Yellow Paper von Dr. Gavin Wood:

Ethereum Runtime Environment: (auch bekannt als ERE) Die Umgebung, die einem autonomen Objekt bereitgestellt wird, das in der EVM ausgeführt wird. Beinhaltet die EVM, aber auch die Struktur des Weltzustands, auf den sich die EVM für bestimmte I/OAnweisungen stützt, einschließlich CALL& CREATE.

Abschließend wird die Speicherung des Status von der Client-Implementierung des Ethereum-Protokolls verwaltet. Ich habe ein (zu stark vereinfachtes) Bild angehängt, das ich erstellt habe und das den Zustandsübergang vor und nach dem Senden einer Transaktion zwischen zwei Parteien zeigen soll.

Bild, das ich erstellt habe, um das konzeptionelle Modell des Zustandsübergangs zu verstehenWas das Verständnis des Merkle-Patricia-Baums betrifft, würde ich Sie in die Richtung jedes Artikels verweisen, der sich mit Radix-Bäumen befasst

Erstmal danke für deine ausführliche Antwort! Habe gerade mein Diagramm etwas umstrukturiert. Auflisten meines Verständnisses und meiner Fragen. Bitte teilen Sie Ihre Ansichten darüber mit. Q1. Was ich bekomme, ist, dass der Block-Header nur die Root-Hashes für jeden Baum speichert, dh Zustand/Transaktion/Empfang. Der eigentliche Baum ist ein einzelner Baum mit verschiedenen Wurzeln, wenn er aufwächst. Q2. Die Zustandswurzel dieses Blocks zeigt auf eine Wurzel, die Ihnen den Zustand (dh an diesem Punkt) aller Konten geben kann, die an diesen Transaktionen beteiligt sind, die in dem Block vorhanden sind.
Q3. Basierend auf dem neu hinzugefügten Bild kann ich also, wenn ich mich auf Block 180993 beziehe (vorausgesetzt, das Konto von A erhält Ether und damit insgesamt 100), mithilfe des State-Root-Hashs feststellen, dass der Status von Konto A 100 ist, der für diesen Block spezifisch ist. Q4. Nehmen wir an, 180994 hat die Transaktion (A bis B 50 eth). Das heißt, wenn ich mich auf Block 180994 beziehe, kann ich basierend auf dem Status-Root-Hash feststellen, dass der Status von Konto A 50 eth und der Kontostatus von B 150 eth spezifisch für diesen Block ist. Q5. In der Hoffnung, dass die Zustands-/Transaktions-/Empfangsbäume von jedem Client auf seinen jeweiligen Knoten gepflegt werden
F6. Aber nehmen wir an, Knoten A (dh mit Konto A) ist ausgefallen, dennoch kann ein Anruf von Knoten B den Kontostand von A ermitteln, möglicherweise durch Verwendung des Transaktionsbaums und Aufsummieren aller Kontoübertragungen von/auf das Konto von A. Q7. Wenn, sagen wir, Knoten A aktiv war, dann wird Knoten A direkt abgefragt, wenn es einen Anruf gab, um das Guthaben von A zu finden. Glaubst du, dass das nie passiert, es versucht nur, den Zustands-Root-Hash aus dem letzten Block herauszufinden und dann den Zustand von A zu finden, der hier 50 eth ist?

Stehlen Sie dieses Diagramm von Badr in dieser fantastischen Antwort . Wo werden die Zustandsdaten gespeichert?

"Block 180994 zeigt auf das erste linke Kind von Block 180993" bedeutet einfach, dass das erste linke Kind mutiert wurde . Wir könnten uns also einfach auf denselben Hash beziehen. Beachten Sie, dass dieser Ansatz rekursiv angewendet wird . Und deshalb sehen wir viele Verweise auf den vorherigen Block.

Geben Sie hier die Bildbeschreibung ein

Ethereum Merkle Tree Erklärung
AntwortenHierDatenschutz-Bestimmungen1y, 0v