Polygon Hard Forks: Austin und Kyoto sichern Netzwerk ab


Polygon Crypto hat zwei koordinierte Hard Forks implementiert: Austin auf Bor v2.10.0 und Kyoto auf Heimdall v0.11.0. Ziel dieser Maßnahmen war es, Risiken in den Bereichen Denial-of-Service (DoS), Ressourcenerschöpfung und Konsenshärtung im Polygon PoS-Client-Stack zu eliminieren. Laut einem Polygon-Forumsbeitrag vom 27. August wurden beide Upgrades zunächst privat ausgerollt und im Amoy-Testnetz validiert, bevor die Aktivierung im Mainnet erfolgte.
Während der Phase, in der Austin die Schwachstellen adressierte, wurden keine Störungen im Mainnet beobachtet. Zum Zeitpunkt der öffentlichen Bekanntgabe waren beide Forks bereits sowohl auf Amoy als auch im Mainnet aktiv. Die Abfolge war hierbei entscheidend: Polygon behob zuerst die Probleme und stellte sicher, dass die Flotte sicher war, bevor die Details zu den behobenen Fehlern veröffentlicht wurden.
ENTDECKEN SIE: Kryptowährungen mit Zukunft
Polygon Crypto: Was Austin und Kyoto konkret bewirken
Austin schloss zwei DoS-Pfade bei der Bor-Blockverarbeitung. State-Sync-Ereignisse, die L1-zu-L2-Bridge-Einzahlungen verarbeiten, führen Vertragscode und Precompiles genau wie gewöhnliche Transaktionen aus. Bisher wurde ihr Gasverbrauch jedoch nicht gegen eine harte Obergrenze pro Block angerechnet. Ein Block mit zu vielen oder besonders rechenintensiven State-Sync-Ereignissen hätte die Verarbeitung so stark verlangsamen können, dass die Chain vorübergehend ins Stocken geraten wäre. Austin führte hierfür eine explizite Gas-Obergrenze pro Block ein.
Die zweite Korrektur durch Austin entfernte das Feld „TxDependency“ aus dem Bor-Wire-Protokoll vollständig. Dieses Feld diente als Hinweis für die parallele Ausführung, besaß jedoch keine Größenbeschränkung. Ein Block-Produzent hätte somit einen beliebig großen Datenblock in einen ansonsten gültigen Geschwister-Block packen und damit jeden Peer, der versuchte, diesen zu verarbeiten, zum Absturz bringen können.
Da die parallele Ausführung nicht darauf angewiesen ist, dass Peers den Hinweisen eines Produzenten vertrauen, hatte die Entfernung des Feldes keine negativen Auswirkungen auf nachgelagerte Prozesse. Die kritischste Korrektur von Kyoto betraf tief verschachtelte „google.protobuf.Any“-Felder in Heimdall-Transaktionen. Ohne eine Begrenzung hätte eine einzige, manipulierte Transaktion alle Validatoren gleichzeitig zu einem unverhältnismäßig hohen Dekodierungsaufwand zwingen können – eine erlaubnisfreie Methode, um das gesamte Validator-Set massiv zu belasten.
Kyoto führte daher einen Pre-Scan auf Byte-Ebene ein, der identisch bei der Aufnahme in den Mempool und auf dem Konsenspfad erzwungen wird. So kann eine Transaktion nicht eine Prüfung bestehen und erst bei der nächsten abgelehnt werden. Darüber hinaus bündelte Kyoto kleinere Härtungsmaßnahmen: eine Obergrenze für Gebühren-Coins, normalisierte Bytes zur Wiederherstellung von Checkpoint-Signaturen, einen idempotenten Umgang mit wiederholten Nachrichten über Ausfallzeiten von Produzenten sowie Milestone-Bereichsvotes, die an den signierten Parent-Hash gebunden sind. Hinzu kamen Kontinuitätsprüfungen für Checkpoint-Fenster und injektive Replay-Keys für L1-Ereignisse.
Alle diese Änderungen sind unterhalb der Fork-Höhe inaktiv, sodass der normale Datenverkehr keine Verhaltensänderungen spürt. Diese Art der mehrschichtigen Validierung spiegelt breitere Bemühungen der Branche wider, Grenzfälle bei der Transaktionsverarbeitung abzusichern, bevor sie ausgenutzt werden können – ähnlich wie Protokolländerungen zum Schutz vor aufkommenden Sicherheitsbedrohungen in anderen Bereichen des Sektors.
Warum Bor und Heimdall beide Patches benötigten
Austin wurde bei Amoy-Block 44.120.000 und Mainnet-Block 91.949.700 aktiviert. Kyoto erreichte die Aktivierung bei Amoy-Höhe 42.252.000 und Mainnet-Höhe 51.533.000. Während Bor für die Blockausführung zuständig ist, übernimmt Heimdall den Konsens. Die Korrekturen von Kyoto erstrecken sich über ABCI, Milestone, Bor, Stake und Bridge-Verarbeitung, was bedeutet, dass der Patch gleichzeitig die Checkpoint-Finalität, die Milestone-Abrechnung und die L1-Event-Replay-Logik betraf.
Bor v2.10.0 ist für alle Nodes obligatorisch; Heimdall v0.11.0 ist für alle Validatoren und Full Nodes zwingend erforderlich. Es handelt sich um reine Binär-Upgrades, bei denen für Betreiber, die bereits auf dem aktuellen Stand sind, keine Statusmigration oder Genesis-Änderung erforderlich ist.
Anders verhält es sich bei Nodes, die nach den Aktivierungshöhen noch mit Pre-Fork-Binärdateien laufen: Diese sind bereits vom kanonischen Konsens abgewichen und müssen upgraden sowie einen Rollback durchführen, um sich neu zu synchronisieren, anstatt nur ein einfaches Update im laufenden Betrieb vorzunehmen.
Koordinierte Client-Upgrades dieser Art sind für jede Hochdurchsatz-Chain mit operationellen Risiken verbunden. Diese Dynamik zeigt sich auch an anderen Stellen, wenn Netzwerke das Statuswachstum und Ausführungsrisiken gegen die Upgrade-Frequenz abwägen, wie etwa in der Debatte um den Glamsterdam-Upgrade-Pfad von Ethereum. Für Polygon PoS ist das Fazit klar: Bei den Schwachstellen handelte es sich um Risiken der Ressourcenerschöpfung und Konsens-Grenzfälle, nicht um Fehler in der Korrektheit, und beide wurden behoben, bevor sie im Mainnet ausgenutzt werden konnten.
ENTDECKEN SIE: Neue Binance-Kryptowährungen