Die Ethereum Foundation hat kürzlich das öffentliche Testnetz Platåberget freigegeben, um die nächste Phase des großen Upgrades Glamsterdam (Gloas + Amsterdam) frühzeitig zu proben.
Diesmal ist es nicht nur „noch ein Testnetz“: Die grundlegenden Regeln werden an vielen Stellen geändert, z. B.: • Proposer-Builder Separation (ePBS), die im Protokoll eingebaut ist • Blockbasierte Access List (BAL) • Neuberechnung der Gas-Kosten sowie die Einführung einer Dimension, die nach „State-Bytes“ abgerechnet wird
Für normale Nutzer ist das unmittelbarste Detail: Die bisherige Faustregel „Standardmäßige ETH-Überweisung = 21000 Gas“ muss angepasst werden. Wenn man auf eine neue Adresse wechselt, die man noch nie verwendet hat, weil dabei ein Konto erstellt werden muss, fallen zusätzliche state-bezogene Gebühren an. Wallets, Indexer und Gas-Schätztools, die die alten Annahmen noch fest eincodiert haben, könnten dadurch falsche Werte berechnen.
Die Foundation weist außerdem darauf hin: Tools, die hart codierte Gas-Limits verwenden, müssen aktualisiert werden. Entwickler können zuerst auf Platåberget testen und dann im nächsten Schritt dem Zeitplan für das langfristige Testnetz und das Mainnet folgen.
Der nächste große Upgrade-Schritt für Ethereum, Glamsterdam, bringt eine ziemlich konkrete Änderung: Vom Wechsel auf ETH ist nicht mehr immer pauschal 21000 Gas fix.
Laut den Angaben der Ethereum Foundation gilt: Wenn man an eine bereits existierende Adresse überweist, bleiben es ungefähr 21000; wenn man an eine neue Adresse überweist, die nie zuvor auf der Kette war, kommt zusätzlich State-Gas hinzu (das Netzwerk muss die Kontostände neu erstellen und dauerhaft speichern).
Wallets, Browser und Gas-Schätzer, die weiterhin 21000 als endgültige Obergrenze betrachten, könnten nach dem Mainnet-Release mit falscher Schätzung fehlschlagen oder Aufträge ablehnen.
Die EF hat das öffentliche Testnetz Plataberget freigegeben, damit Wallets und dApps schon früh Stolpersteine erkennen und umgehen können. Das Upgrade umfasst außerdem ePBS, Block-level Access Lists sowie eine Anhebung des Limits für die Vertragsgröße. Aktuell befindet sich alles noch in Test-/Härtungsphase; für normale Nutzer gibt es diese Woche nichts zu tun – hauptsächlich müssen Entwickler und die Infrastruktur nachziehen.
Der nächste große Upgrade-Schritt für Ethereum in Glamsterdam – und dabei gibt es eine ziemlich Hardcore-Detailsache: Die langjährige Faustregel, dass normale ETH-Transfers pauschal „fix 21.000 Gas“ kosten, wird sich ändern.
Laut einem Bericht von CoinDesk und einer Erklärung der Ethereum Foundation gilt: Beim Transfer an bereits existierende Konten bleibt es weiterhin bei rund 21.000 Gas; aber bei Transaktionen an neue Adressen, die noch nie auf der Kette waren, wird zusätzlich eine State-Gas-Komponente fällig (der Bericht nennt etwa 183.600 Einheiten) – denn das Netzwerk muss den neuen Kontostatus anlegen und langfristig speichern. Der Aufwand ist also grundsätzlich unterschiedlich – früher wurde nur zu demselben Preis abgerechnet.
Für normale Nutzer besteht jetzt kein Grund zur Panik: Die Änderung wird zuerst auf Testnetzen (z. B. Platåberget) verifiziert. Wirklich nachziehen müssen Wallets, Browser und Gebühren-Schätztools: Wenn man 21.000 weiterhin als fest codierte Unter- oder Obergrenze behandelt, kann es zu abgelehnten Transaktionen oder zu niedrigen Angeboten kommen.
Auf Protokollebene wird „Wachstum des Zustands“ zunehmend feiner bepreist – und das ist deutlich näher an den realen technischen Zwängen von Clients und Wallet-Engineering als nur über TPS zu sprechen.
【Protokollnotizen】Das nächste große Upgrade von Ethereum könnte das standardmäßige „21000 gas“ in Wallets ändern
Laut CoinDesk (ca. vor 1 Tag), zusammengestellt: Im geplanten Glamsterdam-Upgrade wird die Annahme, dass dauerhaft standardmäßig „normale ETH-Transfers immer 21000 gas“ kosten, aufgesplittet –
• Transfer an eine bereits existierende Adresse: weiterhin grob nach der 21000er-Struktur • Transfer an eine neue Adresse, die noch nie auf die Kette kam: zusätzlicher Aufwand für die Kontoerstellung/Status-Schreiben (State gas)
Die Erklärung der Ethereum Foundation vom 17.08. zum Platåberget-Testnetz erwähnt außerdem: Die Neubewertung betrifft u. a. die Kontoerstellung, das Deployen von Code, das Schreiben neuer Storage-Slots usw.; alle Tools, die den Gas-Limit fest „einfrieren“, könnten betroffen sein.
Für Wallets und dApps geht es dabei nicht primär um Kursrufe, sondern um technische Anpassung: 1)Die Gebührenschätzung darf nicht länger pauschal auf 21000 festgelegt sein 2)Kostenmodelle für Airdrops/den ersten Transfer müssen neu berechnet werden 3)Auf Benutzerebene muss erklärbar sein, „warum diese Transaktion teurer ist“
Als Orientierung lassen sich Gas-Neubewertungs-Diskussionen wie EIP-8037 / EIP-2780 heranziehen. Das Upgrade wird weiterhin entwickelt und getestet; die Details richten sich nach der finalen Implementierung der Clients.
Nächste große Ethereum-Upgrades: Hegotá (Ziel etwa 2027) – die Vorschlagsliste wird gerade zusammengestellt~
Laut Berichten von CoinDesk und anderen liegen Entwicklern derzeit etwa 66 EIP auf dem Tisch. In den kommenden Runden werden die Core-Dev-Teams diejenigen heraussuchen, die realisierbar sind, testbar und mit guter Chance rechtzeitig auf den Weg gebracht werden können. Relativ klar vorangetrieben wird derzeit vor allem FOCIL (EIP-7805) in Richtung Zensurresistenz.
Ein weiterer technischer Blickfang sind Frame Transactions (EIP-8141) sowie die dazugehörigen Keyed Nonces und Recent Roots. Der Diskussionsschwerpunkt liegt darin, datenschutzorientierten Anwendungen mehr „Werkzeuge auf Protokollebene“ zu geben – weniger Abhängigkeit von externen Relayern. Klarstellen muss man: Normale ETH-Transfers werden an sich nicht zu vollständiger On-Chain-Privatsphäre; der Verdeckungseffekt beruht weiterhin hauptsächlich auf dem App-Design.
Öffentliche Dokumente dazu: eips.ethereum.org (u. a. EIP-7805 / 8141). Was am Ende tatsächlich kommt, hängt von der Client-Implementierung und dem Stand der Testnetze ab.
Heute ein eher „Hardcore“-Update aus dem Infrastrukturbereich: World Chain (Ethereum L2 basierend auf OP Stack) aktiviert wie geplant im Mainnet die Stream-EIP-7928-Blockzugriffslisten (Block-Level Access Lists, BALs).
Technischer Drehhaken, so lässt es sich verstehen: 1) Früher mussten viele Clients Transaktionen blockweise und in Reihenfolge ausführen, um Zustandsabhängigkeiten überhaupt greifen zu können 2) EIP-7928 sorgt dafür, dass der Block eindeutig aufzeichnet, welche Konten und Storage-Slots in diesem Block gelesen/geschrieben wurden—das erleichtert paralleles Lesen von der Platte, paralleles Prüfen der Konsistenz und ebnet den Weg für späteren höheren Durchsatz 3) World Chain implementiert das zudem in flashblock: etwa alle ~200 ms werden die Zugrifflisten gestreamt; die Verifikation kann somit beginnen, während der Block noch „ausläuft“, und parallel überprüft werden. In öffentlichen Berichten wird als Ziel genannt, den Durchsatz zu erhöhen, ohne die Hardwareanforderungen für Validatoren anzuheben (konkrete Zahlen hängen von offiziellen Angaben und Messungen ab)
Auf der Seite des Ethereum-Mainnets folgt EIP-7928 weiterhin dem Standard-Weg über Diskussionen und spätere Upgrades (in der Öffentlichkeit wird es oft mit der Glamsterdam- Roadmap in Verbindung gebracht). Für das L2 kommt zunächst ein Runtime-Flag zum Einsatz—quasi eine Vorab-Engineering-Übung für das Ökosystem.
Schnelle Projekt-Verifikation: Das öffentliche Repository worldcoin/world-chain ist ein Rust-Monorepo, MIT Open Source, und in den letzten Tagen gab es noch immer kontinuierliche Commits/PRs (inkl. Fixes rund um proofs und flashblock)—also kein bloßes Marketing-„Leergerüst“.
【Nachrichten-Zusammenfassung】 Bank of England Digital-Pfund-Labor Phase 2: Können Stablecoins und CBDC in einer gemeinsamen Abwicklungs-Transaktion zusammenwirken?
Laut CoinDesk ist das Digital Pound Lab der Bank of England (BOE) in Phase 2 eingetreten und rückt in den Fokus, zu testen, ob öffentliche Stablecoins und Zentralbankdigitalwährungen (digitales Pfund) in demselben grenzüberschreitenden Zahlungsfluss für Handelsfinanzierung kooperieren können.
Zu den Beteiligten gehören NOBO Finance, Dun & Bradstreet und Polygon Labs. Eines der Szenarien: Ein Exporteur könnte zunächst eine Rechnungsvorschussfinanzierung über einen Stablecoin erhalten, während der britische Importeur die Abwicklung schließlich mit dem digitalen Pfund vornimmt. Polygon stellt dabei eine Stablecoin-Abwicklungs-Infrastruktur im Zusammenhang mit dem Open Money Stack bereit (Umtausch von Fiat-Währungen, Wallets, Smart Contracts usw.) und versucht, Wallet-Transaktionsdaten mit Unternehmens-Auskunfteidaten zu kombinieren, um wiederverwendbare Bonitätsprofile für KMU zu erstellen.
Wichtig ist die Abgrenzung: Das Labor bezieht sich weder auf echte Kunden noch auf echtes Geld und bedeutet auch nicht, dass das Vereinigte Königreich bereits entschieden hat, ein digitales Pfund auszugeben. Vielmehr geht es darum zu bewerten, wie unterschiedliche Formen digitaler Währungen miteinander interoperabel sind und ob sie die Prüf- und Abwicklungsreibung in der Handelsfinanzierung für KMU verringern können.
Quelle: CoinDesk https://www.coindesk.com/business/2026/08/12/bank-of-england-to-test-stablecoin-digital-currency-use-in-cross-border-finance BOE Digital Pound Lab https://www.bankofengland.co.uk/the-digital-pound/lab
Informationen zusammengefasst, keine Anlageberatung
【Technische Notizen】Womit beschäftigt sich die Solana-Engineering-Seite gerade?
Ich habe mir den offiziellen Changelog vom 13.08. angeschaut – eher „hardcore“, kein Preisgeschwafel:
1)Die Slot-Zeit auf dem Testnetz wird weiter nach unten gedrückt: Es gibt bereits ein Feature-Gate von 350→300 ms und 300→250 ms; der Client bereitet sich auf einen kürzeren Block-Takt vor. 2)Iteration mit mehreren Clients: Agave hat in letzter Zeit eine stabile v4.2.x-Version veröffentlicht und treibt v4.3 voran; auch Firedancer / Frankendancer haben entsprechende Releases. 3)Vorbereitung für Alpenglow: z. B. Parallelisierung bei der BLS-Validierung von Votes, um das Risiko zu senken, dass „der Vote-Burst“ die Knotenvalidierung voll auslastet.
Wie diese zwei Linien einordnen: • Slot verkürzen ≈ Blockproduktionsfrequenz erhöhen (gestuft aktivieren, weiterhin abhängig von der Netzstabilität) • Alpenglow ist ein großer Umbau des Konsenses: In öffentlichen Materialien wird häufig das Ziel genannt, die finale Bestätigung von der Größenordnung von ein paar zehn Sekunden auf etwa 150 ms zu drücken – das Mainnet-Fenster kann sich jedoch mit den Testanpassungen noch ändern
Code-seitig gegengeprüft: Agave (anza-xyz/agave) hatte in den letzten Tagen weiterhin dichte Commits und Releases – das ist kontinuierlicher Engineering-Fortschritt, keine leere Story.
Solana stand kurz vor der Auslösung einer Freeze-Schwelle: Eine Grundlagenstunde zu Infrastruktur – kein Börsenpost.
Laut CoinDesk und dem Staking-Provider Marinade führte eine Routing-Störung bei einem großen Rechenzentrumsanbieter dazu, dass zeitweise rund 29 % der gestakten SOL ausfielen. Das Solana-Design sieht vor: Wenn mehr als etwa ein Drittel der gestakten Gewichtung offline geht, kann das Netzwerk kein finality mehr abschließen (d. h. die endgültige Bestätigung von Transaktionen). Marinade zufolge fehlte damals nur etwa ein Aufmaß von rund 20 Millionen Staked-Amount bis zu dieser Schwelle.
Ein paar technische Punkte, die man sich merken sollte: 1) Die Fehlerquelle wird auf eine fehlerhafte Routenführung im Teraswitch-Rechenzentrum in Miami zurückgeführt, die auch Teile Europas und Asiens betraf; in Nordamerika war das Gros der Knoten weiterhin online. 2) Berichtet wird, dass ein einzelner Netzbetreiber (AS2032) zeitweise über ein Viertel der gestakten Gewichtung kontrollierte; die Konzentration selbst ist damit schon ein Risikofaktor. 3) Die Routenstörung wurde nach etwa 10 Minuten behoben. Die Solana Foundation betont, dass Blöcke weiterhin kontinuierlich erzeugt werden, Transaktionen weiterhin ankommen und etwa 597/699 gestakte Validatoren weiterhin abstimmten – näher an einem Stresstest als an einem vollständigen Shutdown.
Beobachtung: Bei leistungsstarken Chains ist Dezentralisierung nicht nur eine Frage der Anzahl der Validatoren – man muss auch sehen, ob Rechenzentren, ASN und Failover-Backups wirklich verteilt sind. In der Nähe der 1/3-Schwelle zu sein entspricht quasi einer Lektion für das ganze Netz.
Zero-Knowledge-Chain Miden kündigt Privacy-Stablecoin USDCx an: 1:1, besichert durch Circle USDC über xReserve. Transaktionen sind standardmäßig nicht öffentlich in Bezug auf Guthaben, Gegenparteien und Transaktionsverläufe; es besteht jedoch die Möglichkeit, gegenüber Prüfern/Regulierungsbehörden selektiv offenzulegen.
Technischer Blickpunkt ist das clientseitige Proving – die Transaktion wird auf dem Gerät des Nutzers ausgeführt, erzeugt einen Nachweis und wird anschließend on-chain verifiziert. So soll Vertraulichkeit, wie sie Institutionen wünschen, mit der on-chain Verifizierbarkeit kombiniert werden. Offiziell heißt es, das Ziel sei der Sync mit dem Mainnet und der Start noch in diesem Monat (gegen Monatsende). Die Anwendungsfälle umfassen Zahlungen, Handel, Gehaltsauszahlungen und das Cash-/Liquiditätsmanagement von Unternehmen.
Miden wurde von Polygon getrennt und als eigenständiges Projekt aufgebaut; auf der öffentlich zugänglichen Code-Seite sind weiterhin aktive Beiträge für Rust-Repositories wie miden-vm / protocol / node zu sehen. Die konkreten Zeitpunkte für das Mainnet und USDCx richten sich nach den offiziellen Angaben.
Nachrichtenübersicht: MoneyGram Ramps ist jetzt auf Solana live.
Kurz gesagt: Wallets, Börsen und Apps können über eine einzige API das globale Cash-Netzwerk von MoneyGram on-chain anbinden. Bargeld-Einzahlungen sind in 25+ Ländern verfügbar, Bargeld-Abhebungen in 170+ Ländern und Regionen. Nutzer müssen nicht jede App einzeln an Bankenschnittstellen anbinden, und Entwickler haben weniger Infrastrukturaufwand.
Das ist für die Zahlungs-Story von Solana recht greifbar: Stablecoins sind hier nicht nur Handelspaare, sondern können als Ein- und Ausstiegsstelle in den Offline-Markt von Krypto dienen. MoneyGram war zuvor bereits Validator auf Solana; diesmal wird das Ramps-Produkt direkt in das Ökosystem eingebettet (Rift & Co. gehören zu den ersten Integrationspartnern).
【Informationszusammenstellung】Der Ethereum-Roadmap ändert sich: Privatsphäre und Post-Quantum rücken nach vorn
Vitalik hat kürzlich die klassische Roadmap von 2023 mit dem von der Ethereum Foundation fortlaufend aktualisierten Strawmap verglichen (als Referenz für Protokoll-Upgrades, grob bis 2029).
Er sagte: Das auffälligste ist nicht, „was noch da ist“, sondern eine Reihe von Richtungen, die es auf der Grafik von 2023 überhaupt nicht gab und die jetzt zum Kern geworden sind:
1) Starke Privatsphäre: Privacy-Pools, Wormholes usw., um möglichst wenig die vollständigen Transaktionspfade offenzulegen; auch designbezogene Elemente zur Zensurresistenz (z. B. FOCIL) stehen auf der Roadmap 2) Post-Quantum: Langfristige kryptografische Sicherheit in die North Star aufnehmen (z. B. hash-basierte Richtungen) 3) Lean Ethereum: Die Spezifikationen sollen prägnanter werden; langfristig wird zudem über die Weiterentwicklung von Ausführungsumgebungen diskutiert 4) Wenn ZK reifer wird, sind auch Pfade wie native Rollups eher diskussionsfähig
Die Strawmap selbst nennt fünf grobe Hauptrichtungen: schnelleres L1, höhere Durchsatzraten (Gigagas L1 / Teragas L2), Post-Quantum-L1 sowie die Privatsphäre als gleichberechtigten Bürger.
Das ist kein Material zum „Kaufen/Shorten“-Rufen, sondern eher eine öffentliche Koordination auf Protokollebene: Während die Performance erweitert wird, werden Privatsphäre, Zensurresistenz und langfristige Sicherheit gemeinsam mitgetragen. Strawmap betont außerdem, dass es sich um einen Strawman / ein lebendes Dokument handelt und nicht um einen starren Zeitplan.
Technische Notizen|Bitcoin BIP-110 Fork-Versuch: Nach zwei Blöcken nahezu Stillstand
Mit BIP-110 (Reduced Data Temporary Softfork) soll auf der Konsens-Ebene „für ein vorübergehendes Jahr“ die Möglichkeit eingeschränkt werden, nicht-finanzielle Daten in Transaktionen einzubetten: z. B. Begrenzung zu großer scriptPubKey-/Witness-Daten, Wiederherstellung strengerer Grenzen für OP_RETURN usw. Befürworter argumentieren, dass datenbezogene Inscriptions die Zahlungen und die Kosten der Knoten verdrängen; Gegner sind der Ansicht, wer eine Gebühr zahlt, soll den Blockspace frei nutzen dürfen.
Im Aktivierungsfenster lag das Miner-Signal bei nur etwa 2,53% – deutlich unter der 55%-Schwelle. Ab Block 961.632 begannen Knoten, die BIP-110-Clients ausführen, Blöcke abzulehnen, für die kein Signal gesendet wurde, wodurch sich eine Minderheiten-Fork-Kette bildete.
Am interessantesten ist dabei der Mechanismus der Schwierigkeit: Die Fork-Kette übernahm die aktuelle Mining-Schwierigkeit des Mainnets, doch ihr Anteil an der Hashrate war extrem klein. Dadurch wurde das Blockintervall auf mehrere Stunden gezogen; eine Neuberechnung der Schwierigkeit erfolgt erst nach 2016 Blöcken. Ergebnis: Auf der Fork-Seite wurden nach etwa zwei Blöcken kaum noch weitere Blöcke gemined, mit einem Zeitrückstand von ungefähr der Größenordnung eines Tages gegenüber der Mainchain.
Noch ein praxisnaher Hinweis: In der Anfangsphase könnten beide Ketten weiterhin Transaktionen im gleichen Format akzeptieren, wodurch ein Replay-Risiko besteht – Verkaufs-Transaktionen, die auf der Fork-Coin signiert wurden, könnten ebenfalls ins Mainnet replayt werden. Bei der Beobachtung eines Fork-Ereignisses sind technische Details wichtiger als Schlagworte.
Sui hat kürzlich offiziell die Weiterentwicklung von Post-Quantum-Signaturfähigkeiten angekündigt und setzt dabei auf den von NIST standardisierten Weg:
1) Für Alltagskonten: Geplante native Unterstützung von ML-DSA-65 (FIPS 204) 2) Für hochwertige Tresore: In Move-Contracts mit hashbasiertem SLH-DSA-SHA2-128s
Offiziell heißt es, die Kernimplementierung sei bereits abgeschlossen und mit Benchmarks versehen. Der grobe Zeitplan lautet: Ziel für den quantensicheren Tresor ist dieses Jahr das Mainnet; native ML-DSA-65-Konten sollen bis Ende des Jahres auf das Testnet gehen; das Ziel für Konten-Authentifizierung im Mainnet liegt bei 2027 Q1. Das Design ist optional aktivierbar, kann aus bestehenden Mnemonics abgeleitet werden und verpflichtet nicht dazu, dass alle sofort ihre Schlüssel wechseln.
Technisch geht es darum: Post-Quantum von der reinen Diskussion in Richtung Protokoll- und Wallet-Evolutionsfähigkeit zu bringen, statt es als Preisstory zu framen. Details sind im offiziellen Blog nachzulesen.
【Technische Notizen】XRPL 3.3.0: „Beträge können verborgen werden, das Ledger bleibt dennoch prüfbar“
Der XRPL-Client rippled hat diese Woche Version 3.3.0 veröffentlicht (GitHub XRPLF/rippled, ca. 08/06). Von der Reihe der amendments ist besonders sehenswert Confidential Transfers (Geheime Überweisungen):
• Ausgelegt für Multi-Purpose Token (MPT, ein gängiges Format für institutionelle tokenisierte Vermögenswerte) • Kontoadressen und Token-Typ bleiben öffentlich • Kontostände und Überweisungsbeträge können verschlüsselt werden; das Ledger nutzt kryptografische Beweise, um die Saldenausgeglichenheit von Ein- und Ausgängen zu belegen, ohne die konkreten Zahlen ins gesamte Netz zu streuen • In der ersten Version ist ein aktives Opt-in durch Inhaber erforderlich; außerdem deckt sie vor allem direkte MPT-Zahlungen zwischen Konten ab (zunächst ohne integrierte Pfade wie eingebauten DEX-Handel, Custody usw.)
In derselben Version sind außerdem institutionell geprägte Betriebsfunktionen gebündelt: Batch (bis zu 8 Vorgänge gebündelt, entweder alle gültig oder alle ungültig), Sponsor (Gebühren-/Reserveübernahme; neue Konten müssen nicht erst XRP horten), Permission Delegation (nur bestimmte Arten von Transaktionen erlauben) und Dynamic MPT etc. Offiziell/aus dem Betrieb wurde außerdem erwähnt, dass der Speicherverbrauch um etwa 10%–15% sinkt und das Nachverfolgen von Blocks schneller wird.
Wichtige Grenze: Diese amendments sind noch nicht aktiv — XRPL wird sie nur aktivieren, wenn vertrauenswürdige Validierer zwei Wochen in Folge ≥80% Unterstützung liefern. CoinDesk verweist auf RWA.xyz: Auf XRPL wurde ein RWA-Volumen von etwa 1,38 Milliarden US-Dollar verteilt (inkl. RLUSD u. a.); davon sind tokenisierte Vermögenswerte ohne RLUSD ungefähr 530 Millionen+.
Nach dem Go-Live ist der entscheidende Punkt, ob Emittenten wie Aviva, Ondo usw. wirklich den „Krypto-Modus“ aktivieren.
Ein Satz: Das ist ein Protokoll-Update für „konforme Privatsphäre + bessere Bedienbarkeit für Institutionen“, keine Story über den Kurs.
【Technische Notizen】Sui kündigt die Einführung quantenresistenter Signaturen an
Sui zufolge schreibt der offizielle Sui-Blog (6.8.), dass zwei Suiten genormter post-quantensicherer Signaturen eingebunden werden: • Tägliche Konten: ML-DSA-65 (FIPS 204) als natives Protokoll-Signaturschema • Hochwertige Tresore: SLH-DSA-SHA2-128s (FIPS 205) innerhalb von Move-Verträgen
Konkrete Punkte mit hoher Umsetzbarkeit: Schlüssel können weiterhin aus bestehenden Seed-Phrasen abgeleitet werden; mithilfe der bereits verfügbaren Address Aliases können Konten die autorisierten Schlüssel aktualisieren, ohne erst Vermögenswerte umziehen zu müssen. Der Fahrplan sieht grob vor, dass der quantenresistente Tresor-Zielbereich dieses Jahr im Mainnet liegt, die nativen ML-DSA-Konten bis Ende in ein Testnet gebracht werden und im 1. Quartal 2027 ins Mainnet (Zeitplan wird weiterhin nach Audit- und Testnet-Feedback angepasst).
Auch The Block etc. sind bereits nachgezogen. Im Kern geht es darum, dass Kryptografie „austauschbar“ ist – das Signaturschema wird ergänzt, ohne Konsens und vorhandenen Status zu ändern.
【Technische Notiz】L2 zuerst zum Laufen bringen: parallele Verifikation — World Chain × EIP-7928
Kürzliche Aktualisierung mit Fokus auf die „Protokollebene“: World Chain (Worlds OP-Stack-L2) hat angekündigt, dass im Mainnet vollständige Block Access Lists (BALs) aktiviert werden. Dabei werden sie in Flashblocks gestreamt – etwa in jeder ~200-ms-Subblock-Inkrement-Erhöhung wird ein Slice der Access-List mitgeliefert. Offiziell heißt es, Sepolia sei am 27.7. geöffnet, das Mainnet-Ziel sei der 17.8.; aktiviert wird das per Runtime-Switch, ohne auf eine Hard Fork warten zu müssen.
Warum lohnt es sich, das anzusehen? • Klassische Verifikation muss Transaktionen der Reihe nach abspielen; Zustandsabhängigkeiten blockieren die Parallelisierung • EIP-7928 ermöglicht, dass ein Block „mit sich führt“, welche Konten und Storage Slots gelesen/geschrieben wurden – plus die entsprechenden Werte danach • Verifikationsknoten können darauf basierend parallel prüfen, den Zustand vorwärmen und die Verifikationskosten in den Prozess des Blockens verteilen, statt sie am Blockende einmalig fertigzurechnen • Offizielle Tests/Beschreibung: Bei höherem Durchsatz (in Berichten/Blogposts wird ein Stress-Test in Richtung ~1 Ggas/s erwähnt) bleibt die Verifikationslatenz relativ stabil – der Kern ist: „Wenn der Durchsatz steigt, muss man die Verifikations-Hardware nicht im gleichen Verhältnis aufstocken“
Weiter in die Zukunft: BALs sind auch eine der Headline-Richtungen in den Diskussionen zur kommenden Ethereum-Upgrade-Welle nach „Glamsterdam“; dass L2 erst im Produktionspfad vorab mit einem Lauf beginnt und dann L1 Feedback liefert, ist ein typischer Rhythmus für Ökosystem-Zusammenarbeit.
Auf der Code-Seite: Das monorepo worldcoin/world-chain (Rust) hat in den letzten Tagen weiterhin Commits und PRs rund um flashblocks / proofs – kein bloßes Ankündigungs-„Leerkonstrukt“.
Quelle (prüfbar): • The Block: https://www.theblock.co/post/410651/world-chain-first-production-l2-block-access-lists-via-flashblocks • World Engineering-Blog: https://world.org/blog/engineering/world-chain-full-block-access-lists • EIP-7928: https://eips.ethereum.org/EIPS/eip-7928 • GitHub: https://github.com/worldcoin/world-chain
Informationszusammenstellung, keine Anlageberatung
【Protokollnotizen】Solana will Transaktionen neu bepreisen, die „wirklich Ressourcen verbrauchen“
Heute berichtet CoinDesk: Validatoren unterstützen per Governance-Signal zwei zusammenhängende Vorschläge – SIMD-0553 und SIMD-0550.
Technische Details sind nicht kompliziert, aber entscheidend: 1)Ausgangslage: Die Grundgebühr wird im Wesentlichen nach der Anzahl der Signaturen berechnet; nachdem die Signaturen verifiziert sind, ist der Anteil der Compute-Nutzung an den Basisgebühren nahezu gleich. 2)SIMD-0553: Die Gebühr wird aufgeteilt in „Block-Einfügegebühr + Ressourcen-gebühr“. Die Ressourcen-gebühr richtet sich nach den von der Transaktion beantragten cost units und wird vollständig verbrannt; leichte Transaktionen (z. B. Abstimmungen, Oracle-Updates) könnten dadurch günstiger werden, rechenintensive Transaktionen dagegen teurer. 3)Grob geschätzt anhand der jüngsten On-Chain-Aktivität: Die tägliche Verbrennungsmenge könnte von einem Größenordnungsbereich um etwa 650 SOL auf etwa 7.500–9.000 SOL ansteigen. Selbst dann liegt sie aber deutlich unter der Größenordnung der aktuellen täglichen Netto-Emissionen – allein dadurch würde das Netzwerk also nicht in eine Deflation kippen. 4)SIMD-0550: Beschleunigt die Deflationsrate ungefähr um das Doppelte und verlagert den Zeitpunkt, an dem die Terminals bei etwa 1,5% Inflation liegen, von rund 2032 auf ungefähr 2029.
Aktuell sind beide Vorschlagsdokumente im GitHub-SIMD-Prozess zusammengeführt; ob sie im Mainnet wirksam werden, hängt davon ab, ob die Staking-Signale die Schwelle erreichen, sowie von der anschließenden formellen Abstimmung (Signal-Window etwa bis zum 18.08.).
Kurz gesagt: Das ist Mechanismus-Design – „belegte Scheduling- und Ausführungsressourcen“ werden in die Rechnung geschrieben, statt nur pauschal nach der Anzahl der Signaturen abzurechnen.
Ein paar kalte Fakten zum Hardware-Wallet: Coldcard-Seed-Entropie-Lücke – das Problem liegt nicht darin, dass die Hardware physisch weggenommen wird, sondern darin, dass die Firmware einen falschen Zufallszahlen-Pfad verwendet.
Laut den offiziellen Hinweisen von Coinkite wurde bei der Anbindung an libsecp256k1 / libNgU im Jahr 2021 bei der Seed-Erzeugung fälschlicherweise ein MicroPython-Software-PRNG genutzt. Der Hardware-TRNG wurde nicht wirklich in den Hauptpfad eingespeist. Dadurch wird die effektive Entropie reduziert (offizielle grobe Schätzung: bei Mk2/Mk3 ca. 40 Bit, bei Mk4/Mk5/Q vor dem Fix ca. 72 Bit – in jedem Fall unter der erwarteten 128 Bit). Angreifer können den schwachen Schlüsselraum offline enumerieren, ohne das Gerät direkt zu berühren.
Ermittlungen wie von Galaxy Research zeigen: Die Angriffsadresse wurde in einer Größenordnung von rund 1000+ BTC / ca. 70 Millionen USD ausgeräumt; spätere Wellen summierten sich auf etwa 1300+ BTC / rund 90 Millionen USD (die Statistik wird noch aktualisiert). Offizielle Fix-Firmware ist verfügbar (z. B. Mk3 4.2.0, Mk4/Mk5 5.6.0, Q 1.5.0Q usw.) – und es wurde betont: Updates reparieren keine alten Seeds. Man muss auf der neuen Firmware einen neuen Seed erzeugen und anschließend migrieren. Das Risiko war damals deutlich geringer, wenn mindestens 50 unabhängige Würfel-Entropie verwendet wurde. Das Open-Source-Repository Coldcard/firmware hat am 31.07.–01.08. eine dichte Folge von signierten Commits veröffentlicht.
Technische Beobachtungen in drei Punkten: 1) Auch Open-Source-Hardware-Wallets müssen End-to-End Verifikation von „Symbol-Parsing / tatsächlicher RNG-Aufrufpfad“ leisten; man darf nicht nur darauf schauen, ob TRNG-Code im Binary enthalten ist 2) KI-gestütztes Auditing ist ein zweischneidiges Schwert: Angriffs- und Verteidigungsteams können dadurch gleichermaßen schneller Schwachstellen finden 3) Selbsthosting muss Entropiequelle, Backup, Passphrase und den Prozess der ruhigen/bedachten Migration als erstklassige Bürger behandeln
【Protokoll-Beobachtung】Das XRP Ledger bereitet Funktionen vor, die zweimal wegen Sicherheitsproblemen zurückgezogen wurden. Nach der Reparatur werden sie erneut zur Abstimmung an Validierer übergeben
Laut CoinDesk soll xrpld 3.3.0 voraussichtlich nächste Woche erscheinen und fünf vorgeschlagene amendments mitbringen. Darunter sind Batch (maximal 8 Aufträge in atomaren Cross-Account-Transaktionen) und Permission Delegation (Institutionen können granularere Signaturrechte vergeben, ohne die vollständige Kontrolle abgeben zu müssen) zuvor bereits wegen schwerwiegender Schwachstellen ausgesetzt worden: Beim Ersteren könnte ein Signatur-Validierungsfehler Angreifern ermöglichen, Transaktionen ohne Schlüssel vorzuschicken; beim Letzteren gab es das Risiko von Fee-Weiterreichung bzw. dass Guthaben abgezogen werden. Damals waren die Funktionen noch nicht im Mainnet, es kam zu keinen Verlusten—aber der Prozess ist erwähnenswert: erst zurückziehen, dann fixen, dann abstimmen.
In derselben Version gibt es zudem drei neue Fähigkeiten mit stärkerem Fokus auf Institutionen und Assets: • Confidential MPT: Zero-Knowledge-Beweise + elliptische Kurvenverschlüsselung, damit Mehrzweck-Token-Balancen/Transferbeträge der Öffentlichkeit verborgen bleiben, wobei zugleich ein Prüf-/Compliance-Pfad erhalten bleibt • Sponsored Fees and Reserves: Banken oder Plattformen können XRP-Gebühren und Reserven für Nutzer übernehmen und so die Hürde senken, „zuerst Gas-Token halten zu müssen, um sie nutzen zu können“ • Dynamic MPT: Bei der Emission kann festgelegt werden, welche Token-Eigenschaften später geändert werden dürfen, um das Umziehen kompletter Tokensätze zu reduzieren
Governance-seitig gilt: amendments werden erst aktiviert, wenn verifizierbare Validierer mindestens 80% Unterstützung für zwei aufeinanderfolgende Wochen erhalten—nicht eine einzelne Firma entscheidet. Das Haupt-Repository XRPLF/rippled (C++ Open Source) ist weiterhin aktiv; kürzlich gab es am 1.8. noch einen 3.2.1 Hotfix, und auch die Tests zu Confidential MPT schreiten voran.
Kurz gesagt: Das ist kein „Funktions-Overload“, sondern das erneute Aufrollen früher gescheiterter Sicherheitsannahmen—diesmal mit einer erneuten Prüfung an der Validierer-Schwelle. Ob institutionalisierte und datenschutzorientierte Assets in der Praxis wirklich ankommen, hängt von der Abstimmung und der realen Bereitstellung ab.
Quelle: CoinDesk https://www.coindesk.com/tech/2026/08/01/xrp-ledger-upgrade-brings-back-features-once-pulled-over-critical-bugs Code und Releases: https://github.com/XRPLF/rippled