Due sviluppatori di Ethereum, Leo Glisic e Giulio Rebuffo, hanno presentato domenica proposte concorrenti che delineano strategie distinte per proteggere le applicazioni già distribuite sulla rete. Entrambe affrontano le potenziali conseguenze delle Ethereum Improvement Proposals EIP-8037 ed EIP-8038, che aumenterebbero il gas richiesto per determinate operazioni degli smart contract. La controversia è diventata una questione significativa per Glamsterdam, mentre gli sviluppatori valutano se le modifiche ai prezzi proposte possano essere introdotte senza interferire con i contratti progettati attorno all'attuale schema del gas di Ethereum.

Le modifiche al gas di Glamsterdam sollevano preoccupazioni di compatibilità

Al centro della controversia ci sono EIP-8037 ed EIP-8038, due proposte incluse nell'aggiornamento Glamsterdam pianificato che modificherebbero il costo di creazione dei contratti e l'accesso ai dati memorizzati sulla blockchain. Il gas è l'unità che Ethereum utilizza per misurare le risorse computazionali necessarie per eseguire transazioni e istruzioni degli smart contract, e le modifiche ai prezzi del gas possono alterare il comportamento delle applicazioni, in particolare quando gli sviluppatori hanno programmato i contratti attorno a limiti di esecuzione specifici.

Gli aggiornamenti di Ethereum come Glamsterdam raggruppano più EIP in un'unica modifica coordinata alle regole della rete, e le proposte in genere passano attraverso la revisione degli sviluppatori core, l'implementazione nei client e i test su testnet prima che venga presa una decisione sull'attivazione. L'attuale disputa si svolge all'interno di tale processo: le obiezioni emergono mentre Glamsterdam è ancora in fase di valutazione su testnet, prima che qualcosa raggiunga la blockchain principale.

Con l'EIP-8037, la tariffa base del gas per la creazione di uno smart contract salirebbe da 32.000 a 183.600 gas, con costi aggiuntivi legati all'archiviazione del codice e all'esecuzione applicati separatamente. L'aumento ha sollevato preoccupazioni perché alcune applicazioni Ethereum esistenti sono state sviluppate partendo dal presupposto che determinate operazioni avrebbero continuato a consumare la stessa quantità di gas.

Alcuni contratti allocano una quantità fissa di gas quando interagiscono con altre applicazioni. Se il costo di tali interazioni supera la quantità allocata, le operazioni potrebbero fallire. La posta in gioco è particolarmente alta per gli smart contract che non possono essere modificati dopo il deployment, poiché tali applicazioni potrebbero non avere un meccanismo semplice per adattarsi a uno schema del gas rivisto.

I ricercatori di sicurezza avvertono di interruzioni diffuse dei contratti

Le preoccupazioni hanno già influito sulla tempistica dei test di Glamsterdam. Sebbene l'aggiornamento sia stato distribuito su una rete di test di Ethereum, una seconda esercitazione di testing fissata per il 26 ottobre è stata rinviata a seguito degli avvertimenti dei ricercatori di sicurezza. Le reti di test di Ethereum consentono agli sviluppatori di valutare le modifiche al protocollo prima che raggiungano la blockchain principale, dove le applicazioni e le transazioni coinvolgono attivi reali. Anche gli aggiornamenti precedenti di Ethereum hanno comportato revisioni dello schema del gas, ed è per questo che le proposte di repricing vengono regolarmente verificate rispetto ai contratti scritti in base a presupposti di costo più datati.

Il ricercatore di sicurezza pcaversaccio ha criticato pubblicamente le modifiche ai prezzi del gas proposte, sostenendo che Glamsterdam non dovrebbe procedere nella sua forma attuale.

"imho Glamsterdam should not be shipped in its current form, period," ha scritto pcaversaccio su X.

Il ricercatore ha dichiarato che le preoccupazioni erano state sollevate con gli sviluppatori core di Ethereum due settimane prima.

Anche lo sviluppatore pseudonimo banteg ha messo in discussione l'ampiezza delle valutazioni di compatibilità esistenti, indicando un elenco di circa 200.000 contratti potenzialmente coinvolti nel repository ethereum/repricing-impact. Secondo banteg, i limiti metodologici della valutazione potrebbero significare che un numero di contratti molto più elevato è interessato rispetto a quanto indicato dall'elenco esistente. Lo sviluppatore ha inoltre avvertito che le modifiche proposte potrebbero interferire con il deployment e il funzionamento di diversi protocolli Ethereum di rilievo, anziché interessare solo le applicazioni meno diffuse.

Gli avvertimenti hanno intensificato il controllo su come gli sviluppatori di Ethereum intendono implementare il repricing del gas preservando la funzionalità dei contratti già operanti sulla rete.

L'EIP-8488 propone regole del gas separate per i contratti esistenti e nuovi

La proposta di Glisic, identificata come EIP-8488, introduce un meccanismo di compatibilità che distinguerebbe gli smart contract distribuiti prima dell'aggiornamento da quelli creati successivamente. I contratti esistenti continuerebbero a operare secondo le attuali regole di determinazione dei prezzi del gas di Ethereum, mentre i nuovi contratti distribuiti utilizzerebbero un insieme rivisto di istruzioni che riflette i costi del gas più elevati introdotti da EIP-8037 ed EIP-8038.

La proposta dividerebbe di fatto l'insieme di istruzioni di Ethereum in due versioni, consentendo alle applicazioni più datate di mantenere i propri costi di esecuzione consolidati e richiedendo alle nuove applicazioni di seguire la struttura di prezzi aggiornata.

"Existing contracts keep the legacy schedule," afferma la bozza dell'EIP-8488.

I nuovi contratti sarebbero tenuti a utilizzare gli opcode V2 associati allo schema del gas rivisto. L'approccio mira a ridurre i rischi di compatibilità per le applicazioni che non possono essere aggiornate, consentendo al contempo a Ethereum di introdurre le modifiche pianificate ai prezzi del gas per i deployment futuri.

Una proposta alternativa introduce la doppia contabilità del gas

Rebuffo ha avanzato un meccanismo diverso che applicherebbe il nuovo schema dei prezzi del gas alla fatturazione delle transazioni, preservando il comportamento di esecuzione esistente per gli smart contract più datati. Invece di mantenere insiemi di istruzioni separati per le applicazioni vecchie e nuove, il progetto introdurrebbe due meccanismi di contabilità del gas all'interno di ciascuna transazione. Un contatore monitorerebbe l'esecuzione dei contratti secondo le regole del gas esistenti, mentre un secondo calcolerebbe gli addebiti delle transazioni utilizzando lo schema dei prezzi aggiornato.

Secondo questa struttura, il nuovo schema determinerebbe la commissione di transazione, ma le applicazioni più datate continuerebbero a eseguirsi secondo i presupposti stabiliti dalle precedenti regole del gas. La proposta mira a separare il calcolo dei costi di transazione dalle condizioni di esecuzione da cui dipendono gli smart contract esistenti.

La bozza riconosce tuttavia che il progetto resta non testato a livello di implementazione.

"no execution-client implementation or consensus tests have been run for this design," afferma la proposta.

Gli sviluppatori affrontano decisioni sulle modifiche al gas di Glamsterdam

Le proposte concorrenti evidenziano approcci diversi per risolvere lo stesso problema di compatibilità. L'EIP-8488 di Glisic preserverebbe i prezzi del gas esistenti per i contratti distribuiti in precedenza, introducendo lo schema rivisto tramite nuove istruzioni. L'alternativa di Rebuffo applicherebbe una fatturazione delle transazioni aggiornata mantenendo il comportamento di esecuzione legacy. Entrambi gli approcci cercano di impedire che il repricing del gas pianificato interrompa le applicazioni che si basano sui costi di esecuzione esistenti di Ethereum.

La questione ha attirato l'attenzione perché i contratti coinvolti potrebbero includere protocolli consolidati che non possono facilmente modificare il proprio codice distribuito. Con i test già rinviati a seguito degli avvertimenti di sicurezza, le proposte introducono potenziali soluzioni tecniche per gli sviluppatori che valutano i rischi di compatibilità di Glamsterdam.

Le tappe che farebbero avanzare il dibattito sono concrete: un giro di test sul testnet riprogrammato e condotto con un meccanismo di compatibilità in atto e, se una delle due bozze dovesse progredire, implementazioni nei client di esecuzione e risultati dei test di consenso per valutarla. Fino a quando questi passaggi non avvengono, la questione della compatibilità resta aperta mentre Glamsterdam prosegue nel proprio ciclo di sviluppo.

Le informazioni disponibili non stabiliscono se una delle due proposte sarà adottata. Anche il progetto di Rebuffo resta privo di implementazioni nei client di esecuzione o di risultati dei test di consenso, lasciando la sua fattibilità tecnica soggetta a ulteriore valutazione.

Fonte: CoinDesk

Prima pubblicazione: Hokanews