Gli sviluppatori di Ethereum CORE discutono i vantaggi di hard fork più frequenti

Quanto spesso è troppo spesso per alterare il consenso?

Un gruppo di veterani sviluppatori open source di Ethereum ha discusso l'argomento in un incontro quindicinale venerdì, durante il quale hanno ventilato la possibilità che gli aggiornamenti del software a livello di sistema, chiamati anche hard fork, possano essere effettuati anche ogni tre mesi.

Volendo "controllare la temperatura", lo sviluppatore che ha posto la domanda ha spiegato che alcune prossime proposte di miglioramento Ethereum (EIP) come affitti statalirichiederebbe più aggiornamenti sequenziali per ottenere l'effetto completo.

Tre mesi, tuttavia, agli occhi di Joseph Delong, ingegnere informatico senior presso lo studio di capitale di rischio Consensys, sono "troppo QUICK per un'inversione di tendenza".

Il responsabile del team della Fondazione Ethereum Péter Szilágyi è d'accordo, spiegando:

"Come sviluppatore client [software], se il tuo unico lavoro è implementare hard fork e farli, allora tre mesi vanno bene, ma di solito i client richiedono molta manutenzione. Quindi, se inizi a fare hard fork di tre mesi, sostanzialmente sottrarrai tutto il tempo alla manutenzione generale e ai miglioramenti delle prestazioni".

Martin Hoste Swende, responsabile della sicurezza Ethereum Foundation, pur concordando sul fatto che un hard fork ogni tre mesi "sarebbe una cosa negativa", ha osservato che casi particolari con modifiche semplici su cui si concorda all'unanimità potrebbero avere tempi di esecuzione più brevi.

"L'idea non sarebbe quella di programmare un hard fork ogni tre mesi, ma di vedere se la funzionalità X è terminata, se esistono casi di test e se è implementata in tutti i client. Se così fosse, allora potremmo fare un hard fork molto presto", ha sostenuto Swende durante la chiamata.

Ma incoraggiando gli sviluppatori a procedere con i loro piani "ONE passo" alla volta, Fredrik Harryson, CTO di Parity Technologies, ha osservato che non è mai stata rispettata nemmeno una tempistica di sei mesi per un hard fork pianificato Ethereum .

"Ci sono un paio di cose che probabilmente dobbiamo automatizzare per fare [hard fork più brevi] davvero bene. Gran parte del tempo che si impiega nell'hard fork non è solo per creare il codice. È tutto ciò che gira intorno", ha detto Harryson.

Oltre a questo, il consulente della Ethereum Foundation Greg Colvin ha osservato che la maggior parte dei team che sviluppano client software Ethereum non hanno attualmente "la persona giusta" per gestire i lavori essenziali per l'implementazione dell'hard fork come "l'impostazione di testnet, l'esecuzione di casi di test, l'esecuzione di test" tra le altre responsabilità.

A questo, Harryson ha risposto che la questione era la mancanza di fondi sufficienti per assumere tali membri del team. "Per noi, sono soldi. T abbiamo abbastanza soldi per sostenerli", ha scherzato Harryson.

Aggiornamenti in più fasi

Ma non è solo una questione se ci debbano essere o meno hard fork più frequenti.

Durante la chiamata odierna, gli sviluppatori hanno anche discusso se ci fosse la necessità di apportare cambiamenti ambiziosi e a lungo termine all'attuale blockchain di Ethereum alla luce dell'imminente passaggio a Ethereum 2.0, una nuova rete Ethereum alla quale, una volta completamente attivata, gli utenti passerebbero dall'attuale mainnet.

Suggerendo che sviluppatori come Alexey Akhunov e il fondatore Ethereum Vitalik Buterin hanno messo in guardia contro "cambiamenti che T sono per la sopravvivenza della catena [attuale Ethereum]", Harryson ha chiesto:

“Quanto ci allontaniamo da questo perché [EIP 615] porta a una lunga catena di miglioramenti che durano diversi anni prima che ne vediamo enormi benefici.”

EIP 615 è ONE delle cinque proposte considerate per l'inclusione nel prossimo hard fork Ethereum chiamato Istanbul. Mira a introdurre miglioramenti al cuore stesso della base di codice Ethereum nota come Ethereum Virtual Machine (EVM), che è responsabile dell'esecuzione di tutte le linee di codice auto-distribuibili, chiamate anche smart contract, sulla piattaforma.

L'EVM è anche una Tecnologie chiave che altre iniziative blockchain aziendali come Iperregistrosono stati segnalati in passato per realizzare l'interoperabilità con.

"La progettazione dell'EVM rende difficile l'esecuzione a basso costo del gas e ad alte prestazioni. Proponiamo di andare avanti con proposte per risolvere questi problemi rafforzando le garanzie di sicurezza e spingendo i limiti delle prestazioni dell'EVM",scrivegli autori di EIP 615 Colvin, Brooklyn Zelenka, Pawel Bylic e Christina Reitwiessner.

Tuttavia, come sottolineato da Swende durante la chiamata odierna, l'EIP 615 così come proposto richiederebbe almeno due hard fork per essere eseguito completamente e "un effetto positivo sulla velocità" dei calcoli effettivi del codice nell'EVM non sarebbe evidente fino a quando non venisse eseguito l'ultimo hard fork.

"Questa è la mia preoccupazione principale su questo EIP, è un sacco di lavoro ma T credo che porterà a un EVM molto migliore. Potrebbe essere meglio per gli strumenti esterni come se si stesse eseguendo un'analisi inversa delle proprietà di sicurezza di uno smart contract", ha affermato Swende.

Zelenka ha suggerito che tali strumenti siano essenziali per garantire una continua "compatibilità futura" con i prossimi aggiornamenti EVM come eWASM e un'esperienza di onboarding fluida per gli sviluppatori di contratti intelligenti alla luce di "una data di rilascio di Ethereum 2.0 indeterminata".

"Ci sono altre opzioni per gli sviluppatori di smart contract là fuori. Dobbiamo KEEP in vita Ethereum 1.x e questo significa continuare a muoverci", ha sostenuto Zelenka nella chiamata di oggi.

Accettando di continuare il dibattito e la discussione sull'EIP nelle prossime settimane, Swende ha concluso che al momento rimane scettico riguardo "l'implementazione di cambiamenti così grandi nel vecchio motore che sostanzialmente richiede un paio di hard fork prima che si stabilizzi definitivamente".

Ma concordando con il sentimento incerto sul futuro di Ethereum 2.0, Harryson, che ha sollevato la domanda iniziale sugli ambiziosi aggiornamenti multi-hard fork, ha affermato:

"T dovremmo modificare la nostra tabella di marcia o il nostro modo di pensare in base a ciò che Ethereum 2.0 potrebbe o non potrebbe essere."

Immagine della forchetta tramite Shutterstock