Verweisen Sie auf ein längst vergessenes Konto

Im Etherem-Blog

Vitalik sagt: "Aber wir speichern keine Geschichte, die älter als 5000 Blöcke ist.".

1) Ist zu verstehen, dass der Status Trie nicht den Status von Konten enthält, die während der letzten 5000 Blöcke nicht verwendet wurden?

2) Nehmen wir an, ein Typ erwacht nach 50 Jahren aus einem Winterschlaf und möchte eine Transaktion durchführen, die auf einen Block verweist, der vor Jahren passiert ist. Unter Berücksichtigung aller aktuellen Blockchain-Pruning-Algorithmen, die in Ethereum implementiert sind oder bald implementiert werden sollen; Wie würde das Protokoll darüber gehen? Ich nehme an, die meisten der typischen Full Nodes würden nicht einmal die Blöcke enthalten, die Transaktionen enthalten, die dieses bestimmte Konto auf ihren Festplatten erwähnen (gibt es noch einmal irgendwelche Blockchain- (nicht den Trie State) Pruning-Algorithmen, die gerade vorhanden sind?) Wahrscheinlich wäre es enthalten einige der Archivknoten. Wie würde das Protokoll darüber gehen?

Die Frage erstreckt sich also ein wenig über die Architektur von Ethereum selbst (es deutet darauf hin, dass wir tatsächlich einige Arten von Full-Nodes haben, solche, die alle Daten speichern, und andere, die sich entschieden haben, einige Pruning-Algorithmen zu verwenden.) Nicht, dass es die Kryptografie bedroht Sicherheit, da die jüngsten Hashes ausreichen würden, um zu überprüfen, ob die vor 50 Jahren platzierten korrekt sind, aber dazu müssten alle Blöcke erneut überprüft werden, sobald wir sie aus dem Zustand Trie gelöscht hätten. Eine andere Option wäre, einem Archivierungsknoten sofort zu VERTRAUEN, aber dann nicht die kryptografische Sicherheit, ABER die dezentrale Natur der Dienste leidet stark.

Neugierig bin ich.

Antworten (1)

  1. Das ist falsch. Ich denke, die Trennung besteht darin, dass der Block nicht nur Änderungen am Zustand enthält, sondern auch die Zustandswurzel selbst, die unter Verwendung des gesamten aktuellen Zustands generiert wird. Im Wesentlichen bedeutet dies, dass für die letzten 5000 Blöcke der gesamte Zustand für jeden dieser Blöcke gespeichert wird, aber für Blöcke davor verworfen wird. Sie haben also den Status jedes Kontos in den Blöcken n bis n-5000, aber nicht davor.

  2. Siehe auch #1. Die Person hätte keine Probleme, da ihr Konto im aktuellen Zustand noch vorhanden wäre. Ich bin mir jedoch nicht ganz sicher, was Sie mit "Verweisen auf einen Block, der vor Jahren passiert ist" meinen. Sie referenzieren keinen Block, wenn Sie eine Transaktion durchführen. Sie könnten jedoch verwirrt sein, da die Ethereum-Blockchain in 10 Jahren mit Sharding, Plasma, Casper usw. wahrscheinlich ziemlich anders aussehen wird.

Ich weiß, dass jeder Block eine Zustandswurzel enthält. Blöcke enthalten Transaktionen, die den aktuellen Zustand ändern/aktualisieren. Das ist klar.
Ich finde, was du geschrieben hast, ist weitgehend falsch. Es schlägt vor, dass Ethereum die gesamte Kopie eines Trie für jeden der letzten 5000 Blöcke speichert, während die Blogs und die Logik von Vitalik vorschlagen, dass nicht modifizierte Knoten einfach in der neuen Instanz des Trie referenziert werden.
Mein einziges Problem ist; Wie verarbeitet das Netzwerk eine Transaktion, die auf ein Konto verweist, dessen Status nicht mehr Teil des State Trie ist. Soweit ich weiß, ist es nach 5000 Blöcken nicht mehr Teil des State Trie, wurde beschnitten und muss jetzt aus dem Transaktionsverlauf neu berechnet werden. Falsch?
Es muss nicht für jeden der 5000 Blöcke eine vollständige Kopie des Statustrie gespeichert werden. Viele der Daten sind unverändert, werden also nicht neu gespeichert. Aber die Staatswurzel ist der Merkle-Patricia-Baum des gesamten Staates. Es speichert immer noch den vollständigen Zustand der letzten 5000 Blöcke, obwohl vieles davon in diesen Blöcken unverändert ist und auf den ältesten Block verweist, für den der Zustand noch gespeichert ist. Es ist nicht wirklich ein Verweis auf den alten Block.
Zum Beispiel: Ein Vertrag, der von Block 1 zu Block 2 und zu Block 3 unverändert ist, hat denselben Hash, sodass der Status dieses Vertrags nur einmal in der Datenbank gespeichert wird und alle Lookups der Hashes auf dieselben Daten verweisen.
Auch dies bedeutet nicht, dass Daten, die sich in den letzten 5000 Blöcken nicht geändert haben, bereinigt werden. Es bedeutet nur, dass veraltete Zustände (z. B. der Saldo Ihrer Adresse vor 6000 Blöcken, der jetzt einen anderen Saldo hat) verworfen werden.
Nehmen wir an, wir haben einen sehr großen Staat Trie.Now. Während der nächsten 5000 Blöcke führen wir Transaktionen nur zwischen zwei Konten durch. Der Algorithmus aktualisiert ständig die Salden des Kontos (indem er neue Knoten zum Statustrie hinzufügt, die auf die übergeordneten Knoten der vergangenen Zustände der beiden Konten verweisen). Dies geht für 5000 Blöcke so weiter. Jetzt. Nachdem wir mehr als 5000 Blöcke haben, beginnt die Beschneidung. Der Großteil des Staates Trie befindet sich jetzt im 5001. Block. werden alle diese Zustände gelöscht?
Ich bin mir nicht ganz sicher, was du sagst. Der Zustand im aktuellen Block ist immer der aktuelle Zustand des Gesamtsystems. Es enthält keine veralteten Zustände, sondern nur die aktuellsten Zustände der Konten. Die Kontenstände bei n-5001 werden nur dann in der Datenbank gespeichert, wenn sie noch relevant sind, zB wenn der Kontostand noch stimmt. Wenn es nicht mehr genau ist, wird es beschnitten.
Vielen Dank für den Versuch zu helfen. Eigentlich waren mein Beispiel und meine Frage sehr spezifisch. github.com/ethereum/go-ethereum/pull/2111 Wir haben nicht erwähnt, dass der ursprüngliche Vorschlag von Vitalik das Zählen beinhaltete, um Probleme wie dieses zu lösen, UND vor allem, dass der beschriebene Algorithmus es nie geschafft hat, implementiert zu werden. Irgendwelche Ideen, was sind dann die aktuellen Prunning-Algorithmen?