Polygon crypto ha attivato il suo hardfork Giugliano sulla mainnet al blocco 85.268.500 l’8 aprile, mirando a una riduzione misurabile della finalità delle transazioni consentendo ai produttori di blocchi di annunciare i blocchi prima nel ciclo di conferma.
La Polygon Foundation ha confermato l’aggiornamento in un post su X, citando una riduzione dimostrata di 2 secondi nel tempo di finalità durante i test sulla testnet Amoy il mese scorso. Per una rete che ha trascorso gran parte dell’ultimo anno a gestire incidenti di stabilità piuttosto che ad apportare miglioramenti nelle prestazioni, Giugliano rappresenta un cambio deliberato verso throughput e esperienza degli sviluppatori come narrativa principale.
Aggiornamento Giugliano
L’hardfork Giugliano verrà rilasciato sulla mainnet Polygon al numero di blocco 85.268.500, circa alle 14:00 UTC dell’8 aprile.
Questo aggiornamento: consente una finalità più rapida permettendo ai produttori di annunciare i blocchi prima, aggiunge parametri di commissione direttamente nelle intestazioni dei blocchi,…
— Polygon Foundation (@0xPolygonFdn)
Riteniamo che il tempismo di questo aggiornamento sia tanto strategico quanto i suoi meccanismi. Polygon si è impegnata visibilmente a ricostruire la credibilità dopo che un bug di finalità a settembre ha innescato un hardfork per risolvere ritardi nelle transazioni, e una separata uscita di validatori a luglio ha causato un’interruzione della rete di un’ora – entrambi i casi hanno attirato l’attenzione in un momento in cui i network Layer 2 concorrenti stavano guadagnando attenzione tra gli sviluppatori.
Distribuire Giugliano ora, in modo pulito e secondo un programma pubblicizzato, invia un segnale agli integratori istituzionali e agli sviluppatori di dApp che la pipeline di ingegneria di Polygon è funzionante – un segnale che la rete doveva inviare prima che il divario competitivo si ampliasse ulteriormente.
Meccanismi dell’Hardfork Giugliano di Polygon Crypto: cosa cambia davvero nella finalità
L’aggiornamento Giugliano – formalmente documentato come PIP-84 nel forum delle Polygon Improvement Proposals – introduce tre cambiamenti distinti nella catena PoS di Polygon. I produttori di blocchi ora possono annunciare i blocchi prima nella pipeline, comprimendo la finestra tra creazione e conferma del blocco; i parametri delle commissioni sono integrati direttamente nelle intestazioni dei blocchi invece di richiedere una ricerca separata; e nuovi endpoint RPC forniscono dati sulle commissioni in modo più efficiente a wallet e applicazioni che interrogano la rete.
La conseguenza pratica del primo cambiamento è la riduzione di 2 secondi della finalità osservata su Amoy, dove l’aggiornamento è stato eseguito al blocco 35.573.500 il 23 marzo senza incidenti segnalati.
Prima di Giugliano, la finestra di conferma comprendeva una latenza dovuta al ritardo nell’annuncio del produttore; dopo, i produttori trasmettono prima e la catena raggiunge l’accordo più rapidamente. Per i protocolli DeFi ad alta frequenza e le applicazioni di pagamento – i due casi d’uso che Polygon ha esplicitamente prioritizzato nella sua roadmap Gigagas – una riduzione di 2 secondi non è semplicemente cosmetica. È la differenza tra uno strato di regolamento che può competere con i circuiti delle carte e uno che non può.
Promemoria: PIP-85 si attiva su Polygon PoS dal blocco 85.245.000, mentre l’hardfork Giugliano stesso è previsto più tardi al blocco 85.268.500 (~14:00 UTC l’8 aprile).
Cosa cambia con PIP-85:
– i deleganti iniziano a ricevere direttamente entrate dalle commissioni di priorità
– 37% agli staker tramite Ethereum…— Vadim | POLTRACK (@vadim_web3)
Il cambiamento dei parametri delle commissioni comporta un’implicazione più silenziosa ma strutturalmente significativa per gli sviluppatori: integrare i dati delle commissioni nelle intestazioni dei blocchi riduce il numero di chiamate RPC che una dApp deve effettuare per costruire una transazione, riducendo i costi operativi e migliorando la reattività di wallet e interfacce di trading.
Gli operatori dei nodi devono aggiornare a Bor v2.7.0 o Erigon v3.5.0 prima del blocco di attivazione per restare sincronizzati – la Foundation ha indicato esplicitamente questo requisito, e il ciclo della testnet Amoy ha servito come validazione finale prima del deployment sulla mainnet.
Vale anche la pena notare che Giugliano riprende cambiamenti da PIP-66, che erano stati originariamente inclusi nell’hardfork Bhilai precedente ma successivamente annullati dopo problemi comportamentali emersi post-deployment. Il team di Polygon ha revisionato e raffinato quell’implementazione prima di reintrodurla qui – il che significa che Giugliano non è un primo tentativo per questo meccanismo ma una seconda passata corretta, cosa che cambia significativamente il modo in cui dovrebbe essere interpretato il successo su Amoy.
