ETHEREVOLUTION: INSIEME NEL FUTURO

Menu
Home » Codice e sviluppo » CREATE2: a cosa serve la discussa feature introdotta da Constantinople

CREATE2: a cosa serve la discussa feature introdotta da Constantinople

19 Febbraio 2019 15:00
Tempo di lettura: 5 min.
19 Febbraio 2019 15:00
Giuseppe Brogna

Nei giorni passati sono circolate voci sull’opportunità di un ulteriore rimando dell’atteso aggiornamento Constantinople. La causa di quello che si sarebbe potuto rivelare un triplice rinvio, è da rinvenire in CREATE2: un nuovo opcode per la Ethereum Virtual Machine.

Nel nostro articolo che esponeva le novità apportate da Constantinople, l’hard fork veniva descritto come un aggiornamento minore, nel senso che i miglioramenti introdotti non sarebbero stati notati dall’utente medio.

Fondamentalmente, lo scopo di Constantinople è quello di ottimizzare la rete e preparare il terreno per la roadmap di scaling, oltre che ridurre l’emissione di ether da 3 a 2 per blocco. Le Ethereum Improvement Proposal (EIP) programmate, apporteranno piccoli ma significativi miglioramenti all’efficienza del network.

Si ricorderà che lo scorso gennaio Constantinople è stato già rinviato, per via di una potenziale vulnerabilità favorita da una delle EIP in via di introduzione.

La vulnerabilità è stata scovata nell’EIP 1283 che, se implementata, avrebbe potuto concedere a un attaccante la possibilità di sottrarre i fondi degli utenti (“reentrancy attack” simile a quello che afflisse il The Dao nel 2016).

Di recente, invece, si è speculato su un possibile, ulteriore, rinvio di Constantinople, a causa di un potenziale vettore d’attacco derivante dall’implementazione di EIP 1014.

EIP 1014 introduce CREATE2, con l’obiettivo di facilitare la soluzione di scaling basata sugli state channels, permettendo delle interazioni con un contratto che ancora non esiste sulla blockchain.

L’originale funzione CREATE, genera un contratto a un indirizzo ricavato (come hash) dall’indirizzo del creatore e dall’attuale nonce associato all’indirizzo del creatore. CREATE2 crea un contratto a un indirizzo che può essere determinato in anticipo da diverse parti, consentendo di “riservare” un indirizzo di un contratto senza deployarlo sulla mainnet.

Questa nuova funzione di creazione di un contratto è stata proposta da Vitalik nella EIP 1014. Attribuisce agli sviluppatori un livello di controllo sul nuovo indirizzo di contratto generato.

Un articolo pubblicato su Trustnodes, ha parlato dell’opportunità – idea avanzata da Jason Carver della Fondazione Ethereum – di rimuovere la funzione CREATE2, che renderebbe più difficile la verifica del codice.

Secondo quanto riportato, a seguito della implementazione della EIP in discussione, un attore malevolo potrebbe far rivivere un contratto genitore e modificare a piacimento quelli generati da quest’ultimo.

La nuova proposta, consente a uno sviluppatore di cambiare ciò che fa un contratto che riporta la funzione self destruct, facendolo rivivere con regole diverse da quelle seguite in precedenza.

Comunque, su Twitter, Hudson Jameson ha dichiarato che Constantinople sarà implementato secondo i piani, ritenendo non preciso l’articolo pubblicato da Trustnodes.

La discussione sul se considerare CREATE2 più un bug o più una feature, ha ovviamente alimentato la curiosità su quella che sembravava essere una delle tante, poco entusiasmanti, implementazioni tecniche.

A cosa può essere utile questa nuova funzione di creazione di contratto?

L’aspetto importante di CREATE2 risiede nell’opportunità attribuita agli sviluppatori di dApps di generare indirizzi di contratto senza dover effettivamente deployare un contratto.

Sebbene sia stata pensata in origine come una funzione per la scalabilità, CREATE2 può fare molto di più. La funzione è utile nella risoluzione del problema di coinvolgimento di nuovi utenti, nonché nel rendere più efficiente questo processo in termini di gas.

Il problema è che attualmente possono interagire con le dApps solo tecnici o utenti comunque avanzati. L’utente medio non è non grado di farlo agevolmente. E non vorrebbe nemmeno provarci, considerata la barriera all’ingresso cui va incontro.

Un utente che vorrebbe provare a utilizzare una dApp dovrebbe dapprima crearsi un wallet (es. MetaMask), quindi generare una coppia di chiavi privata e pubblica. Dovrebbe poi provvedere a mettere in sicurezza la chiave crittografica. Ma prima di provare la dApp dovrebbe anche registrarsi su un exchange, comprare degli ether e trasferirli sul wallet creato in precedenza. Senza ether non si può pagare il gas per inviare transazioni a uno smart contract.

L’utente medio non utilizzerebbe una DApp, è abituato alla comodità del web2. Per utilizzare Facebook è sufficiente un-email, una password, un click e sei dentro al servizio. Se si smarriscono le credenziali, sono disponibili varie modalità di recupero.

CREATE2 apre la possibilità a soluzioni che consentono agli utenti di effettuare transazioni off chain, dispensandoli dalla necessità di compiere tutta una serie di operazioni preliminari che si risolvono in barriere all’ingresso, come la custodia di chiavi per la conservazione dei fondi.

Allo stesso tempo, CREATE2 aiuta gli sviluppatori di dApps a risparmiare sui costi di gas.

Degli utenti potrebbero interagire con una dApp, senza che abbiano mai avuto a che fare con la blockchain di Ethereum. La dApp potrebbe prevedere il trasferimento di qualcosa agli utenti, come ad esempio dei token non fungibili. Gli utenti avrebbero quindi bisogno di un loro indirizzo, nella forma di un wallet contratto.

Attualmente, chi sviluppa una dApp deve deployare un nuovo smart contract per ogni nuovo utente, anche se poi l’utente non torna più a utilizzare la dApp in questione. Vuol dire dover pagare gas per ogni deploy, ciò che rende non efficiente l’attività di mantenimento della dApp.

Con CREATE2 è possibile predeterminare l’indirizzo dello smart contract senza effettivamente deployarlo e quindi pagare gas. È possibile generare off chain indirizzi di wallet contratto per tutti gli utenti, quindi in modo gratuito.

Possono essere inviati token a questi indirizzi. Quando l’utente è pronto per riscattare i suoi fondi, o token non fungibili, invierà una piccola quantità di ether all’indirizzo del contratto, che saranno utilizzati per pagare le fee.

Se sia più una feature o un potenziale vettore d’attacco, saranno gli sviluppatori a valutarlo. Intanto, come feature, CREATE2 è interessante perché consente di sviluppare soluzioni che favoriscono l’accesso di nuovi utenti al mondo delle applicazioni decentralizzate.



3 VIDEO GRATUITI DALLA DM CRIPTO












Ti invieremo i
VIDEO GRATUITI
e in più, n
elle email successive, il frutto delle nostre ricerche più avanzate sulle criptovalute e i nostri servizi legati ad esse.

Tratteremo i tuoi
dati personali
con la massima cura e in conformità della normativa privacy GDPR UE2016/679. E potrai disiscriverti in qualsiasi momento con un semplice click.


Condividi
  • 10
    Shares

CATEGORIE:

Codice e sviluppo


Giuseppe Brogna

Giuseppe è laureato in giurisprudenza, da sempre appassionato di tecnologia e studioso di tematiche economiche. Stimolato dal potenziale impatto economico e sociale, si approccia al mondo delle DLT; matura particolari interessi nella nuova finanza hitech legata alle tecnologie del ledger distribuito.


Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Condividi questo articolo

Invia questo articolo ad un amico