Polygon hat zwei Schwachstellen in BlockSTM V2 behoben, dem parallelen Ausführungssystem im Bor-Client, der die Polygon-PoS-Blockchain antreibt, die es gültigen Transaktionen ermöglicht hätten, Netzwerk-Nodes zu verlangsamen. Laut der veröffentlichten technischen Überprüfung von Polygon änderten die Fehler keine Transaktionsergebnisse und gefährdeten nicht den Konsens. Ihr Risiko betraf die Verfügbarkeit: Ein Node konnte das korrekte Ergebnis eines Blocks berechnen, brauchte aber so lange für die Verarbeitung, dass er gegenüber dem restlichen Netzwerk ins Hintertreffen geriet. Das Unternehmen veröffentlichte die Ergebnisse gemeinsam mit der öffentlichen Freigabe von Bor v2.10.3, der Client-Version mit den Korrekturen.

Polygon erklärt, keine Kenntnis über Ausnutzungen im Mainnet oder im Amoy-Testnet zu haben.

Warum die zuerst abgeschlossene serielle Ausführung die Verzögerung nicht beendete

Bor verarbeitet eingehende Blöcke durch sowohl serielle als auch parallele Ausführung und übernimmt den jeweils zuerst abgeschlossenen Weg. Die serielle Ausführung folgt der Transaktionsreihenfolge, während die parallele Ausführung versucht, Transaktionen gleichzeitig zu verarbeiten und anschließend zu prüfen, ob die angenommenen Abhängigkeiten korrekt waren. Dieser Ansatz kann gewöhnliche Workloads beschleunigen, wenn Transaktionen nicht voneinander abhängen, erzeugt jedoch auch spekulative Arbeit, die umgehend gestoppt werden muss, sobald sie nicht mehr benötigt wird.

Dieses Design ordnet Bor in die Familie der optimistischen parallelen Ausführungssysteme ein: Der Client nimmt an, dass die meisten Transaktionen unabhängig sind, führt sie nebeneinander aus und zahlt einen Verifikationspreis, wenn sich eine Annahme als falsch herausstellt. Leistungsfehler in solchen Systemen zeigen sich typischerweise als verschwendete Arbeit statt als falsche Ergebnisse, was dem von Polygon beschriebenen Muster entspricht.

Polygons Test mit wiederholtem Code-Hashing legte die Lücke offen. Die serielle Ausführung schloss die Transaktion in wenigen zehn Millisekunden ab, doch der parallele Weg arbeitete etwa 11 Sekunden weiter. Zu diesem Zeitpunkt wurde ein Abbruch nur zwischen Transaktionen geprüft, was bedeutete, dass eine bereits parallel laufende teure Transaktion zu Ende laufen musste, selbst nachdem die serielle Ausführung das Ergebnis geliefert hatte.

Deshalb war der Test von Bedeutung: Die Transaktion war gültig, und Bor konnte ihren Endzustand schnell bestimmen, doch der Node musste dennoch warten, bis die unnötige Verarbeitung endete.

Zwei Fehler erzeugten Arbeit, die Gas nicht vollständig einkalkulierte

Die beiden Schwachstellen gingen von unterschiedlichen Quellen überzähliger Arbeit aus. Eine erlaubte der spekulativen Ausführung, zu viele berechnete Daten vorzuhalten. Die andere berechnete den Code-Hash eines Contracts wiederholt neu, obwohl ein früheres Ergebnis hätte wiederverwendet werden können.

-Limits belasten Nutzer für bestimmte Transaktionsoperationen, erfassen jedoch nicht immer jede Kostenkomponente, die durch die Implementierung eines Clients entsteht. In diesen Fällen konnten Cache-Wachstum und redundantes Hashing node-seitige Arbeit erzeugen, die in keinem Verhältnis zu den scheinbaren Kosten der Transaktion stand.

Polygon stufte beide Fehler als mittlere Schwere ein und erklärte, keiner davon wirke sich auf den Konsens aus. Diese Einstufung passt zum Profil der Funde: Das Risiko waren langsamere Nodes und verschwendete Ressourcen, nicht veränderte Transaktionsergebnisse oder ein beschädigter Konsens.

Was der Bor-v2.10.3-Patch ändert

Die v2.10.3-Korrekturen begrenzen diesen Mehraufwand, ohne Ausführungsergebnisse zu verändern. Das Update begrenzt den gemeinsamen Cache der spekulativen Ausführung und ermöglicht Bor die Wiederverwendung eines Code-Hash-Ergebnisses statt dessen Neuberechnung bei wiederholten Lesevorgängen. Ziel ist es, zu verhindern, dass eine gültige, aber ungünstige Workload übermäßige Ressourcen verbraucht oder die Blockverarbeitungszeit unnötig verlängert.

Laut den Bor v2.10.3 Release Notes erfordert die öffentliche Version weder einen Hard Fork, eine Datenbankmigration noch eine Resynchronisierung der Nodes. Betreiber können ihre Nodes einzeln aktualisieren.

Private Patch-Versorgung ging der öffentlichen Offenlegung voraus

Polygon teilte mit, dass ein privater Build für das Amoy-Testnet am 5. Oktober verteilt wurde, gefolgt von einem privaten Mainnet-Build am 8. Oktober. Die technische Offenlegung wurde am 15. Oktober im Polygon-Governance-Forum veröffentlicht, nachdem die Upgrades den Großteil des Netzwerks erreicht hatten. Eine separate Release-Ankündigung behandelt das Rollout im Mainnet und Testnet.

Den Release Notes zufolge liefen die meisten Validatoren und großen RPC-Anbieter bereits die private Version. Das bedeutet nicht, dass jeder verbundene Node aktualisiert war – weshalb Polygons Betreiber-Ankündigung Nutzer von Bor v2.10.2 oder früher zur baldigen Aktualisierung auffordert. Betreiber, die bereits die privaten Builds einsetzen, können beim nächsten Wartungsfenster auf die öffentliche Version wechseln.

Das verbleibende Thema ist die Patch-Abdeckung

Für Wallets, Anwendungen und andere Dienste können Nodes im Rückstand verzögerte Ketteninformationen liefern oder länger für die Übermittlung von Transaktionen benötigen. Polygons Offenlegung legt nicht dar, dass Nutzer eine solche Störung erlebten, und das Unternehmen erklärt, keine Kenntnis von Ausnutzungen im Mainnet oder Amoy zu haben.

Da v2.10.3 ohne Hard Fork ausgeliefert wird, gibt es keine protokollseitige Frist, die Nachzügler zum Upgrade zwingt; die Übernahme erfolgt nach dem Zeitplan jedes einzelnen Betreibers. Damit ist die Patch-Abdeckung das zu beobachtende Signal: wie schnell Bor-Betreiber auf v2.10.2 oder früher auf die korrigierte Version wechseln.

Polygons breitere Arbeiten an schnellerer Verarbeitung und Zahlungsinfrastruktur machen diese operative Zuverlässigkeit relevant. Der Patch beseitigt die beiden identifizierten Quellen überzähliger Arbeit; der praktische nächste Schritt ist, dass verbleibende Bor-Betreiber ihn anwenden.

Dieser Artikel dient ausschließlich Informationszwecken. Beschreibungen der Schwachstellen und Einschätzungen zur Ausnutzung beruhen auf der veröffentlichten Offenlegung von Polygon.

Quelle: Coindoo