EIP-2935 erklärt: Historische Ethereum-Blockhashes, Ringpuffer und Risiken
EIP-2935 löst ein unscheinbares, aber grundlegendes Problem der Ethereum-Infrastruktur: Smart Contracts können standardmässig nur einen begrenzten Ausschnitt historischer Blockhashes direkt über den Opcode BLOCKHASH abrufen. Wer weiter zurückliegende Blockinformationen für überprüfbare Anwendungen benötigt, muss andere Wege finden. Der Standard schafft dafür einen besonderen Systemvertrag, der einen längeren, jedoch weiterhin begrenzten Zeitraum abdeckt. Dieser Artikel erklärt die genaue Funktionsweise, den Unterschied zum bisherigen Opcode, die Bedeutung für Rollups und mögliche Sicherheitsfehler. Entscheidend ist die Trennung zwischen einem kryptografischen Blockhash und der vollständigen Geschichte einer Blockchain. Ein Hash ist ein kompakter Fingerabdruck eines Blockheaders; er enthält weder die vollständigen Transaktionen noch automatisch einen Beweis für einen bestimmten wirtschaftlichen Sachverhalt. EIP-2935 ist deshalb eine technische Infrastrukturverbesserung und weder ein neuer Coin noch eine zusätzliche Renditequelle.
Warum historische Blockhashes wichtig sind
Ethereum verarbeitet Transaktionen in Blöcken. Jeder Block verweist kryptografisch auf seinen Vorgänger, wodurch eine Kette entsteht. Ein Blockhash identifiziert einen bestimmten Blockheader und ist für viele Überprüfungen nützlich. Smart Contracts benötigen solche Werte beispielsweise, um Aussagen über jüngere Vorfahren der aktuellen Kette zu überprüfen. Ohne standardisierte Verfügbarkeit müssen Entwickler zusätzliche Vertrauensannahmen treffen, eigene Archive betreiben oder komplexe Beweise einreichen. Der bisherige BLOCKHASH-Opcode bietet ein Fenster von 256 vorherigen Blöcken. Für zahlreiche praktische Abläufe kann diese Spanne knapp sein, etwa wenn eine Anwendung erst nach mehreren Stunden eine Überprüfung durchführen möchte. EIP-2935 erweitert nicht heimlich diesen Opcode, sondern bietet einen separaten Zugang über einen Systemvertrag. Gerade diese Unterscheidung verhindert falsche Erwartungen an bestehende Smart Contracts.
Was EIP-2935 tatsächlich festlegt
Die offizielle Spezifikation trägt den Titel Serve historical block hashes from state und ist ein Core-Ethereum-Improvement-Proposal. Sie definiert einen Speicher mit 8'191 Einträgen, in dem die Hashes jüngerer Vorfahren abgelegt werden. Die Schreiboperation wird beim Verarbeiten neuer Blöcke vom Protokoll ausgelöst. Ein normaler Nutzer kann die Historie nicht nach Belieben verändern. Lesende Smart Contracts greifen auf den vorgesehenen Vertrag zu und übergeben die gesuchte Blocknummer. Ausserhalb des erlaubten Bereichs wird die Anfrage abgewiesen. Die Speichergrenze ist bewusst endlich: Ein unbegrenzt wachsender Datensatz würde die Zustandslast des Netzwerks erhöhen. Das Verfahren schafft also einen Kompromiss zwischen Zugänglichkeit und Ressourcenbedarf. Die Spezifikation ist unter eips.ethereum.org/EIPS/eip-2935 öffentlich dokumentiert; technische Aussagen in diesem Beitrag beziehen sich auf diese Primärquelle.
BLOCKHASH bleibt unverändert
Ein häufiger Irrtum lautet, dass nach EIP-2935 jede Anwendung den Opcode BLOCKHASH plötzlich für 8'191 Blöcke verwenden könne. Das ist falsch. Die Semantik und das 256-Blöcke-Fenster des Opcodes bleiben bestehen. Wer das grössere Fenster benötigt, muss den speziellen History-Vertrag ausdrücklich aufrufen. Bereits vorhandene Verträge ändern ihr Verhalten daher nicht automatisch. Diese Rückwärtskompatibilität ist wichtig, weil Programme auf festgelegte Grenzen und Fehlerfälle angewiesen sein können. Ein unerwartet veränderter Opcode könnte Annahmen über Verfügbarkeit, Gebühren oder Sicherheitsprüfungen brechen. Für Entwickler folgt daraus eine klare Aufgabe: Prüfe, welche Schnittstelle Dein Programm nutzt. Ein Aufruf von BLOCKHASH und ein Aufruf des History-Vertrags sind nicht austauschbar, obwohl beide auf Hashes von Ethereum-Blöcken Bezug nehmen.
Die Adresse des History-Vertrags
Die Spezifikation nennt als History-Speicheradresse 0x0000F90827F1C53a10cb7A02335B175320002935. Es handelt sich um eine protokollseitig festgelegte Adresse, nicht um eine gewöhnliche Handelsplattform oder eine Wallet für Einzahlungen. Die Schreiboperation erfolgt mit der besonderen Systemadresse 0xfffffffffffffffffffffffffffffffffffffffe als Aufrufer. Dadurch kann der Vertrag zwischen autorisiertem Schreiben und normalem Lesen unterscheiden. Nutzer sollten solche technischen Adressen niemals als Zahlungsziel interpretieren. Auch die Existenz einer Adresse allein beweist nicht, dass eine beliebige Blockchain denselben Standard aktiviert hat. Wer Software auf mehreren Netzwerken betreibt, muss die jeweilige Chain-Konfiguration und Aktivierung kontrollieren. Ein Entwickler sollte den Quellstandard und die tatsächliche Netzwerkimplementierung vergleichen, statt nur auf eine vertraut aussehende Hexadezimaladresse zu vertrauen.
So entsteht der Eintrag für einen Block
Bei der Verarbeitung eines neuen Blocks schreibt das Protokoll den Hash des Elternblocks in den History-Speicher. Die Operation findet vor der normalen Verarbeitung der Transaktionen des neuen Blocks statt. Damit ist die Historie an den regulären Zustandsübergang gekoppelt. Der Systemaufruf ist keine frei wählbare Nutzertransaktion und belastet nicht einfach das normale Gasbudget des Blocks. Die Spezifikation sieht dafür einen eigenen technischen Ablauf vor. Der gespeicherte Wert ist der Hash des Elternblocks, nicht der Hash eines erst künftig bekannten Blocks. Diese zeitliche Reihenfolge ist wesentlich: Ein Vertrag darf nicht so programmiert werden, als könnte er auf Informationen aus der Zukunft zugreifen. Bei Tests müssen Entwickler die aktuelle Blocknummer, den abgelegten Vorgängerhash und den Zeitpunkt des Zugriffs auseinanderhalten.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten.
Bitcoin mit Relai kaufen: Gutscheincode AUSWANDERNSCHWEIZ. Relai bietet keine der hier besprochenen Altcoins an.
Ringpuffer: Weshalb 8'191 Plätze genügen müssen
Ein Ringpuffer nutzt eine feste Zahl von Speicherpositionen wieder. EIP-2935 bestimmt die Position anhand der Blocknummer modulo 8'191. Wenn neue Blöcke hinzukommen, werden alte Werte schrittweise überschrieben. Das hält den Speicherbedarf grundsätzlich begrenzt. Beispiel: Für die Blocknummer 20'000 ergibt die Division durch 8'191 den Rest 3'618. Der entsprechende Speicherplatz kann später erneut verwendet werden, sobald die Blocknummer um 8'191 weitergestiegen ist. Die Rechnung beschreibt das Prinzip und ist keine Aufforderung, Speicherpositionen ohne zusätzliche Gültigkeitsprüfung direkt auszulesen. Der Vertrag kontrolliert vielmehr, ob die angefragte Nummer im zulässigen historischen Fenster liegt. Ein alter Hash bleibt deshalb nicht dauerhaft über diese Schnittstelle verfügbar. Für Langzeitarchive braucht es andere Lösungen.
Zeitfenster richtig berechnen
8'191 Blöcke sind keine feste Anzahl Stunden. Die tatsächliche Zeitspanne hängt von der Blockproduktion des jeweiligen Netzwerks ab. Bei einer angenommenen durchschnittlichen Blockzeit von zwölf Sekunden entsprächen 8'191 Blöcke rechnerisch 98'292 Sekunden, also rund 27 Stunden und 18 Minuten. Das ist eine Modellrechnung, keine Garantie für einen konkreten Zeitraum und keine aktuelle Netzwerkmessung. Bei zehn Sekunden pro Block wären es nur rund 22 Stunden und 45 Minuten. Wer Fristen für einen Smart Contract festlegt, sollte deshalb Blocknummern und reale Uhrzeit nicht verwechseln. Besonders bei Verzögerungen, Netzwerkausfällen oder abweichenden Chain-Konfigurationen kann die Annahme einer starren Zeitdauer gefährlich werden. Prüfe immer, welche Frist Dein konkretes Protokoll tatsächlich verwendet.
Der Unterschied zwischen Daten und Beweisen
Ein Blockhash ist ein kryptografischer Anker, aber nicht bereits der vollständige Beweis für eine Transaktion. Um nachzuweisen, dass ein bestimmter Eintrag zu einem Block gehört, können zusätzliche Daten und kryptografische Nachweispfade erforderlich sein. Eine Anwendung, die nur den Blockhash aus dem History-Vertrag liest, weiss zunächst lediglich, welchen Hash das Protokoll für die angefragte Blocknummer gespeichert hat. Sie kennt damit nicht automatisch alle Transaktionen, Logs oder Kontostände dieses Blocks. Diese Trennung ist zentral für sichere Cross-Chain- und Rollup-Anwendungen. Wer von einer verifizierten Übertragung spricht, muss präzisieren, welcher Sachverhalt geprüft wird, welche Daten ein externer Akteur liefert und welche kryptografischen Annahmen der Smart Contract tatsächlich kontrolliert.
Warum Statelessness eine Rolle spielt
Ein langfristiges Ziel der Ethereum-Entwicklung ist, dass die Validierung nicht immer einen vollständigen lokalen Zustand voraussetzen muss. Sogenannte stateless oder zustandsarme Verfahren verwenden zusätzliche Beweisdaten, häufig als Witness bezeichnet. Historische Blockhashes müssen in solchen Modellen zuverlässig erreichbar sein, wenn sie für die Ausführung erforderlich sind. EIP-2935 verankert die jüngere Historie deshalb im Ethereum-Zustand, anstatt sie ausschliesslich als implizite Information des Clients zu behandeln. Das macht die betreffenden Werte grundsätzlich besser in zustandsbasierte Nachweismechanismen integrierbar. Daraus folgt jedoch nicht, dass Ethereum allein durch diesen Standard vollständig stateless geworden wäre. Weitere Änderungen an Datenstrukturen, Clients und Beweisverfahren sind eigenständige technische Herausforderungen. Eine einzelne EIP sollte niemals als Lösung aller Skalierungsprobleme dargestellt werden.
Anwendungen für Rollups
Rollups bündeln Transaktionen und verlagern einen Teil ihrer Verarbeitung von der Ethereum-Hauptkette. Für bestimmte Prüfungen kann es hilfreich sein, historische Blockhashes aus dem Zustand abrufen zu können. Das längere Fenster eröffnet zusätzliche Gestaltungsmöglichkeiten, etwa bei zeitlich verzögerten Nachweisen. Trotzdem ersetzt EIP-2935 weder ein vollständiges Rollup-Protokoll noch die jeweilige Betrugs- oder Gültigkeitsprüfung. Auch der Sequencer, die Datenverfügbarkeit und die Regeln für Auszahlungen bleiben eigenständige Risikofaktoren. Eine Anwendung kann einen korrekt gespeicherten Blockhash verwenden und dennoch durch fehlerhafte Vertragslogik angreifbar sein. Bei der Beurteilung eines Rollups solltest Du deshalb nicht nur die Existenz des History-Vertrags prüfen, sondern auch dessen tatsächliche Einbindung in die Sicherheitsarchitektur und die zugrunde liegenden Vertrauensannahmen.
Bedeutung für Bridges
Cross-Chain-Bridges verbinden unterschiedliche Netzwerke, häufig über Nachrichten, Vermögenswertrepräsentationen oder gesperrte Sicherheiten. Ein historischer Ethereum-Blockhash kann dabei ein nützlicher Ausgangspunkt für bestimmte Nachweise sein. Er garantiert aber nicht, dass die andere Blockchain korrekt funktioniert oder dass ein Bridge-Vertrag ausreichend abgesichert ist. Eine Bridge kann trotz korrekter Hashprüfung kompromittierte Administratorenschlüssel, fehlerhafte Signaturregeln oder eine gefährliche Upgrade-Funktion besitzen. Besonders kritisch sind Systeme, die zusätzliche Daten von zentralisierten Relayern akzeptieren. EIP-2935 kann in einem durchdachten Nachweisverfahren helfen, ist jedoch kein universeller Schutz gegen Bridge-Hacks. Prüfe bei jeder Anwendung, welche Teile tatsächlich on-chain verifiziert werden und welche Aussagen lediglich von externen Parteien stammen.
Sicherheit: Reorganisationen und Finalität
Blockhashes müssen im Zusammenhang mit Kettenreorganisationen betrachtet werden. Ein jüngerer Block kann unter bestimmten Umständen durch einen konkurrierenden Block ersetzt werden, bevor ausreichend Finalität erreicht ist. Eine Anwendung sollte deshalb nicht allein aus der Existenz eines gespeicherten Hashes auf unumkehrbare wirtschaftliche Sicherheit schliessen. Wie lange gewartet werden muss, hängt vom Konsensmechanismus, vom konkreten Netzwerk und vom Sicherheitsziel ab. Bei Ethereum ist zudem zwischen der Verfügbarkeit eines Hashes und der Finalität eines Blocks zu unterscheiden. EIP-2935 verändert nicht automatisch die Konsensregeln. Ein Entwickler muss weiterhin entscheiden, wie viele Bestätigungen oder welche Finalitätsnachweise eine Auszahlung erfordert. Besonders bei grossen Beträgen kann eine falsche Annahme über Finalität erhebliche Verluste verursachen.
Sicherheit: Falsche Blocknummern
Eine typische Fehlerquelle ist die Verwechslung der aktuellen Blocknummer mit der Nummer des Elternblocks. EIP-2935 speichert beim neuen Block den Hash des vorherigen Blocks. Der lesende Vertrag erwartet eine Blocknummer in einem klar definierten zulässigen Bereich. Anfragen ausserhalb dieses Bereichs schlagen fehl. Programme sollten solche Fehler nicht unbemerkt als gültigen Nullwert interpretieren. Ebenso gefährlich ist eine falsche Umrechnung zwischen Blocknummer, Speicherindex und Zeitstempel. Eine robuste Implementierung testet Grenzwerte ausdrücklich: den jüngsten zulässigen Vorfahren, den ältesten noch verfügbaren Eintrag, eine Nummer knapp ausserhalb des Fensters und fehlerhaft formatierte Eingaben. Die Spezifikation fordert für den Leseaufruf eine 32-Byte-Eingabe. Eine sorgfältige Fehlerbehandlung ist daher wichtiger als eine vermeintlich elegante Abkürzung.
Sicherheit: Alte Werte werden überschrieben
Ein Ringpuffer ist absichtlich kein dauerhaftes Archiv. Sobald der Abstand zur aktuellen Blocknummer zu gross wird, kann der zuvor gespeicherte Wert überschrieben sein. Das ist kein Datenverlust durch einen Angriff, sondern die vorgesehene Funktionsweise. Anwendungen, die Beweise erst Wochen später prüfen möchten, dürfen sich deshalb nicht allein auf EIP-2935 verlassen. Sie brauchen eine geeignete alternative Speicherung oder eine andere überprüfbare Beweiskonstruktion. Ebenso wichtig ist, dass Entwickler keine beliebigen historischen Nummern akzeptieren, ohne den zulässigen Bereich zu kontrollieren. Die Lesefunktion des Systemvertrags setzt diese Grenze bereits durch, aber die aufrufende Anwendung muss ihre Geschäftslogik ebenfalls darauf abstimmen. Eine technisch erfolgreiche Transaktion bedeutet nicht automatisch, dass die fachliche Aussage korrekt ist.
Gasgebühren und Kosten
Die protokollseitige Aktualisierung des History-Vertrags ist von normalen Nutzertransaktionen zu unterscheiden. Laut EIP zählt der Systemaufruf nicht gegen das gewöhnliche Blockgaslimit. Das bedeutet nicht, dass jeder Lesezugriff für Nutzer kostenlos wäre. Ein Smart Contract, der den History-Vertrag aufruft, unterliegt den üblichen Regeln der EVM-Ausführung und kann Gas verbrauchen. Die genaue Gebühr hängt von Netzwerkzustand, Aufruf und weiterer Vertragslogik ab; eine feste CHF- oder ETH-Zahl wäre ohne aktuelle Messung irreführend. Die Spezifikation erläutert ausserdem, dass die Systemaktualisierung die betreffenden Speicherplätze nicht für spätere Nutzeraufrufe vorwärmt. Wer Anwendungen optimiert, sollte daher echte Transaktionssimulationen und Gasprofile verwenden, statt allein aus dem Wort Systemvertrag auf Gebührenfreiheit zu schliessen.
EIP-2935 gegenüber EIP-4788
Beide Standards verwenden protokollseitige Systemoperationen und begrenzte Historienpuffer, erfüllen jedoch unterschiedliche Aufgaben. EIP-4788 stellt Beacon-Block-Roots aus der Konsensschicht für die Ausführungsschicht bereit. EIP-2935 bezieht sich dagegen auf historische Hashes von Execution-Blöcken. Diese Daten sind nicht identisch und dürfen in einem Smart Contract nicht miteinander verwechselt werden. Die Nähe der beiden Vorschläge liegt vor allem in der technischen Idee, bislang schwer zugängliche Konsens- beziehungsweise Historieninformationen über definierte Verträge verfügbar zu machen. Für Staking-Protokolle kann EIP-4788 besonders relevant sein; für die Prüfung jüngerer Execution-Vorfahren ist EIP-2935 die passendere Schnittstelle. Die Entscheidung muss anhand des benötigten Nachweises erfolgen, nicht anhand der ähnlich klingenden Bezeichnungen.
EIP-2935 gegenüber externen Datenanbietern
Ein Blockchain-Explorer oder ein RPC-Dienst kann historische Daten komfortabel bereitstellen. Solche Dienste sind praktisch, ersetzen aber nicht in jeder Situation eine vertrauensminimierte Prüfung innerhalb eines Smart Contracts. Wer eine API-Antwort in eine Anwendung übernimmt, muss berücksichtigen, ob der Anbieter ausfallen, falsche Daten liefern oder Anfragen einschränken kann. EIP-2935 ermöglicht für sein begrenztes Fenster einen Zugriff über den Ethereum-Zustand selbst. Das kann zusätzliche externe Abhängigkeiten reduzieren, jedoch nur für den vorgesehenen Datentyp und Zeitraum. Vollständige historische Transaktionen, detaillierte Logs und beliebige alte Zustände werden dadurch nicht automatisch verfügbar. Ein sinnvolles System kombiniert bei Bedarf Archivdienste für Recherche mit kryptografisch überprüfbaren Mechanismen für sicherheitskritische Entscheidungen.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten.
Praxisbeispiel für eine zeitverzögerte Prüfung
Stell Dir vor, ein Smart Contract soll eine Aussage über einen Ethereum-Block überprüfen, der 1'000 Blöcke zurückliegt. Der klassische BLOCKHASH-Opcode reicht dafür nicht aus, weil sein Fenster nur 256 vorherige Blöcke umfasst. Liegt die Blocknummer innerhalb des EIP-2935-Fensters, kann der Vertrag den entsprechenden Hash über den History-Vertrag abfragen. Anschliessend muss die Anwendung mit zusätzlichen Daten nachweisen, dass die gewünschte Aussage tatsächlich zu diesem Block gehört. Der Hash allein verrät beispielsweise nicht, ob eine bestimmte Zahlung stattgefunden hat. Wenn die Prüfung erst nach 9'000 weiteren Blöcken erfolgt, liegt der ursprünglich gewünschte Block ausserhalb des 8'191er-Fensters. Die Anwendung muss dann einen anderen verlässlichen Nachweismechanismus vorsehen. Das Beispiel illustriert sowohl den Nutzen als auch die Grenzen des Standards.
Prüfliste für Entwickler
Bevor Du EIP-2935 in produktive Software integrierst, kläre zunächst, ob das Zielnetzwerk die Regel tatsächlich aktiviert hat. Prüfe anschliessend die korrekte Vertragsadresse und die erwartete Eingabekodierung. Teste die Grenzen des historischen Fensters und den Umgang mit Reverts. Definiere, welche zusätzliche Beweislogik den gespeicherten Hash verwendet, und dokumentiere die Annahmen über Finalität. Eine unabhängige Sicherheitsprüfung ist besonders sinnvoll, wenn der Vertrag Gelder verwaltet oder Auszahlungen freigibt. Testnet-Ergebnisse sind hilfreich, aber nicht automatisch auf Mainnet übertragbar. Kontrolliere ausserdem die Kosten unter realistischen Lastbedingungen. Für kritische Anwendungen empfiehlt sich ein Plan für den Fall, dass eine externe Komponente ausfällt oder eine Prüfung nicht rechtzeitig innerhalb des Speicherfensters abgeschlossen werden kann.
Was Anleger daraus ableiten können
EIP-2935 ist keine Investmentstrategie. Es gibt keinen eigenständigen EIP-2935-Token, dessen Wert automatisch von der Einführung dieser Infrastruktur abhängt. Technische Verbesserungen können langfristig die Entwicklung von Anwendungen erleichtern, aber daraus folgt weder ein bestimmter ETH-Kurs noch eine garantierte Nachfrage nach einem Altcoin. Wer in Kryptoanlagen investiert, trägt weiterhin erhebliche Preis-, Liquiditäts-, Verwahrungs- und Gegenparteirisiken. Hinzu kommen Fehler in Smart Contracts und mögliche Verluste durch kompromittierte Bridges. Selbst eine formal korrekte Blockchain kann mit wirtschaftlich riskanten Produkten kombiniert werden. Prüfe deshalb die reale Nutzung, die Sicherheitsarchitektur und die rechtlichen Rahmenbedingungen einer Anwendung getrennt von ihrem Marketing. Dieser Beitrag ist allgemeine Information und keine individuelle Anlageberatung.
Häufige Frage: Sind 8'191 Blockhashes dauerhaft verfügbar?
Nein. Das Fenster ist begrenzt und wird fortlaufend überschrieben. EIP-2935 schafft kein unendliches Archiv. Für ältere Daten sind andere Speicher- oder Nachweisverfahren nötig. Entscheidend ist der Abstand zwischen angefragter und aktueller Blocknummer, nicht eine starre Stundenangabe. Auch die anfängliche Befüllung nach Aktivierung eines Netzwerks muss berücksichtigt werden. Unmittelbar nach Aktivierung existieren nicht rückwirkend sämtliche früheren Hashes in diesem neuen Speicher. Entwickler sollten daher beim Start einer Anwendung prüfen, welche Historie tatsächlich bereits befüllt wurde.
Häufige Frage: Wird BLOCKHASH auf 8'191 erweitert?
Nein. Der bisherige Opcode bleibt auf seine bisherige Semantik beschränkt. Das längere Fenster ist über den speziellen History-Vertrag verfügbar. Ein bestehender Vertrag, der weiterhin ausschliesslich BLOCKHASH verwendet, profitiert nicht automatisch von der zusätzlichen Reichweite. Eine Anpassung muss bewusst entwickelt und getestet werden. Diese Trennung schützt die Rückwärtskompatibilität und erleichtert die Prüfung von Programmen, die bisher auf dem 256-Blöcke-Fenster aufbauen.
Häufige Frage: Macht der Standard Bridges sicher?
Nein. Ein überprüfbarer historischer Hash kann nur ein Baustein einer sicheren Bridge sein. Schlüsselverwaltung, Administratorrechte, Beweisprüfung, Finalität und mögliche Upgrades bleiben entscheidend. Ein Fehler in einem dieser Bereiche kann auch dann zum Verlust von Vermögenswerten führen, wenn der History-Vertrag korrekt arbeitet. Anleger sollten die Verwendung eines Ethereum-Standards daher nicht mit einer unabhängigen Sicherheitsgarantie verwechseln.
Fazit
EIP-2935 verankert einen begrenzten Ausschnitt historischer Execution-Blockhashes im Ethereum-Zustand. Der Ansatz kann Smart Contracts und Rollups bei bestimmten Prüfungen unterstützen und passt zu längerfristigen Arbeiten an zustandsarmen Ausführungsmodellen. Gleichzeitig bleiben die Grenzen klar: 8'191 Einträge statt unbegrenzter Historie, ein separater Systemvertrag statt einer Änderung des BLOCKHASH-Opcodes und ein Hash statt eines vollständigen Transaktionsbeweises. Wer diese Unterschiede versteht, kann den Standard realistisch einordnen. Für Entwickler zählen korrekte Blocknummern, Fenstergrenzen und Finalitätsannahmen. Für Anleger bleibt EIP-2935 eine Infrastrukturentwicklung ohne Gewinnversprechen.
Kommentare