Polygon Bor v2.10.3: Stiller Sicherheits-Patch behebt kritische Konsens-Logik
Polygon veröffentlicht mit Version 2.10.3 einen Sicherheits-Patch für Nodes. Ein stiller Vorab-Rollout wirft Fragen zur Transparenz auf.
Am Donnerstag veröffentlichten die Entwickler des Polygon-Netzwerks die Bor-Version 2.10.3. Das Update folgt auf die Version 2.10.2 und trägt offiziell das Etikett eines Sicherheits- und Stabilitäts-Releases. Die Bereitstellung erfolgte allerdings nicht aus dem Nichts.
Das Team bestätigte in der offiziellen Ankündigung, dass es sich bei dem Patch um die öffentliche Freigabe einer internen Version namens „v2.10.3-priv“ handelt. Diese private Version lief laut Angaben der Entwickler bereits vorab auf den Systemen der meisten Validatoren und der großen RPC-Provider.
Ein klassisches Muster mit offenen Fragen
Dieses Vorgehen ist ein bekanntes Muster in der Krypto-Industrie, wenn es um kritische Fehler geht. Entwickler verteilen den Fix stillschweigend an die wichtigsten Infrastruktur-Betreiber, um das Netzwerk abzusichern, bevor die Lücke öffentlich ausgenutzt werden kann. Ähnliche Notfall-Patches ohne vorherige Ankündigung kennen wir bereits aus dem Ethereum-Ökosystem.
Welcher Bug diesen koordinierten Schritt bei Polygon ausgelöst hat, lassen die Entwickler offen. Es existiert keine offizielle Schwachstellenbeschreibung (CVE-Nummer) und auch kein Security Advisory. Unbeantwortet bleibt, wann genau die private Version verteilt wurde, wie lange diese Phase lief und welche RPC-Provider konkret involviert waren. Das Team äußert sich nicht dazu, ob die Lücke bereits aktiv ausgenutzt wurde oder ob das Update für Node-Betreiber verpflichtend ist.
Ein Blick auf die Code-Änderungen zeigt, wo das Risiko gelegen haben könnte. Der Patch mit der Nummer 2403 verändert die Ausführungslogik, die für den Konsens des Netzwerks entscheidend ist. Parallele Lesezugriffe auf Kontostände über die BlockSTM-V2-Architektur werden nun korrekt über eine sogenannte Self-Destruct-Grenze hinweg aufgelöst. Ob der bisherige, fehlerhafte Zustand zu abweichenden Blockchains (Chain-Divergenz) oder falschen Kontoständen hätte führen können, bleibt unklar.
Massive Beschleunigung beim Neustart
Abseits der Sicherheitsaspekte bringt das Update weitreichende technische Überarbeitungen, die vor allem die Effizienz der Nodes steigern. Das Update erfordert nach Selbstauskunft keinen Hardfork, keine Änderung des Datenbankschemas und keine Neusynchronisation (Resync). Betreiber können ihre Nodes einzeln und in beliebiger Reihenfolge aktualisieren.
Die auffälligste Verbesserung betrifft die Ladezeit. Der sogenannte Storage Trie Preload nutzt ab sofort eine segmentierte Warteschlange. In Kombination mit einem optionalen Speicher-Cache sinkt die Ladezeit für den Vorabruf auf einem Mainnet-Sentry-Node massiv: Ein Vorgang, der bisher etwa eine Stunde und 25 Minuten dauerte, läuft nun in rund vier Sekunden ab.
Der Speicherverbrauch unter hoher Last durch kryptografische Operationen (Keccak oder Ecrecover) geht ebenfalls zurück. Erreicht wird dies durch eine Größenbegrenzung der geteilten Block-Caches und die Zwischenspeicherung von Code-Hashes auf Transaktionsebene. Das Zählen von Logs während des Tracings kopiert nun keine Logs mehr, was weitere Ressourcen schont (PR #2460).
Neue Regeln für Verbindungen und Transaktionen
Das Update ordnet die Verwaltung von Verbindungen im Hintergrund neu. Statische Peers bleiben nun auch über Sperren (Jails) und volle dynamische Slots hinweg verbunden und werden von der automatischen Trennung ausgenommen (PR #2438). Beim sogenannten RPC-Protokoll wird der Ausführungsslot zwischen Batch-Elementen neu erworben, und das System wendet den in der Konfiguration hinterlegten Timeout-Wert für den RPC-Ausführungspool strikt an.
Gefilterte Adressen greifen fortan auch für Autorisierungen zur Code-Setzung (Type 4). Die Software tauscht den Pool-Signer nicht mehr aus, wenn ungeschützte Transaktionen explizit erlaubt sind (PR #2464). Die zugrunde liegende Go-Toolchain hebt das Team auf die Version 1.26.8 an. Der Release-Kandidat wurde von dem Entwickler „@marcello33“ unter dem Pull-Request 2492 eingereicht.
Konfigurations-Änderungen im Detail
Node-Betreiber müssen bei ihren Einstellungen aufpassen. Vor allem beim Heimdall-Client griff eine Konfigurationsregel bislang nicht.
| Parameter | Änderung und Auswirkung |
|---|---|
[heimdall] timeout | Der Wert wurde laut Team bisher ignoriert, greift aber nun (PR #2411). Der Standard liegt bei 30 Sekunden. Betreiber mit explizit niedrigen Werten aus älteren Vorlagen (oft 5 Sekunden) sollen diese entfernen oder auf 30 Sekunden erhöhen. |
[txpool] strandedlifetime | Neuer Parameter, standardmäßig aktiv (3 Stunden). Ausstehende Transaktionsketten hinter einem nicht minbaren Head verfallen nach Ablauf dieser Zeit in der Txpool. Der Wert 0 deaktiviert die Funktion. |
[cache] addresscachepersist | Neuer Parameter, standardmäßig deaktiviert (false). Sichert den Address-Cache über Neustarts hinweg. Erfordert auf dem Mainnet rund 9 Gigabyte Speicherplatz. |
Die Perspektive für Anleger
Bist du ein normaler POL-Halter und betreibst keinen Node, verlangt diese Nachricht keine direkte Aktion von dir. Sie liefert jedoch einen echten Einblick in die Netzwerksicherheit. Das Polygon-Team hat offensichtlich eine kritische Konsens-Logik repariert und den Fix zuerst hinter verschlossenen Türen mit den großen Akteuren ausgerollt.
Ein solches Vorgehen schützt zwar das Netzwerk und damit den Wert deiner Token vor akuten Angriffen. Es zeigt aber auch die Zentralisierung in der Krisenbewältigung. Wenn die Gefahr gebannt ist, gehört ein sauberes Security Advisory zum Branchenstandard. Dass die Entwickler die genauen Auswirkungen des Bugs im Nachhinein nicht dokumentieren, nimmt dir als Anleger die Möglichkeit, das tatsächliche Risiko für deine Bestände rückwirkend einzuschätzen.
Quellen
- Polygon Bor v2.10.3 Release Notes
