Polygon ha corretto due vulnerabilità in BlockSTM V2, il sistema di esecuzione parallela all'interno del client Bor che alimenta la blockchain Polygon PoS, che avrebbero potuto permettere a transazioni valide di rallentare i nodi della rete. Secondo la revisione tecnica pubblicata da Polygon, i bug non hanno modificato i risultati delle transazioni né minacciato il consenso. Il rischio riguardava la disponibilità: un nodo poteva calcolare il risultato corretto di un blocco ma impiegare così tanto tempo a elaborarlo da restare indietro rispetto al resto della rete. L'azienda ha divulgato i risultati insieme al rilascio pubblico di Bor v2.10.3, la versione del client che contiene le correzioni.

Polygon dichiara di non avere conoscenza di sfruttamenti sulla mainnet o sulla testnet Amoy.

Perché il completamento dell'esecuzione seriale non poneva fine al ritardo

Bor elabora i blocchi in arrivo sia tramite esecuzione seriale che parallela, adottando il percorso che termina per primo. L'esecuzione seriale segue l'ordine delle transazioni, mentre l'esecuzione parallela tenta di elaborare le transazioni simultaneamente e poi verifica se le dipendenze presupposte erano corrette. Questo approccio può accelerare i carichi di lavoro ordinari quando le transazioni non dipendono l'una dall'altra, ma crea anche lavoro speculativo che deve interrompersi prontamente una volta che non è più utile.

Questo design colloca Bor nella famiglia dei sistemi di esecuzione parallela ottimistica: il client presume che la maggior parte delle transazioni sia indipendente, le esegue in parallelo e paga un costo di verifica quando un'assunzione si rivela errata. I bug di prestazioni in tali sistemi tendono a manifestarsi come lavoro sprecato piuttosto che risposte errate, il che corrisponde al profilo descritto da Polygon.

Il test di hashing ripetuto del codice di Polygon ha esposto la lacuna. L'esecuzione seriale ha completato la transazione in poche decine di millisecondi, ma il percorso parallelo ha continuato a lavorare per circa 11 secondi. All'epoca, la cancellazione veniva verificata solo tra le transazioni, il che significava che una transazione costosa già in esecuzione in parallelo doveva comunque terminare anche dopo che l'esecuzione seriale aveva prodotto il risultato.

Ecco perché il test era importante: la transazione era valida e Bor poteva determinarne rapidamente lo stato finale, ma il nodo doveva comunque attendere la fine dell'elaborazione non necessaria.

Due difetti creavano lavoro che il gas non prezzava pienamente

Le due vulnerabilità derivavano da fonti diverse di lavoro eccessivo. Una consentiva all'esecuzione speculativa di trattenere troppi dati calcolati. L'altra ricalcolava ripetutamente l'hash del codice di un contratto quando avrebbe potuto riutilizzare un risultato precedente.

I limiti di gas addebitano agli utenti le operazioni di transazione specificate, ma non sempre catturano ogni costo introdotto dall'implementazione di un client. In questi casi, la crescita della cache e l'hashing ridondante potevano generare lavoro lato nodo sproporzionato rispetto al costo apparente della transazione.

Polygon ha classificato entrambi i bug come di gravità media e ha affermato che nessuno dei due influiva sul consenso. La valutazione è in linea con il profilo dei risultati: l'esposizione era costituita da nodi più lenti e risorse sprecate, non da risultati di transazione alterati o consenso danneggiato.

Cosa cambia la patch di Bor v2.10.3

Le correzioni della v2.10.3 limitano tale overhead senza modificare i risultati dell'esecuzione. L'aggiornamento limita la cache condivisa utilizzata durante l'esecuzione speculativa e consente a Bor di riutilizzare un risultato dell'hash del codice invece di ricalcolarlo durante letture ripetute. L'obiettivo è impedire che un carico di lavoro valido ma anomalo consumi risorse eccessive o prolunghi inutilmente il tempo di elaborazione dei blocchi.

Secondo le note di rilascio di Bor v2.10.3, il rilascio pubblico non richiede hard fork, migrazione del database o risincronizzazione del nodo. Gli operatori possono aggiornare i propri nodi individualmente.

La correzione privata ha preceduto la divulgazione pubblica

Polygon ha dichiarato di aver distribuito una build privata per la testnet Amoy il 5 ottobre, seguita da una build privata per la mainnet l'8 ottobre. Ha pubblicato la divulgazione tecnica sul forum di governance di Polygon il 15 ottobre, dopo che gli aggiornamenti avevano raggiunto la maggior parte della rete. Un annuncio di rilascio separato copre il rollout su mainnet e testnet.

Le note di rilascio indicano che la maggior parte dei validatori e dei principali provider RPC eseguiva già la versione privata. Ciò non significa che ogni nodo connesso fosse stato aggiornato, ed è per questo che l'annuncio agli operatori di Polygon sollecita gli utenti di Bor v2.10.2 o versioni precedenti ad aggiornare prontamente. Gli operatori già sulle build private possono passare al rilascio pubblico durante la loro prossima finestra di manutenzione.

Il problema rimanente è la copertura della patch

Per wallet, applicazioni e altri servizi, i nodi che restano indietro possono restituire informazioni sulla catena ritardate o impiegare più tempo a inviare transazioni. La divulgazione di Polygon non stabilisce che gli utenti abbiano subito tali interruzioni, e l'azienda afferma di non essere a conoscenza di sfruttamenti sulla mainnet o su Amoy.

Poiché la v2.10.3 viene distribuita senza hard fork, non esiste una scadenza a livello di protocollo che costringa i più lenti ad aggiornare; l'adozione procede secondo i tempi di ciascun operatore. Questo rende la copertura della patch il segnale osservabile da seguire: la rapidità con cui gli operatori Bor su v2.10.2 o versioni precedenti passeranno alla versione corretta.

Il lavoro più ampio di Polygon su elaborazione più rapida e infrastruttura di pagamento rende tale affidabilità operativa rilevante. La patch rimuove le due fonti identificate di lavoro eccessivo; il passo pratico successivo è che gli operatori Bor rimanenti la applichino.

Questo articolo è fornito solo a scopo informativo. Le descrizioni delle vulnerabilità e le valutazioni di sfruttamento riflettono la divulgazione pubblicata da Polygon.

Fonte: Coindoo