Preise werden geladen…
🔥BULLISH

Polygon: Dringendes Node-Upgrade nach Austin-Hardfork nötig

Veraltete Bor- und Heimdall-Nodes sind bereits vom kanonischen Konsens abgekoppelt, daher ist ein Resync der einzige Weg zurück. Die offengelegten Risiken zeigen, warum zeitnahes Patchen entscheidend war.

Polygon Labs hat Node-Betreiber mit Pre-Hardfork-Binaries zu einem sofortigen Upgrade aufgefordert, nachdem das Sicherheits-Review vom 27. August bestätigte, dass Bor-Nodes unterhalb v2.10.0 und Heimdall-Nodes unterhalb v0.11.0 nicht mehr dem kanonischen Konsens folgen. Austin wurde auf der Execution-Client-Seite beim Mainnet-Block 91.949.700 aktiviert, Kyoto für die Konsens-Schicht auf Höhe 51.533.000 am 18. August um 10:10:31 UTC.

Warum es zählt

Austin schloss zwei Pfade zur Ressourcen-Erschöpfung in Bor. Der erste deckelt das Gas, das Bor bei der Verarbeitung von State-Sync-Events aus L1-to-L2-Bridge-Deposits verbraucht, da diese Aufrufe zuvor außerhalb des Gas-Limits des Blocks liefen und die Verarbeitung blockieren konnten, wenn genügend Events eingingen. Der zweite entfernte das TxDependency-Extra-Data-Feld in Bor, nachdem Forscher zeigten, dass ein Producer ein überdimensioniertes Blob in das Feld stopfen und Peer-Nodes beim Verarbeiten eines Geschwister-Blocks zum Absturz bringen konnte. Polygon erklärte, keine Mainnet-Störungen durch Austin beobachtet zu haben, und ordnete die Änderungen als proaktive Fixes ein.

Kyotos Fix mit der höchsten Schweregradstufe fügte in Heimdall eine Byte-Level-Nesting-Prüfung auf google.protobuf.Any-Nachrichten hinzu und schloss damit einen Vektor, über den eine einzelne günstige Transaktion jeden Validator zu hohem Decode-Aufwand zwingen konnte. Kyoto deckelt außerdem Fee-Coin-Listen vor einem O(n)-Validation-Scan (Heimdall erlaubt einen Fee Coin), normalisierte Checkpoint-Signature-Recovery-Bytes, sodass eine gültige Signatur auf Ethereum nicht bei der Recovery scheitern kann, machte wiederholte Producer-Downtime-Nachrichten idempotent, band Milestone-Range-Votes an den signierten Parent-Hash, verhinderte, dass fehlgeschlagene Future-Span-Creations das Milestone-Commitment blockieren, und machte Replay-Keys für Topup-, Clerk- und Stake-Events injektiv über out-of-range Log-Indizes hinweg. Eine zuvor gemeldete einstündige RPC-Störung wurde auf einen Heimdall-Hotfix im selben Code-Pfad zurückgeführt.

Marktauswirkung

Beide Hardforks sind reine Binary-Upgrades ohne State-Migration oder Genesis-Änderung, sodass Nodes, die planmäßig aktualisiert haben, nichts tun müssen. Betreiber, die die relevante Höhe auf einem älteren Client bereits überschritten haben, müssen das entsprechende Release installieren, bei Bedarf auf einen Pre-Hardfork-Block zurückrollen und nach Polygon-Vorgaben neu synchronisieren.

Häufig gestellte Fragen

  1. Was müssen Node-Betreiber nach den Hardforks Austin und Kyoto tun?

    Betreiber mit Bor unterhalb v2.10.0 oder Heimdall unterhalb v0.11.0 müssen das aktuelle Release installieren, bei Bedarf auf einen Pre-Hardfork-Block zurückrollen und nach Polygon-Vorgaben neu synchronisieren. Nodes, die bereits planmäßig aktualisiert haben, müssen nichts tun.

  2. Wann wurden Austin und Kyoto auf dem Polygon-PoS-Mainnet aktiviert?

    Austin wurde auf der Execution-Client-Seite bei Block 91.949.700 aktiviert. Kyoto wurde auf Höhe 51.533.000 am 18. August um 10:10:31 UTC für die Konsens-Schicht aktiviert. Beide Aktivierungshöhen liegen nun in der Vergangenheit.

  3. Was hat der Hardfork Austin in Polygon PoS behoben?

    Austin deckelt das Gas, das Bor bei der Verarbeitung von State-Sync-Events aus L1-to-L2-Bridge-Deposits verbraucht, und entfernte das TxDependency-Extra-Data-Feld ohne Größenlimit, mit dem ein Producer Peer-Nodes durch ein überdimensioniertes Blob zum Absturz bringen konnte. Polygon stufte beide als…

  4. Was war Kyotos Fix mit dem höchsten Schweregrad?

    Kyoto fügte in Heimdall eine Byte-Level-Nesting-Prüfung auf google.protobuf.Any-Nachrichten hinzu und schloss damit einen Vektor, über den eine einzelne günstige Transaktion jeden Validator zu hohem Decode-Aufwand zwingen konnte. Eine zuvor gemeldete einstündige RPC-Störung wurde auf einen Hotfix im selben Code-Pfad…

  5. Erfordern diese Hardforks eine State-Migration oder einen Resync von Grund auf?

    Nein. Beide sind reine Binary-Upgrades ohne State-Migration oder Genesis-Änderung. Nodes, die nicht divergiert sind, benötigen keinen Resync. Betreiber, die die relevante Höhe auf einem älteren Client bereits überschritten haben, müssen jedoch zurückrollen und nach Polygon-Vorgaben neu synchronisieren.

Quellenangabe
Aggregiert von CryptoSlate · Verifiziert · Zuletzt aktualisiert vor 4h
Original öffnen →