Bis heute unterstützen alle Ethereum Execution Clients den Ablauf der Teilgeschichte gemäß dem Ablauf der Geschichte in Übereinstimmung mit EIP-4444. Während die Arbeiten an der vollständigen Ablauf des Rolling History dauert, können Benutzer damit rechnen, den für einen Ethereumknoten erforderlichen Speicherplatz um 300-500 GB zu reduzieren, indem die Blockdaten vor dem Zusammenführen entfernt werden. Auf diese Weise kann ein Knoten bequem auf eine 2 TB -Festplatte passen. Informationen zu jedem bestimmten Kunden finden Sie unten.
Kettengeschichte
Per Definition ist eine Blockchain eine Kette von Blöcken, die an einem bestimmten Genesis -Punkt beginnen. Für Ethereum, das geschah auf 30. Juli 2015. Jeder Block enthält Informationen über das Protokoll selbst, dh die aktuelle Gasgrenze, eine Liste von Benutzertransaktionen und das Ergebnis dieser durch eine Quittung eingezogenen Transaktionen. Diese Daten haben viele Verwendungen:
- Die vollständige Validierung der Kette erfordert die Ausführung jedes historischen Blocks, um sicherzustellen, dass nicht nur der aktuelle Hauptzustand korrekt ist, sondern alle historischen Zustände von Genesis bis heute korrekt waren.
- Konstruktion von Indizes über den Kettenverlauf, z. B. die Verfolgung der Balanceänderungen eines bestimmten Kontos im Laufe der Zeit oder wie sich der Zustand einer bestimmten Anwendung ändert.
- Für L2s, die Transaktionen mit CallData veröffentlicht haben, müssen die Kettenhistorie ihre Kette oder Konstruktindizes vollständig validieren.
- Ein allgemeiner Beweis für Past-Operationen wie das Nachweis einer bestimmten Transaktion wurde irgendwann gesendet.
- In seltenen Fällen sind nicht-mischbare Token (NFT) -Daten. Die vorherrschende Methode zum Hosting von NFTS-Onketten besteht jedoch darin, die NFT-Daten entweder in Vertragspeichern oder in Bezug auf externe Quellen wie IPFs zu speichern.
Diese historischen Daten werden von Ethereum -Nutzern nicht regelmäßig konsumiert und dienen stattdessen anspruchsvollere Benutzer und Entwickler. Der Zugriff auf ein aktuelles Guthaben, die Ausführung eines Handels, die Kreditvermögen usw. wird nicht durch Ablauf der Geschichte unterbrochen. Die seit Genesis ruhenden Konten sind ebenfalls nicht betroffen, da der Staat für jedes Konto weiterhin aufrechterhalten wird. Es wird jedoch nur der aktuelle Zustand beibehalten. Daher ist das Gleichgewicht eines Benutzers an einem bestimmten Punkt in der Vergangenheit nicht leicht aus der Geschichte zu bestimmen. Solche Fragen erfordern eine Archivknoten mit speziellen Indizes, die in der Lage sind, vergangene Zustandswerte zu bestimmen.
Blockvalidierung im Beweis für den Beweis blockieren
Als Ethereum mit Nachweis der Arbeit gestartet wurde, war die vollständige Validierung von Genesis der Standard. Später haben Clients Snap Sync und andere ähnliche Synchronisierungsstile implementiert, bei denen Clients basierend auf der schwersten Kettenregel zum Kopf der Kette gesprungen waren, und dann alle Verträge und Konten staatlich herunterladen. Für diejenigen, die der Meinung waren, dass die schwerste Kettenregel nicht ausreichte, um die volle Integrität der Kette zu überprüfen, wurde die volle Synchronisierung beibehalten.
Mit dem Aufkommen von Proof-of-Stake und der Zusammenführung änderte sich die Synchronisierungsstrategie. Da Unterschriften im Grunde genommen keine Kosten generiert werden können, müssen die Kunden an einen kürzlich vertrauenswürdigen Kontrollpunkt verankern, auch bekannt als a Schwacher Subjektivitätskontrollpunkt. Auf diese Weise können neue Benutzer in die Kette bootet, ohne von hypothetischen Langstreckenangriffen von Validatoren ausgetrickt zu werden, die vor langer Zeit den Validator -Satz verlassen haben.
Die Einführung der Subjektivität beseitigt weiterhin die Notwendigkeit, dass Benutzer jeden Block in der Kette vollständig überprüfen müssen. Aus vielen anderen Gründen haben die Kunden eine neue Strategie der Reverse -Synchronisierung verabschiedet, bei der sie die Kette rückwärts in Richtung Genesis gehen, um die Geschichte herunterzuladen. Nachdem die meisten Clients die Kette nicht vollständig ausführen, gibt es kaum Grund, jeden Ethereum -Knoten zum Herunterladen von über 1 TB Daten zu zwingen, die nicht vom P2P -Netzwerk verwendet werden. Nach Ablauf der Geschichte führen wir eine 1-von-n-Vertrauensannahme bei, ähnlich wie bei anderen Netzwerken, dass Knoten die Geschichte über außerhalb des Protokolls abrufen können, wenn mindestens ein Unternehmen die historischen Blöcke liefert.
Das Standard -Sicherheitsmodell der Ablauf des Verlaufs ändert sich nicht vom aktuellen Status quo. Kunden haben die Kette über 5 Jahre lang nicht vollständig von Genesis validiert. Die Ausführungsschicht liefert weiterhin alle Header, die eine kryptografische Überprüfung der Kette von Genesis ermöglichen. Dies hilft Kunden, ungültige historische Daten zu akzeptieren.
Verfügbarkeit, garantiert
Bis heute hat jeder einzelne Knoten im Ethereum -Netzwerk jeden Block von Genesis zum Kopf gespeichert. Dies lieferte eine äußerst hohe Garantie dafür, dass die Geschichte jederzeit von jedem heruntergeladen werden kann. Wir glauben, dass es möglich ist, die Anzahl der Knoten zu verringern, die die gesamte Geschichte speichern und gleichzeitig eine hohe Verfügbarkeit sicherstellen. Wir erreichen dies mit den folgenden Verteilungskanälen:
- Institutionelle Anbieter – Organisationen, die bereit sind, historische Archive auf ihren eigenen Servern zu veranstalten.
- Torrent-Opt-in Erlaubnisloser und dezentrales Hosting für archivierte Geschichte.
- Peer-to-Peer-Netzwerk-Der gleiche Abrufmechanismus wie zuvor, außer dass Peers, die die Geschichte nicht speichern, die Gesamtverfügbarkeit bis zu einem gewissen Grad verwässert.
Eine Liste von Spiegeln und Torrent -Dateien finden Sie in der gepflegten Community -Dokumentation https://eth-clients.github.io/history-endpoints/.
Clientspezifische Befehle
Während diese Informationen zum Veröffentlichen auf dem neuesten Stand sind, unterliegen Befehle und Flaggen, die mit einem bestimmten Kunden verbunden sind, Änderungen. Die aktuellsten Informationen sind immer die jeweilige Dokumentation jedes Kunden.
Jeder mit Vollknoten fokussierte Client unterstützt das Ausführen ohne Vor-Merge-Daten. Der genaue Prozess hängt jedoch vom Client ab. Im Folgenden finden Sie Anweisungen zum Ausführen eines beschnittenen Knotens für jeden Ausführungs -Client. Bitte beachten Sie, dass nur Mainnet und Sepolia ein Präfix ohne Merge-Ketten haben. Daher ist das Beschneiden nur auf diesen Ketten möglich. Darüber hinaus ist das Präfix der Nicht-Merge-Kette in Sepolien gering, sodass das Beschneiden nur geringe Auswirkungen auf die Gesamtscheibengröße hat, die von jedem Kunden erforderlich ist.
Go-Ehereum
Erhältlich nach der Version V1.16.0. Vollständige Dokumentation verfügbar Hier.
Für einen vorhandenen Knoten:
- Geth anmutig schalten.
- Führen Sie den Befehl offline prune aus GETH PRUNSE-HISTORY–DATADIR =
- Starten Sie Geth erneut.
Für einen neuen Knoten:
- Verwenden Sie die Flagge -History.chain Postverge So überspringen Sie das Herunterladen der Pre-Merge-Blöcke.
Nethermind
Standardmäßig aktiviert nach der Version 1.32.2.
Die Geschichte wird nur auf einem neu synchronen Knoten entfernt. In zukünftigen Versionen wird ein automatisiertes Beschneiden hinzugefügt. Die vollständige Dokumentation ist verfügbar Hier.
Um die historische Expirienfunktion zu deaktivieren:
- Verwenden Sie die Flaggen -Sync.ancientBodiesBarrier 0–Sync.ancientreceiptsbarrier 0.
Besut
Erhältlich nach der Version 25.7.0. Vollständige Dokumentation verfügbar Hier.
Für einen vorhandenen Knoten entweder:
Offline -Pflaume
- Schließend anmutig.
- Führen Sie den Befehl offline prune aus: entu–data-path = Speicherpflüde-Pre-Merge-Blocks
- Beginnen Sie mit -Herkundig-expiry-prune
- Warten Sie, bis der gesamte Platz zurückgefordert wurde, ungefähr 24-48 Stunden.
- Entfernen Sie-History-Expiry-Prune und starten Sie Besu neu.
Online -Pflaume - Verwenden Sie die Flagge -Herkundig-expiry-prune beim Starten des Kunden.
Für einen neuen Knoten:
- Verwenden Sie die Flagge -Sync-Modus = Snap
Erigon
Erhältlich nach der Version v3.0.12
Für neue und vorhandene Knoten:
- Verwenden Sie die Flagge -Pirant Beim Starten des Kunden
Um
Erhältlich nach Version V1.5.0.
Für neue und vorhandene Knoten:
- Verwenden Sie die Flagge –Prune.Bodies.pre-Merge-Prune.Receipts.before 15537394 Flagge für Mainnet und –Prune.Bodies.pre-Merge-Prune.Receipts.before 1450409 für Sepolien.
