Polygon heeft twee kwetsbaarheden verholpen in BlockSTM V2, het parallelle executiesysteem in de Bor-client die de Polygon PoS-blockchain aandrijft, waarmee geldige transacties netwerkknooppunten hadden kunnen vertragen. Volgens de gepubliceerde technische analyse van Polygon veranderden de fouten de transactieresultaten niet en bedreigden ze de consensus niet. Het risico betrof de beschikbaarheid: een knooppunt kon het juiste resultaat voor een blok berekenen, maar zoveel tijd kwijt zijn aan de verwerking dat het achterop raakte bij de rest van het netwerk. Het bedrijf maakte de bevindingen bekend tegelijk met de publieke release van Bor v2.10.3, de clientversie die de fixes bevat.

Polygon zegt geen kennis te hebben van misbruik op mainnet of de Amoy-testnet.

Waarom het eerder afronden van seriële executie de vertraging niet beëindigde

Bor verwerkt inkomende blokken via zowel seriële als parallelle executie en gebruikt de route die het eerst klaar is. Seriële executie volgt de transactievolgorde, terwijl parallelle executie probeert transacties gelijktijdig te verwerken en vervolgens controleert of de aangenomen afhankelijkheden correct waren. Die aanpak kan normale werkbelastingen versnellen wanneer transacties niet van elkaar afhankelijk zijn, maar het creëert ook speculatief werk dat snel moet worden gestopt zodra het niet langer nuttig is.

Dit ontwerp plaatst Bor in de familie van optimistische parallelle executiesystemen: de client gaat ervan uit dat de meeste transacties onafhankelijk zijn, voert ze naast elkaar uit en betaalt een verificatiekosten wanneer een aanname onjuist blijkt. Prestatiefouten in dergelijke systemen komen doorgaans naar voren als verspild werk in plaats van verkeerde antwoorden, wat past bij het profiel dat Polygon beschreef.

De herhaalde-codehasheringstest van Polygon legde het gat bloot. Seriële executie voltooide de transactie in tientallen milliseconden, maar de parallelle route bleef ongeveer 11 seconden doorwerken. Destijds werd annulering alleen tussen transacties gecontroleerd, wat betekende dat een kostbare transactie die al parallel liep alsnog moest aflopen, zelfs nadat de seriële executie het resultaat had geproduceerd.

Daarom was de test belangrijk: de transactie geldig en Bor kon de eindtoestand snel bepalen, maar het knooppunt moest nog steeds wachten tot onnodige verwerking eindigde.

Twee fouten creëerden werk dat gas niet volledig prijste

De twee kwetsbaarheden ontstonden uit verschillende bronnen van overtollig werk. Eén liet speculatieve executie te veel berekende gegevens behouden. De andere berekende herhaaldelijk de codehash van een contract opnieuw terwijl een eerder resultaat hergebruikt had kunnen worden.

Gaslimieten brengen gebruikers kosten in rekening voor gespecificeerde transactiebewerkingen, maar dekken niet altijd elke kost die door de implementatie van een client wordt geïntroduceerd. In deze gevallen konden cachegroei en overbodige hasjberekeningen knooppuntwerk creëren dat onevenredig was ten opzichte van de schijnbare kosten van een transactie.

Polygon classificeerde beide fouten als gemiddelde ernst en verklaarde dat geen van beide de consensus beïnvloedde. De beoordeling sluit aan bij het profiel van de bevindingen: de blootstelling bestond uit tragere knooppunten en verspilde resources, niet uit gewijzigde transactie-uitkomsten of beschadigde consensus.

Wat de Bor v2.10.3-patch verandert

De v2.10.3-fixes beperken die overhead zonder de executie-uitkomsten te veranderen. De update beperkt de gedeelde cache die tijdens speculatieve executie wordt gebruikt en stelt Bor in staat een codehash-resultaat te hergebruiken in plaats van het opnieuw te berekenen bij herhaalde lezingen. Het doel is te voorkomen dat een geldige maar lastige werkbelasting buitensporige resources verbruikt of de blokverwerkingstijd onnodig verlengt.

Volgens de Bor v2.10.3 releaseopmerkingen vereist de publieke release geen hard fork, databasemigratie of hersynchronisatie van knooppunten. Operators kunnen hun knooppunten afzonderlijk upgraden.

Private patching ging vooraf aan de openbaarmaking

Polygon zei dat het op 5 oktober een privé-build voor de Amoy-testnet distribueerde, gevolgd door een privé-mainnet-build op 8 oktober. Het publiceerde de technische openbaarmaking op het Polygon-governanceforum op 15 oktober, nadat de upgrades het grootste deel van het netwerk hadden bereikt. Een afzonderlijke releaseaankondiging behandelt de uitrol op mainnet en testnet.

De releaseopmerkingen vermelden dat de meeste validators en grote RPC-providers al de privéversie gebruikten. Dat betekent niet dat elk aangesloten knooppunt was geüpgraded, en daarom roept de operatoraankondiging van Polygon gebruikers van Bor v2.10.2 of eerder op om snel te updaten. Operators die al op de privé-builds zitten, kunnen tijdens hun volgende onderhoudsvenster overstappen op de publieke release.

Het resterende punt is patchdekking

Voor wallets, applicaties en andere diensten kunnen knooppunten die achterop lopen vertraagde keteninformatie teruggeven of langer nodig hebben om transacties in te dienen. De openbaarmaking van Polygon stelt niet dat gebruikers dergelijke verstoringen hebben ervaren, en het zegt geen misbruik te kennen op mainnet of Amoy.

Omdat v2.10.3 zonder hard fork wordt uitgebracht, is er geen protocoldeadline die achterblijvers dwingt te upgraden; adoptie verloopt volgens het eigen schema van elke operator. Daarmee is de patchdekking het waarneembare signaal om te volgen: hoe snel Bor-operators op v2.10.2 of eerder overstappen naar de gefixte release.

Het bredere werk van Polygon aan snellere verwerking en betaalinfrastructuur maakt die operationele betrouwbaarheid relevant. De patch verwijdert de twee geïdentificeerde bronnen van overtollig werk; de praktische volgende stap is dat de overige Bor-operators deze toepassen.

Dit artikel wordt uitsluitend ter informatie verstrekt. Kwetsbaarheidsbeschrijvingen en beoordelingen van misbruik weerspiegelen de gepubliceerde openbaarmaking van Polygon.

Bron: Coindoo