eip

In der Ethereum-Community ist ein EIP-Entwurf mit einer cleveren Idee aufgetaucht: Mit „versionierten Opcodes“ sollen die Gas-Kosten neu festgelegt werden, ohne bereits deployte Contracts zu beeinträchtigen.

Der zentrale Mechanismus besteht aus drei Ebenen:

1｜Getrennte Ausführung für neue und alte Contracts. Neu deployte Contracts müssen V2-Opcodes verwenden und die neuen, in EIP-8037/8038 festgelegten Gas-Zeitpläne ausführen. Bestehende Contracts behalten den alten Zeitplan bei, sodass ihr bisheriges Verhalten auf der Blockchain unverändert bleibt.

2｜Keine Gas-Introspektion. Der V2-Opcode-Satz enthält keine Abfrage-Opcodes wie GAS oder GASLIMIT. Sind solche Opcodes im Bytecode enthalten, wird das Deployment direkt zurückgerollt. Damit wird verhindert, dass Contracts ihre Logik von der Menge des „verbleibenden Gases“ abhängig machen – und der Weg für künftige freie Anpassungen der Gas-Kosten wird geebnet.

3｜Auch Aufrufe sind versioniert. Der neue Opcode DELEGATECALL_V2 verhält sich ähnlich wie DELEGATECALL, setzt aber voraus, dass code_version des Ziel-Contracts mindestens 2 beträgt. Andernfalls schlägt der Aufruf sofort fehl. So wird verhindert, dass neue Contracts versehentlich Logik aus älteren Versionen aufrufen.

Im Grunde macht dieser Ansatz aus der „Anpassung der Gas-Kosten“ statt eines tiefgreifenden Upgrades des gesamten Netzwerks einen regulären, schrittweisen Wechsel je nach Contract-Version. Die Rückwärtskompatibilität wird dabei auf Protokollebene verbindlich sichergestellt. Für gewöhnliche Nutzer $ETH dürfte das kaum spürbar sein; Contract-Entwickler sollten hingegen den Zeitplan für die Anpassung künftiger V2-Toolchains im Blick behalten.

Originalentwurf: https://github.com/ethereum/EIPs/pull/12638

#以太坊 #EIP #Gasgebühren

Ethereum möchte der EVM eine „Versionsnummer“ geben.

Ein neuer EIP-Entwurf schlägt „versionierte Opcodes zur Neupreisfestsetzung von Gas“ vor. Die Grundidee in einem Satz: Opcodes werden nach Versionen aufgeteilt. Alte Contracts laufen weiterhin mit dem alten Gas-Preisschema, während neu bereitgestellte Contracts V2-Opcodes verwenden und dem neuen Preisschema aus EIP-8037/8038 folgen müssen. Beide Regelwerke stören sich nicht gegenseitig und bleiben rückwärtskompatibel.

Einige Details, die Entwickler beachten sollten:

1. Aus dem V2-Opcodesatz wurden GAS, GASLIMIT und andere Opcodes zur Abfrage von Gas direkt entfernt. Neue Contracts, die auch nur einen davon enthalten, werden bei der Bereitstellung zurückgerollt. Die dahinterstehende Logik: Wenn ein Contract davon abhängt, „wie viel Gas noch übrig ist“, könnte jede künftige Preisanpassung ihn beschädigen.

2. DELEGATECALL_V2 kommt neu hinzu. Das Verhalten ähnelt DELEGATECALL, aber der Ziel-Contract muss code_version ≥ 2 haben, andernfalls schlägt der Aufruf sofort fehl. Das entspricht einer Versionskontrolle für Aufrufe zwischen Contracts.

3. Ziel des gesamten Entwurfs ist es, Ethereum bei künftigen Anpassungen der Gas-Kosten mehr Spielraum zu geben: Durch die Trennung nach Versionen werden der Raum für Upgrades und die Sicherheit bestehender Contracts voneinander abgegrenzt, statt bei jeder Preisänderung das gesamte Ökosystem mitzubewegen.

Im Grunde holt die EVM damit nach, was ein „evolvierbares Softwaresystem“ ausmacht. Der Vorschlag befindet sich noch im Entwurfsstadium; bis zur Aufnahme in ein Mainnet-Upgrade ist es noch ein weiter Weg. Diese Richtung sollte man jedoch langfristig im Blick behalten.

#以太坊 #EIP #EVM

Ethereum hat still einen EIP-Entwurf veröffentlicht, der den Lebenszyklus von Smart Contracts im kommenden Jahrzehnt beeinflussen könnte: Versionierte Opcodes sollen den Weg für eine Neupreisgestaltung von Gas ebnen.

Die Kernlogik hat drei Ebenen:
1. Neu bereitgestellte Contracts müssen V2-Opcodes verwenden und damit die neuen Gas-Zeitplantabellen aus EIP-8037/8038 ausführen. Bereits bereitgestellte Contracts behalten die alte Tabelle bei; ihr Verhalten bleibt unverändert.
2. Die V2-Opcode-Sammlung entfernt direkt die Gas-Introspektionsbefehle GAS, GASLIMIT und weitere. Enthält der Bytecode solche Opcodes, wird die Bereitstellung rückgängig gemacht.
3. DELEGATECALL_V2 wird eingeführt. Seine Semantik ähnelt der von DELEGATECALL, allerdings muss der Ziel-Contract code_version ≥ 2 haben, andernfalls schlägt der Aufruf sofort fehl.

Warum sollten Entwickler darauf achten? Bisher war bei Änderungen der Gas-Kosten auf Ethereum die größte Sorge, dass eine „Neupreisgestaltung gleich einer Verhaltensänderung bei bestehenden Contracts“ sei. Protokolle, die sich auf fest codierte Gas-Annahmen stützten, haben dadurch schon mehrfach Nachteile erlitten. Mit der Versionierung bleiben alte Contracts bei den alten Regeln, während neue Logik den neuen Regeln folgt. Zum ersten Mal gibt es eine klare Grenze zwischen Upgrades und Kompatibilität.

Die Nachteile sind ebenso deutlich: Die Möglichkeit, Gas zu inspizieren, wird gezielt entfernt. Designs, die die verbleibende Gas-Menge in Echtzeit on-chain auslesen, müssen daher frühzeitig angepasst werden. Die Versionsanforderung von DELEGATECALL_V2 wird Proxy-Contracts, Multisigs und Smart Wallets außerdem dazu zwingen, ihre gesamte Aufrufkette neu zu prüfen.

Der Entwurf befindet sich noch in der PR-Phase. Bis zum Mainnet sind noch mehrere Hürden zu nehmen – Reviews, Tests und Hard Forks. Die Richtung ist jedoch bereits klar: Ethereum macht aus der „upgradefähigen EVM“ ein konkretes Mechanismusdesign. Inhaber von $ETH müssen kurzfristig nichts unternehmen. Entwicklern wird empfohlen, den Originaltext frühzeitig zu lesen und den Migrationsaufwand einzuschätzen.

#以太坊 #EIP #Gas

In der Ethereum-Core-Entwickler-Community gibt es neue Entwicklungen: Ein EIP-Entwurf mit dem Titel „Versionierte Opcodes zur Neubepreisung von Gas“ wurde offiziell im Forum zur öffentlichen Diskussion gestellt. Die zentrale Idee besteht darin, Opcodes mit Versionsnummern zu versehen, damit künftige Anpassungen der Gas-Kosten keine Hardforks erfordern, die bereits bereitgestellte Contracts beeinträchtigen.

Konkret umfasst der Entwurf mehrere wichtige Punkte:

Erstens: paralleler Betrieb und Abwärtskompatibilität. Neu bereitgestellte Contracts müssen V2-Opcodes verwenden und die in EIP-8037/8038 definierte neue Gas-Tabelle befolgen. Bereits bestehende Contracts verwenden weiterhin die alte Tabelle und verhalten sich unverändert. Die Auswirkungen einer „Preiserhöhung“ bleiben damit auf neue Contracts beschränkt.

Zweitens: Aus dem V2-Opcode-Satz wurden bewusst Opcodes zur Gas-Inspektion wie GAS und GASLIMIT entfernt. Enthält der Bytecode eines neuen Contracts solche Opcodes, wird die Bereitstellung direkt zurückgerollt. Die Überlegung der Entwickler-Community: Wenn ein Contract zu stark von der präzisen Prüfung des verbleibenden Gas abhängt, kann jede künftige Neubepreisung eine Kettenreaktion von Fehlern auslösen. Daher sollte diese Kopplung besser von Anfang an vermieden werden.

Drittens: DELEGATECALL_V2 kommt hinzu. Seine Semantik ähnelt der des klassischen DELEGATECALL, allerdings muss der code_version des Ziel-Contracts mindestens 2 betragen. Andernfalls schlägt der Aufruf sofort fehl. So soll verhindert werden, dass ein neuer Contract versehentlich alte Logik aufruft und dabei auf überholte Gas-Annahmen trifft.

Insgesamt handelt es sich um einen grundlegenden Designschritt, der den Weg für die langfristige Upgradefähigkeit von Ethereum ebnen soll: Die Gas-Bepreisung ist nie ein statischer Parameter. Versionierte Opcodes schaffen für das Protokoll einen reibungslosen Anpassungspfad, der „nur neue Contracts betrifft und alte unbehelligt lässt“. Für Entwickler wird es darauf ankommen, wann die Toolchains für die Migration und die Prüfregeln nachziehen. Für normale Nutzer wird sich das On-Chain-Erlebnis kurzfristig nicht spürbar ändern, doch könnte dieser Schritt die Art und Weise, wie Smart Contracts in den kommenden Jahren geschrieben werden, maßgeblich beeinflussen.

#以太坊 #EIP

Ethereum will der EVM eine „Versionsnummer“ verpassen.

Ein neuer EIP-Entwurf schlägt „versionierte Opcodes zur Neupreisgestaltung von Gas“ vor. Die Grundidee: Neu bereitgestellte Contracts verwenden V2-Opcodes und einen neuen Gas-Zeitplan (EIP-8037/8038), während bereits bereitgestellte ältere Contracts weiterhin den alten Regeln folgen. Beide Systeme beeinflussen sich nicht gegenseitig, sodass Anpassungen der Gas-Kosten abwärtskompatibel bleiben.

Einige Design-Details sind besonders bemerkenswert:

1. Der V2-Opcode-Satz entfernt GAS, GASLIMIT und weitere Opcodes zur Abfrage von Gas-Informationen vollständig. Enthält ein neuer Contract solche Instruktionen, wird seine Bereitstellung direkt zurückgerollt – genau diese Art von Instruktionen hat dazu geführt, dass historische Anpassungen der Gas-Preise bestehende Contracts leicht unbeabsichtigt beeinträchtigen konnten.

2. DELEGATECALL_V2 kommt neu hinzu. Sein Verhalten ähnelt dem von DELEGATECALL, aber der Ziel-Contract muss code_version ≥ 2 haben. Andernfalls schlägt der Aufruf sofort fehl. So sollen semantische Mehrdeutigkeiten bei delegierten Aufrufen über Versionsgrenzen hinweg vermieden werden.

3. Das übergeordnete Ziel ist einfach: Künftige Anpassungen der Gas-Kosten sollen keine „Alles-oder-nichts-Lösung per Hard Fork“ mehr sein, sondern einen reibungslosen Übergang je nach Contract-Version ermöglichen, ohne die Annahmen bereits bereitgestellter Contracts zu verletzen.

Anders gesagt: Ethereum versucht, für die EVM einen Weiterentwicklungsmechanismus nach dem Vorbild der Softwareversionierung zu schaffen. Sollte der Entwurf umgesetzt werden, würde sich die langfristige Upgrade-Fähigkeit der EVM deutlich verbessern. Für $ETH wäre das ebenfalls eine konkrete Verbesserung auf Ebene der Basisinfrastruktur.

Der vollständige Entwurf: github.com/ethereum/EIPs/pull/12638

#以太坊 #EIP #EVM

Der Ethereum-Foundation-Forscher frisitano hat einen EIP-Entwurf eingereicht, der PeerDAS um ein „vertrauensloses Setup + Quantenresistenz“-Upgrade erweitern soll.

Die wichtigste Änderung: Die KZG-Commitments und -Beweise für Blobs werden durch Keccak-256-Merkle-Commitments und Authentifizierungspfade ersetzt. Ein LeanDA-STARK-Beweis berechnet dann die Merkle-Wurzel erneut, prüft die Reed-Solomon-Kodierungsbeziehungen und bestätigt, dass Commitment und Daten übereinstimmen. Dadurch entfällt die Abhängigkeit von einem vertrauenswürdigen KZG-Setup, während zugleich die Sicherheit gegenüber künftigen Quantencomputern erhöht wird.

Der Entwurf führt außerdem Blobs variabler Größe ein: Ihre Länge muss zwischen 2048 und 524288 Byte liegen, eine Zweierpotenz sein und durch 128 Spalten teilbar sein. Transaktionen auf der Ausführungsebene enthalten künftig (merkle_root, byte_length) statt eines versioned hash. Auch die Netzwerkebene und die Gas-Berechnung werden entsprechend angepasst.

Wird der Vorschlag endgültig umgesetzt, können Rollups Daten bedarfsgerechter übermitteln und Blob-Ressourcen effizienter nutzen. Derzeit handelt es sich jedoch noch um einen Entwurf; Parameterdesign, Kompatibilität und Sicherheit müssen weiter diskutiert werden. $ETH #以太坊 #EIP #PeerDAS

EIP-7702 ist ein Sicherheitsupdate für das Ethereum-Netzwerk, das als eine der Ursachen für den jüngsten Binance-Hack genannt wurde. Das Update soll die Sicherheit von Transaktionen im Ethereum-Netzwerk verbessern, doch seine Implementierung hat bei einigen Entwicklern Bedenken ausgelöst.

Für Trader ist diese Nachricht wichtig, weil sie die Stabilität und Sicherheit von Transaktionen im Ethereum-Netzwerk beeinträchtigen könnte, was sich auf den Wert der Kryptowährungen auswirken könnte, die das Netzwerk nutzen. Die Ethereum-Entwickler arbeiten daran, das Update so zu implementieren, dass Unterbrechungen des Dienstes möglichst gering gehalten werden.

Doch welche Maßnahmen sollten Börsen eurer Meinung nach ergreifen, um sich vor künftigen Hacks zu schützen?

#EIP-7702 #BinanceHack #Ethereum #KryptoSicherheit

Die Ethereum Foundation Protocol DevOps-Teams veröffentlichen offiziell das Early-Testing-Netzwerk für das Upgrade „Glamsterdam“: Platåberget. Der Hardfork wird am 20. August in diesem Netzwerk abgeschlossen. Im Gegensatz zu früheren kurzfristigen Devnets wird Platåberget voraussichtlich mehrere Monate stabil laufen und zusätzlich eine One-Click-Netzwerkkonfiguration sowie einen Test-ETH-Faucet bereitstellen, damit Entwickler und die Community kontinuierlich an der Verifikation teilnehmen können.

Auch die Test-Roadmap ist im Wesentlichen klar: Innerhalb eines Monats soll ein nicht endgültiges Devnet online gehen, das für Tests von Szenarien mit abweichendem Konsens dient; anschließend werden langfristige Testnetze wie Sepolia, Hoodi usw. nacheinander die Glamsterdam-Hardfork abschließen, wobei das finale Ziel direkt auf ein Upgrade des Ethereum-Mainnets ausgerichtet ist.

Besonders hervorzuheben sind die Änderungen, auf die man bei diesem Upgrade achten sollte:

Eingebettete Trennung von Proposer und Builder (ePBS), bei der die Beziehung zwischen proposer und builder in die Protokollebene geschrieben wird; Blockbasierte Zugrifflisten (Block-Level Access Lists), zur Optimierung der On-Chain-Datenzugriffseffizienz; Neufestlegung der Gas-Kosten, mit dem Ziel einer Untergrenze von etwa 200 Millionen Gas; die maximalen Größenlimits für Verträge und initcode werden von 24 KiB bzw. 48 KiB auf 64 KiB bzw. 128 KiB angehoben.

Ganz besonders zu beachten ist: Alle Tools, die von hart codierten maximalen Gas-Limits abhängen – wie Wallets, Indexer, Gas-Schätzer usw. – werden davon betroffen sein und müssen entsprechend aktualisiert werden. Den betroffenen Entwicklungsteams wird empfohlen, die Anpassung frühzeitig zu bewerten.

#以太坊 #Glamsterdam #EIP

Die Ethereum-Community hat kürzlich einen EIP-Vorschlag für „Einzahlungsveträge zur Unterstützung der Post-Quantum-Kryptografie“ eingereicht. Wie siehst du dieses proaktive Vorgehen, um sich frühzeitig auf die zukünftige Bedrohung der Cybersicherheit von Krypto-Assets durch Quantencomputing vorzubereiten?

Die Kernpunkte des Vorschlags umfassen:
1️⃣ Einführung neuer Verträge zur Unterstützung von Public Keys und Nachweis-Metadaten variabler Länge, sowie die Ergänzung eines eindeutigen Scheme-Bezeichners (scheme 0 ist für die aktuelle BLS-Einzahlung reserviert)
2️⃣ Der neue Einzahlungsvetrag stützt sich nicht mehr auf die bisherige Merkle-Tree-Struktur der alten Einzahlungsveträge, sondern übergibt die Einzahlungsinformationen an die Konsensschicht durch die log-abgeleitete Ausführung von Anforderungen gemäß EIP-7685 – die Struktur wird dadurch klarer
3️⃣ Einrichtung eines irreversiblen Umschaltmodus, der durch das Protokollsystem gesteuert wird: Die Einzahlung wird zunächst deaktiviert; zu einem festgelegten Zeitpunkt wird die BLS-Einzahlung aktiviert. Danach wird zu einem späteren Zeitpunkt die BLS-Einzahlung dauerhaft deaktiviert – und sie kann nicht erneut aktiviert werden. So wird die Migration Schritt für Schritt abgeschlossen
4️⃣ Während der Migration muss der Ausführungs-Client die Einzahlungsanfragen sowohl aus dem neuen als auch aus dem alten Vertrag gleichzeitig zusammenführen, um einen reibungslosen Übergang sicherzustellen

Angesichts der kontinuierlichen Weiterentwicklung der Quantencomputing-Technologie ist es sinnvoll, die Sicherheitsstandards der Krypto-Infrastruktur frühzeitig zu erhöhen, um die Vermögenssicherheit der Nutzer langfristig zu schützen.$ETH Ökosystem – meinst du, so ein „Vorsorge-Upgrade“ ist notwendig?

#以太坊 #EIP #Post-Quantum-Sicherheit

Die Ethereum-Community hat gerade eine neue Einlagenvertrag-EIP-Vorlage für die Sicherheit gegen Post-Quanten-Computing veröffentlicht. Das ist ein weiterer wichtiger Schritt für Ethereum hin zu einer langfristig sicheren Sicherheitsarchitektur.

Der Kern dieser mit der Nummer EIP-12235 versehenen Vorlage umfasst:
✅ Einführung eines neuen Vertrags zur Unterstützung variabler Längen von öffentlichen Schlüsseln und Credential-Metadaten, kombiniert mit einer klar definierten scheme-Kennung; der aktuelle BLS-Einlagen-Scheme bleibt 0
✅ Verzicht auf die Merkle-Baum-Struktur des alten Einlagenvertrags durch die Ableitungs-Ausführung von Einzahlungsinformationen mittels Log-Derivation-Requests gemäß EIP-7685 in die Konsensschicht
✅ Festlegung einer irreversiblen Zeitleiste, die von einem Protokollsystemaufruf gesteuert wird: Einlagen zunächst deaktiviert, dann BLS-Einlagen aktivieren und schließlich BLS-Einlagen dauerhaft deaktivieren
✅ Während der Migrationsphase muss der Client die Einzahlungsanfragen sowohl für den neuen als auch für den alten Vertrag zusammenführen

Post-Quanten-Sicherheit ist seit langem ein Schwerpunktbereich der Blockchain-Branche. Die Weiterentwicklung des Quantencomputings stellt eine langfristige potenzielle Bedrohung für bestehende Kryptografieverfahren dar. Ethereum rüstet frühzeitig durch Architektur-Updates auf und bereitet sich so auf zukünftige Sicherheitsanforderungen vor – das lohnt sich, kontinuierlich im Blick zu behalten.

$ETH

#以太坊 #EIP #Post-Quanten-Sicherheit

📰 Das Team der Ethereum Foundation Protocols hat die Prioritäten für das Upgrade von Hegotá aufgelistet – und auch das Ziel ist sehr klar: Bis zum 12. Dezember 2029 sollen die drei Ebenen von Ethereum Layer 1 – Ausführung, Konsens und Daten – die Vorbereitung auf die Quanten­sicherheit abgeschlossen haben.

🔥 Zu den beiden zentralen Vorschlägen, die als S-Kategorie „muss unbedingt live gehen“ eingestuft wurden, gehört auf der Konsensebene FOCIL, also EIP-7805. Es soll durch das Erzwingen der Einbeziehung von Public-Mempool-Transaktionen die Widerstandsfähigkeit des Netzwerks gegen Zensur stärken.

💡 Auf der Ausführungsebene gehört ebenfalls der Frame Transactions genannte EIP-8141 zu den „muss live gehen“-Projekten. Er zerlegt Transaktionen in mehrere programmierbare „Frames“ für Verifikation, Gas-Zahlung und Ausführung. Dadurch gibt es künftig eine klarere technische Grundlage für nativen Account Abstraction, benutzerdefinierte Signaturen sowie das Paymaster- bzw. Gas-Delegationsmodell.

Ehrlich gesagt: Quanten­sicherheit klingt für viele Nutzer ziemlich weit weg, aber das ist kein kurzfristiges Pflaster, sondern eine langfristige Upgrade-Roadmap, die das Protokollteam frühzeitig geplant hat. Das Team rechnet damit, dass es ab dem Hardfork Glamsterdam im vierten Quartal 2026 losgeht. Danach soll im Schnitt jede Hardfork etwa 7,2 Monate dauern, um vor dem „Q-day“ – der etwa um 2030 herum erwartet wird – fertig zu sein.

🤔 Wie viele Jahre wird Ethereum dafür brauchen? Und findest du diese vorausschauenden Upgrades sind solide, oder machen sie die Protokoll-Iteration zu langsam?

#以太坊 #Hegotá #量子安全 #EIP

EIP-8361: Der Vorschlag wird offiziell veröffentlicht. Die Kernidee: Ethereum-Inflation „einen Drosselventil-Einsatz“ verpassen:

· In jedem Epoch wird ein Teil aus den Blockbelohnungen der Validatoren abgezogen und vernichtet
· Wenn die gesamte weltweite Staking-Quote 50% erreicht, wird die Vernichtungsrate direkt auf 100% hochgefahren
· Der konkrete Anteil der schließlich ausbleibenden Belohnungen wird durch das Markt-Poker bestimmt, liegt aber streng unter 50%

Kurz gesagt: Je mehr gestaket wird, desto härter werden die Belohnungen vernichtet. Das ist ein Design-Experiment, bei dem eine On-Chain-Mechanik die ETH-Inflation gewissermaßen in die Gegenrichtung dämpfen soll. 50% ist dabei die entscheidende psychologische Schwelle und zugleich die „Warnlinie“ für „übermäßiges Staking“ aus Sicht der Autoren des Vorschlags.

Wenn das umgesetzt wird, bedeutet das, dass sich das ökonomische Modell von Ethereum weiter in Richtung „Deflation priorisieren“ bewegt: Langfristige Halter profitieren, aber die Rendite für Validatoren wird spürbar gedrückt. Siehst du diesen Kurs als gut an?

#Ethereum#EIP#Inflation

Die Ethereum-Community hat gerade einen neuen Einzahlungsvertrag-EIP-Entwurf für das Zeitalter des Post-Quantum-Computing veröffentlicht. Das schafft frühzeitig die Grundlage für eine Sicherheitsaktualisierung – diese Weitsicht verdient volle Punktzahl👏

Kernpunkte des Vorschlags im Überblick:
▫️ Einführung eines neuen Vertrags, der variable Längen für öffentliche Schlüssel und Anmelde-/Zertifikats-Metadaten unterstützt, sowie eines neuen, klar definierten scheme-Bezeichners (scheme 0 ist für die aktuelle BLS-Einzahlung reserviert)
▫️ Keine Abhängigkeit mehr von der alten Einzahlungsvertrags-Struktur mit dem Merkle-Baum: Durch die logbasierte Ausführung der Requests gemäß EIP-7685 werden die Einzahlungsinformationen an die Konsensschicht übergeben – die Architektur wird schlanker und effizienter
▫️ Einrichtung eines nicht umkehrbaren Übergangsmechanismus: Die Einzahlung wird zunächst deaktiviert, dann innerhalb von Zeitfenstern zunächst BLS-Einzahlungen aktivieren, nach Ablauf dauerhaft BLS deaktivieren – der Wechsel ist klar und kontrollierbar
▫️ In der Migrationsphase muss der Client die Einzahlungs-Requests für neue und alte Verträge zusammenführen, um einen reibungslosen Übergang zu gewährleisten

Angesichts der sich allmählich nähernden Bedrohung durch Quantencomputing startet die Ethereum-Community frühzeitig ein grundlegendes Sicherheits-Upgrade. So wird die Basis für die langfristige Sicherheit des Ökosystems gelegt – genau das ist die Art von Top-Level-langfristigem Denken, die man haben muss.

Wie siehst du diese Vorausplanung von Ethereum für das Post-Quantum-Zeitalter? Lass uns deine Meinung in den Kommentaren wissen👇

#以太坊 #EIP #Post-Quantum-Computing

Vitalik neueste Rede im Detail EIP-8288: Ethereum-Skalierung kommt zur „endgültigen Lösung“, zukünftige Transaktionen werden wieder schnell und günstig!

Kernproblem: Ethereum steht seit langem vor dem Dilemma, dass sich Quanten­sicherheit, Datenschutz und Skalierbarkeit nur schwer gleichzeitig erreichen lassen. Normale Transaktionen benötigen etwa 21.000 Gas, die Validierung einer ECDSA-Signatur ungefähr 4.000 Gas; Quanten­sichere Signaturen sind dagegen teuer und kosten 100.000–300.000 Gas, ZK-Privacy-Beweise mindestens 350.000 Gas (manchmal sogar über eine Million). Wenn man beides kombiniert (Quanten­sicherheit + Privacy via STARK-Beweise), verschlingt eine einzelne Transaktion rund 8 Millionen Gas – dadurch würde sich der Ethereum-TPS von 25 direkt auf 0,25 reduzieren, im Grunde nicht nutzbar.

Der Lösungsansatz von V神: Der Kern von EIP-8288 ist, teure kryptografische Rechenoperationen aus der Kette auszulagern:
Bevor eine Transaktion on-chain geht, aggregieren Knoten im mempool die Signaturen/Beweise mehrerer Nutzer zu einem STARK-Beweis mit einem Design namens „mikro-Frame-Struktur“; on-chain wird nur die Abhängigkeitsinformation von etwa 65–96 Byte hinterlegt, die umfangreichen kryptografischen Daten selbst kommen nicht on-chain. Die Transaktion wird in zwei Teile zerlegt: „Geschäftslogik“ und „Verifikationsarbeit“. Die Verifikation wird out-of-chain parallel verarbeitet (spezialisierte Shards).

Einige Highlights: Das könnte das erste Mal sein, dass Ethereum tatsächlich ein RISC-V-Befehlssatzszenario einführt; die Lösung basiert auf dem kurz bevorstehenden EIP-8141 (Native Account Abstraction); nach der Kompression kann die Blockdatenmenge im Bereich von 100–300 KB gehalten werden; die Entwickler-Erfahrung ändert sich kaum – Ethereum-Entwickler müssen nicht viel anpassen.

Fazit: Wenn das Vorhaben umgesetzt wird, sinken die Kosten für quanzensichere Transaktionen deutlich, Datenschutz-Anwendungen müssen nicht mehr wegen hoher Gasgebühren abgewürgt werden, und die Bestätigungsgeschwindigkeit von L2s mit ZK-Rollup kann ebenfalls spürbar steigen. In der Community sind bereits mehrere Einstiegskanäle geöffnet, darunter Netzwerk-Simulationsmodelle, Testnetze, Algorithmus-Wettbewerbe und Prototypcode-Bibliotheken; derzeit befindet es sich in einer frühen Phase des gemeinsamen Aufbaus.

#以太坊扩容 #EIP #比特币现货ETF四日流入23.1亿美元

【Nachrichten-Zusammenfassung】Ethereum-Forscher schlagen EIP-8361 vor: „Auslaufende Emission durch Burn“ zur Begrenzung des Staking-Anteils

Kürzlich haben eine Gruppe von Ethereum-Forschern (u. a. Justin Drake) einen Entwurf zu EIP-8361 (Tapered Issuance Burn) veröffentlicht.

Kurz gesagt funktioniert das so:
1. Die Validator-Belohnungen richten sich nach dem gesamten Netzwerk-Staking-Anteil und ziehen einen Teil ab, der dauerhaft vernichtet wird
2. Je mehr Staking, desto höher ist der Burn-Anteil
3. Wenn das aktive Staking 60,25 Millionen ETH erreicht (etwa die Hälfte des Angebots), kann der Burn 100% erreichen; die Netto-Emission auf der Konsens-Ebene nähert sich dann nahe Null
4. Um die Auswirkungen auf bestehende Staker abzumildern, wurde eine Übergangsphase von etwa 18 Monaten entworfen (die Übergangsphase passt gleichzeitig den Belohnungsfaktor an)

Die Motivation des Vorschlags ist eher auf die Protokollschicht ausgerichtet: die Zentralisierungs- und „Capture“-Risiken zu vermeiden, die durch unendliches Aufhäufen von Staking entstehen, und gleichzeitig möglichst unge-staked ETH in ihrer neutralen Rolle als Währung zu erhalten. Aktuell ist es weiterhin ein Draft; ob es in ein späteres Netzwerk-Upgrade gelangt, ist noch unklar. Die Community diskutiert dies bei Eth Magicians / auf GitHub.

Quelle:
The Block https://www.theblock.co/post/410643/ethereum-researchers-propose-burning-validator-rewards-cap-staking-50
CoinDesk https://www.coindesk.com/tech/2026/08/05/new-ethereum-proposal-would-cut-issuance-to-zero-if-staked-eth-reaches-usd112-billion
Entwurf https://github.com/pintail-xyz/EIPs/blob/edde78eb1feeb285906d5a8deb582c4feaecd6ba/EIPS/eip-draft_tapered_issuance_burn.md

#Ethereum #EIP
Informationszusammenstellung, keine Anlageberatung

Die neueste Einreichung aus der Ethereum-Community hat den EIP-12235-Vorschlag eingebracht. Geplant ist, einen neuen Einzahlungsvertrag einzuführen, der eine quantensichere Sicherheit nach dem Post-Quantum-Computing unterstützt—für eine frühzeitige Planung der langfristigen Sicherheit von Ethereum. Dieser Schritt ist sehr solide.

Die Kernaussagen des Vorschlags umfassen:
1️⃣ Der neue Vertrag unterstützt öffentlich veränderliche (variabel lange) öffentliche Schlüssel sowie Metadaten für Nachweise; außerdem wird ein eindeutiger Scheme-Identifier hinzugefügt. Scheme 0 bleibt für das aktuelle BLS-Einzahlungs-Mechanismus vorbehalten
2️⃣ Der Vertrag ist nicht mehr von der Merkelbaum-Struktur des alten Einzahlungsvertrags abhängig. Stattdessen werden die Einzahlungsinformationen über die log-abgeleitete Ausführung gemäß EIP-7685 an die Konsensschicht übergeben
3️⃣ Es wurde ein durch das Protokollsystem gesteuerter, nicht rückgängig zu machender Übergangsmodus festgelegt: Im Anfangszustand ist die Einzahlungsfunktion deaktiviert. Zuerst wird die BLS-Einzahlung zu einem vorgegebenen Zeitstempel aktiviert, anschließend wird die BLS-Einzahlung zu einem späteren Zeitstempel dauerhaft deaktiviert—und kann nicht wieder aktiviert werden
4️⃣ Während der Migration muss der Client sowohl die Einzahlungsanfragen des neuen als auch des alten Vertrags zusammenführen

Vor dem großen Hintergrund der Entwicklung der Quantencomputing-Technologie ist es sehr notwendig, die kryptografische Sicherheitsbasisinfrastruktur frühzeitig aufzurüsten—denn Sicherheit ist die Lebensader der Blockchain.

$ETH
#以太坊 #后量子安全 #EIP

📰 Binance-Exploit mit EIP-7702-Delegierung in Verbindung gebracht, vorläufige Verluste steigen
Fireblocks zufolge ermöglichte eine signierte EIP-7702-Delegierung Abhebungen aus Binance-Hot-Wallets; Binances vorläufiges Update deutet auf einen kompromittierten DevOps-Laptop hin. (Mehr lesen)
Quelle : Blockchain News
Zeit : 2026-10-30 19:59:28
Verfasser : tony kim
#lazarus_group #binance #crypto-security #news #eip-7702
$ARB $BTC $USDT
Teile deine Meinung im Kommentarbereich unten

Ethereum will die Finalität von etwa 16 auf etwa 4 Minuten verkürzen. Ben Edgington, Koordinator der Ethereum-Forschung zu schneller Finalität, hat gemeinsam mit Francesco D'Amato, Roberto Saltini, Yann Vonlanthen und Mikhail Kalinin einen EIP-Entwurf eingereicht (Nummer 12566, inzwischen im offiziellen Verfahren). Ziel ist es, die Zeit bis zur endgültigen Bestätigung etwa um den Faktor vier zu verkürzen.

Warum muss es schneller gehen? Anbieter grenzüberschreitender Überweisungen müssen Geld vorstrecken und auf die Bestätigung warten: Bei konstanten Vorauszahlungen von 1 Million US-Dollar pro Stunde wären bei einer Verzögerung von 16 Minuten rund 267.000 US-Dollar gebunden. Mit 4 Minuten wären es nur etwa 67.000 US-Dollar.

Die technische Ursache: Validatoren verwenden ihre Stimme für zwei Zwecke – sie wählen damit sowohl Blöcke aus als auch bestätigen ältere Blöcke. Die Bestätigung kann daher nur im Takt des Validatorenwechsels erfolgen. Der Entwurf trennt die beiden Stimmen, sodass die Bestätigung unabhängig davon beschleunigt und später weiter verkürzt werden kann. Getrennte Abstimmungen würden außerdem den späteren Wechsel zu quantensicheren Signaturen erleichtern. Die Verfasser räumen selbst ein, dass „many aspects remain TBD“ – vieles also noch offen ist. Das bescheidene Ziel im Moment ist lediglich, eine EIP-Nummer zu erhalten und in den offiziellen Upgrade-Prozess von Ethereum aufgenommen zu werden. Das Design ist noch nicht fertig, und es gibt kein Aktivierungsdatum – betrachtet den Vorschlag also nicht als beschlossene Sache.

Im Vergleich wird es noch interessanter: Circle (CRCL) verlangt für schnelle grenzüberschreitende USDC-Überweisungen bereits Gebühren nach Geschwindigkeit. Die schnelle Ethereum-Route kostet 0,01 % (1 US-Dollar pro 10.000 US-Dollar); zudem ist das Gesamtvolumen schneller Überweisungen begrenzt. Der Konkurrent Solana hat mit Alpenglow eine Finalität von etwa 150 Millisekunden zum Ziel (gestern gerade gestartet). Selbst mit 4 Minuten wäre Ethereum noch langsam, punktet aber mit der Sicherheit und Größe seines Mainnets.

Quellen: CoinDesk und EIP-Entwurf (github.com/ethereum/EIPs/pull/12566).

#ETH #以太坊 #EIP #跨链 #Circle

🛡️ Ethereum schlägt Sicherheitsverbesserungen für Nutzertransaktionen vor

Ein neuer Vorschlag von Ethereum-Entwicklern, EIP-7906, führt einen Transaktionsbestätigungsmechanismus ein, der das Problem des Blind Signing angehen soll. Dieser Mechanismus könnte die Sicherheit von Transaktionen erhöhen und die Abhängigkeit von Wallet-Oberflächen verringern. Davon könnten Nutzer und Institutionen profitieren, die bei Transaktionen auf wirksame Risikokontrollen angewiesen sind.

━━━━━━━━━━━━━━
📊 Auswirkung: 📈 Hoch
🏷️ ALTCOIN

#Ethereum #Security #EIP #Blockchain #Innovation

📰 Quelle: cryptobriefing.com