| title | Zeitachse aller Ethereum-Forks (2014 bis heute) |
|---|---|
| description | Eine Geschichte der Ethereum-Blockchain einschließlich wichtiger Meilensteine, Veröffentlichungen und Forks. |
| lang | de |
| sidebarDepth | 1 |
Eine Zeitachse aller wichtigen Meilensteine, Forks und Updates der Ethereum-Blockchain.
Forks treten auf, wenn größere technische Upgrades oder Änderungen am Netzwerk vorgenommen werden müssen – sie stammen typischerweise von Ethereum-Verbesserungsvorschlägen (EIPs) und ändern die „Regeln“ des Protokolls.
Wenn Upgrades in traditioneller, zentral gesteuerter Software benötigt werden, veröffentlicht das Unternehmen einfach eine neue Version für den Endbenutzer. Blockchains funktionieren anders, da es keinen zentralen Eigentümer gibt. Ethereum-Clients müssen ihre Software aktualisieren, um die neuen Fork-Regeln zu implementieren. Außerdem müssen Block-Ersteller (Miner in einer Proof-of-Work-Welt, Validatoren in einer Proof-of-Stake-Welt) und Blockchain-Knoten Blöcke erstellen und nach den neuen Regeln validieren. Mehr zu Konsensmechanismen
Diese Regeländerungen können zu einer vorübergehenden Spaltung im Netzwerk führen. Neue Blöcke könnten nach den neuen oder den alten Regeln produziert werden. Forks werden in der Regel im Voraus vereinbart, sodass Clients die Änderungen einstimmig übernehmen und der Fork mit den Upgrades zur Hauptkette wird. In seltenen Fällen können jedoch Meinungsverschiedenheiten über Forks dazu führen, dass sich das Netzwerk dauerhaft spaltet – am bekanntesten ist die Entstehung von Ethereum Classic durch den DAO-Fork.
Die Software, die Ethereum zugrunde liegt, besteht aus zwei Hälften, bekannt als die Ausführungsebene und die Konsensebene.
Benennung von Ausführungs-Upgrades
Seit 2021 werden Upgrades der Ausführungsebene nach den Städtenamen früherer Devcon- und Devconnect-Standorte in chronologischer Reihenfolge benannt:
| Upgrade-Name | Devcon(nect)-Jahr | Devcon-Nummer | Upgrade-Datum |
|---|---|---|---|
| Berlin | 2014 | 0 | 15. Apr. 2021 |
| London | 2015 | I | 5. Aug. 2021 |
| Shanghai | 2016 | II | 12. Apr. 2023 |
| Cancun | 2017 | III | 13. März 2024 |
| Prague | 2018 | IV | 7. Mai 2025 |
| Osaka | 2019 | V | 3. Dez. 2025 |
| Amsterdam | 2022 | Devconnect | TBD - Nächstes |
| Bogotá | 2022 | VI | TBD |
| Istanbul | 2023 | Devconnect | TBD |
| Bangkok | 2024 | VII | TBD |
| Buenos Aires | 2025 | Devconnect | TBD |
| Mumbai | 2026 | VIII | TBD |
Benennung von Konsens-Upgrades
Seit dem Start der Beacon Chain werden Upgrades der Konsensebene nach Sternen benannt, deren Anfangsbuchstaben in alphabetischer Reihenfolge fortschreiten:
| Upgrade-Name | Upgrade-Datum |
|---|---|
| Beacon Chain Genesis | 1. Dez. 2020 |
| Altair | 27. Okt. 2021 |
| Bellatrix | 6. Sep. 2022 |
| Capella | 12. Apr. 2023 |
| Deneb | 13. März 2024 |
| Electra | 7. Mai 2025 |
| Fulu | 3. Dez. 2025 |
| Gloas | TBD - Nächstes |
| Heze | TBD |
Kombinierte Benennung
Die Ausführungs- und Konsens-Upgrades wurden anfangs zu unterschiedlichen Zeiten eingeführt, aber nach The Merge im Jahr 2022 wurden diese gleichzeitig bereitgestellt. Daher haben sich umgangssprachliche Begriffe entwickelt, um Verweise auf diese Upgrades mit einem einzigen zusammengezogenen Begriff zu vereinfachen. Dies begann mit dem Shanghai-Capella-Upgrade, das allgemein als „Shapella“ bezeichnet wird, und wird bei nachfolgenden Upgrades fortgesetzt.
| Ausführungs-Upgrade | Konsens-Upgrade | Kurzname |
|---|---|---|
| Shanghai | Capella | "Shapella" |
| Cancun | Deneb | "Dencun" |
| Prague | Electra | "Pectra" |
| Osaka | Fulu | "Fusaka" |
| Amsterdam | Gloas | "Glamsterdam" |
| Bogotá | Heze | "Hegotá" |
Springen Sie direkt zu Informationen über einige der besonders wichtigen vergangenen Upgrades: Die Beacon Chain; The Merge; und EIP-1559
Suchen Sie nach zukünftigen Protokoll-Upgrades? Erfahren Sie mehr über kommende Upgrades auf der Ethereum-Roadmap.
Das Prague-Electra-Upgrade („Pectra“) umfasste mehrere Verbesserungen am Ethereum-Protokoll, die darauf abzielten, die Erfahrung für alle Benutzer, Ebene-2-Netzwerke, Staker und Blockchain-Knoten-Betreiber zu verbessern.
Das Staking erhielt ein Upgrade mit sich verzinsenden Validator-Konten und einer verbesserten Kontrolle über eingesetzte Mittel (Stake) mithilfe der Ausführungs-Auszahlungsadresse. EIP-7251 erhöhte das maximale effektive Guthaben für einen einzelnen Validator auf 2048, was die Kapitaleffizienz für Staker verbesserte. EIP-7002 ermöglichte es einem Ausführungskonto, Validator-Aktionen sicher auszulösen, einschließlich des Ausstiegs oder der Auszahlung von Teilen der Mittel, was die Erfahrung für ETH-Staker verbesserte und gleichzeitig dazu beitrug, die Verantwortlichkeit für Blockchain-Knoten-Betreiber zu stärken.
Andere Teile des Upgrades konzentrierten sich auf die Verbesserung der Erfahrung für reguläre Benutzer. EIP-7702 brachte die Möglichkeit für ein reguläres Konto ohne Smart Contract (Extern verwaltetes Konto (EOA)), Code ähnlich einem Smart Contract auszuführen. Dies eröffnete grenzenlose neue Funktionen für traditionelle Ethereum-Konten, wie z. B. Transaktionsbündelung, Gas-Sponsoring, alternative Authentifizierung, programmierbare Ausgabenkontrollen, Kontowiederherstellungsmechanismen und mehr.
Bessere Benutzererfahrung:
- EIP-7702 - EOA-Kontocode festlegen
- EIP-7691 - Erhöhung des Blob-Durchsatzes
- EIP-7623 - Erhöhung der Calldata-Kosten
- EIP-7840 - Blob-Zeitplan zu EL-Konfigurationsdateien hinzufügen
Bessere Staking-Erfahrung:
- EIP-7251 - Erhöhung der
MAX_EFFECTIVE_BALANCE - EIP-7002 - Über die Ausführungsebene auslösbare Ausstiege
- EIP-7685 - Allgemeine Anfragen an die Ausführungsebene
- EIP-6110 - Bereitstellung von Validator-Einzahlungen auf der Blockchain
Verbesserungen der Protokolleffizienz und -sicherheit:
- EIP-2537 - Vorkompilierung für BLS12-381-Kurvenoperationen
- EIP-2935 - Speichern historischer Block-Hashes im Zustand
- EIP-7549 - Verschieben des Komitee-Index außerhalb der Bestätigungen
- Pectra.wtf
- Wie Pectra die Staking-Erfahrung verbessern wird
- Lesen Sie die Spezifikationen des Electra-Upgrades
- Prague-Electra („Pectra“) FAQ
Das Cancun-Upgrade enthält eine Reihe von Verbesserungen an Ethereums Ausführung, die darauf abzielen, die Skalierung in Verbindung mit den Deneb-Konsens-Upgrades zu verbessern.
Dazu gehört insbesondere EIP-4844, bekannt als Proto-Danksharding, das die Kosten für die Datenspeicherung für Ebene-2-Rollups erheblich senkt. Dies wird durch die Einführung von Daten-„Blobs“ erreicht, die es Rollups ermöglichen, Daten für kurze Zeit im Mainnet zu veröffentlichen. Dies führt zu deutlich niedrigeren Transaktionsgebühren für Benutzer von Ebene-2-Rollups.
- EIP-1153 - Transiente Speicher-Opcodes
- EIP-4788 - Beacon-Block-Root in der EVM
- EIP-4844 - Shard-Blob-Transaktionen (Proto-Danksharding)
- EIP-5656 -
MCOPY- Speicher-Kopierbefehl - EIP-6780 -
SELFDESTRUCTnur in derselben Transaktion - EIP-7516 -
BLOBBASEFEE-Opcode
Das Deneb-Upgrade enthält eine Reihe von Verbesserungen an Ethereums Konsens, die darauf abzielen, die Skalierung zu verbessern. Dieses Upgrade erfolgt in Verbindung mit den Cancun-Ausführungs-Upgrades, um Proto-Danksharding (EIP-4844) zu ermöglichen, zusammen mit anderen Verbesserungen an der Beacon Chain.
Vorgenerierte signierte „freiwillige Ausstiegsnachrichten“ laufen nicht mehr ab, was Benutzern, die ihre Mittel bei einem Drittanbieter-Blockchain-Knoten-Betreiber staken, mehr Kontrolle gibt. Mit dieser signierten Ausstiegsnachricht können Staker den Betrieb des Blockchain-Knotens delegieren und gleichzeitig die Möglichkeit behalten, jederzeit sicher auszusteigen und ihre Mittel abzuheben, ohne jemanden um Erlaubnis bitten zu müssen.
EIP-7514 bringt eine Verschärfung der Emission von ETH mit sich, indem die „Churn“-Rate, mit der Validatoren dem Netzwerk beitreten können, auf acht (8) pro Epoche begrenzt wird. Da die ETH-Emission proportional zu den gesamten gestakten ETH ist, begrenzt die Einschränkung der Anzahl der beitretenden Validatoren die Wachstumsrate der neu ausgegebenen ETH, während gleichzeitig die Hardwareanforderungen für Blockchain-Knoten-Betreiber gesenkt werden, was der Dezentralisierung zugutekommt.
- EIP-4788 - Beacon-Block-Root in der EVM
- EIP-4844 - Shard-Blob-Transaktionen
- EIP-7044 - Dauerhaft gültige signierte freiwillige Ausstiege
- EIP-7045 - Erhöhung des maximalen Bestätigungs-Inklusions-Slots
- EIP-7514 - Hinzufügen eines maximalen Epochen-Churn-Limits
Das Shanghai-Upgrade brachte Staking-Auszahlungen auf die Ausführungsebene. In Verbindung mit dem Capella-Upgrade ermöglichte dies Blöcken, Auszahlungsoperationen zu akzeptieren, was es Stakern erlaubt, ihre ETH von der Beacon Chain auf die Ausführungsebene abzuheben.
- EIP-3651 – Startet die
COINBASE-Adresse warm - EIP-3855 – Neuer
PUSH0-Befehl - EIP-3860 – Begrenzung und Messung des Initcodes
- EIP-4895 – Beacon-Chain-Push-Auszahlungen als Operationen
- EIP-6049 - Veraltung von
SELFDESTRUCT
Das Capella-Upgrade war das dritte große Upgrade der Konsensebene (Beacon Chain) und ermöglichte Staking-Auszahlungen. Capella fand synchron mit dem Upgrade der Ausführungsebene, Shanghai, statt und aktivierte die Staking-Auszahlungsfunktion.
Dieses Upgrade der Konsensebene brachte Stakern, die bei ihrer anfänglichen Einzahlung keine Auszahlungsdaten angegeben hatten, die Möglichkeit, dies nachzuholen und so Auszahlungen zu ermöglichen.
Das Upgrade bot auch eine automatische Konto-Sweeping-Funktion, die Validator-Konten kontinuierlich auf verfügbare Belohnungszahlungen oder vollständige Auszahlungen verarbeitet.
Das Paris-Upgrade wurde dadurch ausgelöst, dass die Proof-of-Work-Blockchain eine terminale Gesamtschwierigkeit von 58750000000000000000000 überschritt. Dies geschah bei Block 15537393 am 15. September 2022 und löste das Paris-Upgrade im nächsten Block aus. Paris war der Übergang zu The Merge – sein Hauptmerkmal war das Abschalten des Proof-of-Work-Mining-Algorithmus und der zugehörigen Konsenslogik und stattdessen das Einschalten von Proof-of-Stake. Paris selbst war ein Upgrade für die Ausführungs-Clients (äquivalent zu Bellatrix auf der Konsensebene), das es ihnen ermöglichte, Anweisungen von ihren verbundenen Konsens-Clients entgegenzunehmen. Dies erforderte die Aktivierung einer neuen Reihe interner API-Methoden, die zusammen als Engine API bekannt sind. Dies war wohl das bedeutendste Upgrade in der Geschichte von Ethereum seit Homestead!
- EIP-3675 – Upgrade des Konsenses auf Proof-of-Stake
- EIP-4399 – Ersetzen des DIFFICULTY-Opcodes durch PREVRANDAO
Das Bellatrix-Upgrade war das zweite geplante Upgrade für die Beacon Chain, das die Chain auf The Merge vorbereitete. Es bringt die Validator-Strafen für Inaktivität und Slashing-Vergehen auf ihre vollen Werte. Bellatrix enthält auch ein Update der Fork-Choice-Regeln, um die Chain auf The Merge und den Übergang vom letzten Proof-of-Work-Block zum ersten Proof-of-Stake-Block vorzubereiten. Dazu gehört, dass Konsens-Clients auf die terminale Gesamtschwierigkeit von 58750000000000000000000 aufmerksam gemacht werden.
Das Gray-Glacier-Netzwerk-Upgrade verschob die Schwierigkeitsbombe (Difficulty Bomb) um drei Monate nach hinten. Dies ist die einzige Änderung, die in diesem Upgrade eingeführt wurde, und ähnelt in ihrer Art den Upgrades Arrow Glacier und Muir Glacier. Ähnliche Änderungen wurden bei den Netzwerk-Upgrades Byzantium, Constantinople und London durchgeführt.
- EIP-5133 – verzögert die Schwierigkeitsbombe bis September 2022
Das Arrow-Glacier-Netzwerk-Upgrade verschob die Schwierigkeitsbombe um mehrere Monate nach hinten. Dies ist die einzige Änderung, die in diesem Upgrade eingeführt wurde, und ähnelt in ihrer Art dem Muir Glacier-Upgrade. Ähnliche Änderungen wurden bei den Netzwerk-Upgrades Byzantium, Constantinople und London durchgeführt.
- EF-Blog - Ankündigung des Arrow-Glacier-Upgrades
- Ethereum Cat Herders - Ethereum Arrow-Glacier-Upgrade
- EIP-4345 – verzögert die Schwierigkeitsbombe bis Juni 2022
Das Altair-Upgrade war das erste geplante Upgrade für die Beacon Chain. Es fügte Unterstützung für „Sync-Komitees“ hinzu – was Light-Clients ermöglichte – und erhöhte die Strafen für Validator-Inaktivität und Slashing, während die Entwicklung in Richtung The Merge voranschritt.
Altair war das erste große Netzwerk-Upgrade, das eine genaue Rollout-Zeit hatte. Jedes vorherige Upgrade basierte auf einer deklarierten Blocknummer auf der Proof-of-Work-Chain, bei der die Blockzeiten variieren. Die Beacon Chain erfordert keine Lösung für Proof-of-Work und arbeitet stattdessen mit einem zeitbasierten Epochensystem, das aus 32 zwölfsekündigen „Slots“ besteht, in denen Validatoren Blöcke vorschlagen können. Deshalb wussten wir genau, wann wir Epoche 74.240 erreichen würden und Altair live ging!
Das London-Upgrade führte EIP-1559 ein, das den Transaktionsgebührenmarkt reformierte, zusammen mit Änderungen bei der Handhabung von Gas-Rückerstattungen und dem Zeitplan der Eiszeit (Ice Age).
Vor dem London-Upgrade hatte Ethereum Blöcke mit fester Größe. In Zeiten hoher Netzwerknachfrage arbeiteten diese Blöcke mit voller Kapazität. Infolgedessen mussten Benutzer oft warten, bis die Nachfrage sank, um in einen Block aufgenommen zu werden, was zu einer schlechten Benutzererfahrung führte. Das London-Upgrade führte Blöcke mit variabler Größe in Ethereum ein.
Die Art und Weise, wie Transaktionsgebühren im Ethereum-Netzwerk berechnet wurden, änderte sich mit dem London-Upgrade vom August 2021. Vor dem London-Upgrade wurden die Gebühren ohne Trennung von base- und priority-Gebühren wie folgt berechnet:
Nehmen wir an, Alice musste Bob 1 ETH zahlen. In der Transaktion beträgt das Gaslimit 21.000 Einheiten und der Gaspreis 200 Gwei.
Die Gesamtgebühr hätte betragen: Gaseinheiten (Limit) * Gaspreis pro Einheit, d. h. 21.000 * 200 = 4.200.000 Gwei oder 0,0042 ETH
Die Implementierung von EIP-1559 im London-Upgrade machte den Transaktionsgebührenmechanismus komplexer, aber die Gasgebühren vorhersehbarer, was zu einem effizienteren Transaktionsgebührenmarkt führte. Benutzer können Transaktionen mit einer maxFeePerGas einreichen, die dem entspricht, was sie für die Ausführung der Transaktion zu zahlen bereit sind, in dem Wissen, dass sie nicht mehr als den Marktpreis für Gas (baseFeePerGas) zahlen werden, und erhalten jeden Überschuss, abzüglich ihres Trinkgelds, zurückerstattet.
Dieses Video erklärt EIP-1559 und die Vorteile, die es bringt: EIP-1559 Erklärt
- Sind Sie ein Dapp-Entwickler? Stellen Sie sicher, dass Sie Ihre Bibliotheken und Tools aktualisieren.
- Lesen Sie die Ankündigung der Ethereum Foundation
- Lesen Sie die Erklärung der Ethereum Cat Herders
- EIP-1559 – verbessert den Transaktionsgebührenmarkt
- EIP-3198 – gibt die
BASEFEEaus einem Block zurück - EIP-3529 - reduziert Gas-Rückerstattungen für EVM-Operationen
- EIP-3541 - verhindert die Bereitstellung von Verträgen, die mit
0xEFbeginnen - EIP-3554 – verzögert die Eiszeit bis Dezember 2021
Das Berlin-Upgrade optimierte die Gaskosten für bestimmte EVM-Aktionen und erhöht die Unterstützung für mehrere Transaktionstypen.
- EIP-2565 – senkt die ModExp-Gaskosten
- EIP-2718 – ermöglicht eine einfachere Unterstützung für mehrere Transaktionstypen
- EIP-2929 – Erhöhung der Gaskosten für Zustandszugriffs-Opcodes
- EIP-2930 – fügt optionale Zugriffslisten hinzu
Die Beacon Chain benötigte 16.384 Einzahlungen von 32 gestakten ETH, um sicher zu starten. Dies geschah am 27. November, und die Beacon Chain begann am 1. Dezember 2020 mit der Produktion von Blöcken.
Lesen Sie die Ankündigung der Ethereum Foundation
Die Beacon ChainDer Staking-Einzahlungsvertrag führte das Staking in das Ethereum-Ökosystem ein. Obwohl es sich um einen Mainnet-Vertrag handelte, hatte er direkte Auswirkungen auf den Zeitplan für den Start der Beacon Chain, einem wichtigen Ethereum-Upgrade.
Lesen Sie die Ankündigung der Ethereum Foundation
StakingDer Muir-Glacier-Fork führte eine Verzögerung der Schwierigkeitsbombe ein. Erhöhungen der Blockschwierigkeit des Proof-of-Work-Konsensmechanismus drohten die Nutzbarkeit von Ethereum zu verschlechtern, indem sie die Wartezeiten für das Senden von Transaktionen und die Nutzung von Dapps erhöhten.
- EIP-2384 – verzögert die Schwierigkeitsbombe um weitere 4.000.000 Blöcke oder ~611 Tage.
Der Istanbul-Fork:
- Optimierte die Gas-Kosten bestimmter Aktionen in der EVM.
- Verbesserte die Widerstandsfähigkeit gegen Denial-of-Service-Angriffe.
- Machte Ebene-2-Skalierungslösungen basierend auf SNARKs und STARKs leistungsfähiger.
- Ermöglichte die Interoperabilität von Ethereum und Zcash.
- Erlaubte Verträgen, kreativere Funktionen einzuführen.
Lesen Sie die Ankündigung der Ethereum Foundation
- EIP-152 – ermöglicht Ethereum die Zusammenarbeit mit datenschutzfreundlichen Währungen wie Zcash.
- EIP-1108 – günstigere Kryptografie zur Verbesserung der [Gas](/glossary/#gas)-Kosten.
- EIP-1344 – schützt Ethereum vor Replay-Angriffen durch Hinzufügen des
CHAINID-[Opcodes](/developers/docs/ethereum-stack/#ethereum-virtual-machine). - EIP-1884 – Optimierung der Opcode-Gaspreise basierend auf dem Verbrauch.
- EIP-2028 – reduziert die Kosten für CallData, um mehr Daten in Blöcken zu ermöglichen – gut für die [Ebene-2-Skalierung](/developers/docs/scaling/#layer-2-scaling).
- EIP-2200 – weitere Änderungen der Opcode-Gaspreise.
Der Constantinople-Fork:
- Reduzierte die Block-Belohnung für das Mining von 3 auf 2 ETH.
- Stellte sicher, dass die Blockchain nicht einfror, bevor Proof-of-Stake implementiert wurde.
- Optimierte die Gas-Kosten bestimmter Aktionen in der EVM.
- Fügte die Möglichkeit hinzu, mit Adressen zu interagieren, die noch nicht erstellt wurden.
Lesen Sie die Ankündigung der Ethereum Foundation
- EIP-145 – optimiert die Kosten bestimmter Aktionen auf der Blockchain.
- EIP-1014 – ermöglicht die Interaktion mit Adressen, die noch erstellt werden müssen.
- EIP-1052 – führt den
EXTCODEHASH-Befehl ein, um den Hash des Codes eines anderen Vertrags abzurufen. - EIP-1234 – stellt sicher, dass die Blockchain vor Proof-of-Stake nicht einfriert, und reduziert die Block-Belohnung von 3 auf 2 ETH.
Der Byzantium-Fork:
- Reduzierte die Block-Belohnung für das Mining von 5 auf 3 ETH.
- Verzögerte die Schwierigkeitsbombe um ein Jahr.
- Fügte die Möglichkeit hinzu, nicht-zustandsändernde Aufrufe an andere Verträge durchzuführen.
- Fügte bestimmte Kryptografie-Methoden hinzu, um die Ebene-2-Skalierung zu ermöglichen.
Lesen Sie die Ankündigung der Ethereum Foundation
- EIP-140 – fügt den
REVERT-Opcode hinzu. - EIP-658 – Statusfeld zu Transaktionsbelegen hinzugefügt, um Erfolg oder Misserfolg anzuzeigen.
- EIP-196 – fügt elliptische Kurven und Skalarmultiplikation hinzu, um [ZK-Snarks](/developers/docs/scaling/zk-rollups/) zu ermöglichen.
- EIP-197 – fügt elliptische Kurven und Skalarmultiplikation hinzu, um [ZK-Snarks](/developers/docs/scaling/zk-rollups/) zu ermöglichen.
- EIP-198 – ermöglicht die RSA-Signaturüberprüfung.
- EIP-211 – fügt Unterstützung für Rückgabewerte variabler Länge hinzu.
- EIP-214 – fügt den
STATICCALL-Opcode hinzu, der nicht-zustandsändernde Aufrufe an andere Verträge ermöglicht. - EIP-100 – ändert die Formel zur Anpassung der Schwierigkeit.
- EIP-649 – verzögert die [Schwierigkeitsbombe](/glossary/#difficulty-bomb) um 1 Jahr und reduziert die Block-Belohnung von 5 auf 3 ETH.
Der Spurious-Dragon-Fork war die zweite Reaktion auf die Denial-of-Service-Angriffe (DoS) auf das Netzwerk (September/Oktober 2016), einschließlich:
- Anpassung der Opcode-Preise, um zukünftige Angriffe auf das Netzwerk zu verhindern.
- Ermöglichung der „Entschlackung“ (Debloat) des Blockchain-Zustands.
- Hinzufügen von Schutz vor Replay-Angriffen.
Lesen Sie die Ankündigung der Ethereum Foundation
- EIP-155 – verhindert, dass Transaktionen von einer Ethereum-Chain auf einer alternativen Chain erneut gesendet werden, z. B. dass eine Testnet-Transaktion auf der Haupt-Ethereum-Chain wiederholt wird.
- EIP-160 – passt die Preise des
EXP-Opcodes an – macht es schwieriger, das Netzwerk durch rechenintensive Vertragsoperationen zu verlangsamen. - EIP-161 – ermöglicht das Entfernen leerer Konten, die durch die DOS-Angriffe hinzugefügt wurden.
- EIP-170 – ändert die maximale Codegröße, die ein Vertrag auf der Blockchain haben kann – auf 24576 Bytes.
Der Tangerine-Whistle-Fork war die erste Reaktion auf die Denial-of-Service-Angriffe (DoS) auf das Netzwerk (September/Oktober 2016), einschließlich:
- Behebung dringender Probleme mit der Netzwerkgesundheit in Bezug auf zu niedrig bepreiste Operationscodes.
Lesen Sie die Ankündigung der Ethereum Foundation
- EIP-150 – erhöht die Gaskosten von Opcodes, die bei Spam-Angriffen verwendet werden können.
- EIP-158 – reduziert die Zustandsgröße durch Entfernen einer großen Anzahl leerer Konten, die aufgrund von Fehlern in früheren Versionen des Ethereum-Protokolls zu sehr geringen Kosten in den Zustand eingefügt wurden.
Der DAO-Fork war eine Reaktion auf den DAO-Angriff von 2016, bei dem ein unsicherer DAO-Vertrag bei einem Hack um über 3,6 Millionen ETH erleichtert wurde. Der Fork verschob die Mittel aus dem fehlerhaften Vertrag in einen neuen Vertrag mit einer einzigen Funktion: Auszahlen (withdraw). Jeder, der Mittel verloren hatte, konnte 1 ETH für jeweils 100 DAO-Token in seinen Wallets abheben.
Über diese Vorgehensweise wurde von der Ethereum-Community abgestimmt. Jeder ETH-Inhaber konnte über eine Transaktion auf einer Abstimmungsplattform abstimmen. Die Entscheidung für den Fork erreichte über 85 % der Stimmen.
Einige Miner weigerten sich, den Fork durchzuführen, da der DAO-Vorfall kein Fehler im Protokoll war. Sie gründeten daraufhin Ethereum Classic.
Lesen Sie die Ankündigung der Ethereum Foundation
Der Homestead-Fork, der in die Zukunft blickte. Er umfasste mehrere Protokolländerungen und eine Netzwerkänderung, die Ethereum die Möglichkeit gab, weitere Netzwerk-Upgrades durchzuführen.
Lesen Sie die Ankündigung der Ethereum Foundation
- EIP-2 – nimmt Änderungen am Vertragserstellungsprozess vor.
- EIP-7 – fügt neuen Opcode hinzu:
DELEGATECALL - EIP-8 – führt devp2p-Vorwärtskompatibilitätsanforderungen ein
Der Frontier-Thawing-Fork hob das Limit von 5.000 Gas pro Block auf und setzte den Standard-Gaspreis auf 51 Gwei. Dies ermöglichte Transaktionen – Transaktionen erfordern 21.000 Gas. Die Schwierigkeitsbombe wurde eingeführt, um einen zukünftigen Hard-Fork zu Proof-of-Stake sicherzustellen.
Frontier war eine Live-, aber rudimentäre Implementierung des Ethereum-Projekts. Es folgte auf die erfolgreiche Olympic-Testphase. Es war für technische Benutzer, insbesondere Entwickler, gedacht. Blöcke hatten ein Gaslimit von 5.000. Diese „Auftau“-Phase (Thawing) ermöglichte es Minern, ihren Betrieb aufzunehmen, und frühen Anwendern, ihre Clients zu installieren, ohne sich „beeilen“ zu müssen.
Lesen Sie die Ankündigung der Ethereum Foundation
Ether ging offiziell für 42 Tage in den Verkauf. Man konnte es mit BTC kaufen.
Lesen Sie die Ankündigung der Ethereum Foundation
Das Yellow Paper, verfasst von Dr. Gavin Wood, ist eine technische Definition des Ethereum-Protokolls.
Sehen Sie sich das Yellow Paper an
Das Einführungspapier, das 2013 von Vitalik Buterin, dem Gründer von Ethereum, vor dem Start des Projekts im Jahr 2015 veröffentlicht wurde.
Whitepaper