Come funzionano le proposte di miglioramento di Ethereum (EIP)

Come funzionano le proposte di miglioramento di Ethereum (EIP). Per comprendere appieno la necessità di standard ERC (Ethereum Request for Comments), è necessario comprendere come gli aggiornamenti, gli aggiornamenti e le modifiche al codice avvengono in Ethereum.
Ethereum Improvement Proposals (EIP) descrivono gli standard per la piattaforma Ethereum, comprese le specifiche del protocollo di base, le API client e gli standard contrattuali. Questi sono proposti da qualsiasi membro della comunità di Ethereum e poi discussi internamente.
Solo dopo aver compreso appieno la connessione tra EIP e ERC puoi capire come funzionano gli ERC. Quindi, prima di tutto.
Tipi di EIP
Prima di immergerti in ciò che significa stato EIP, dovresti capire qual è lo scopo di ogni tipo di EIP e perché ce ne sono una grande varietà.
Traccia standard: descrive qualsiasi modifica che interessa la maggior parte o tutte le implementazioni di Ethereum, ad esempio una modifica al protocollo di rete, una modifica delle regole di validità di blocchi o transazioni, standard di applicazioni/convenzioni proposti o qualsiasi modifica o aggiunta che influisce sull'interoperabilità delle applicazioni che utilizzano Ethereum.
Core: si tratta di miglioramenti che richiedono un fork di consenso (come EIP5 e EIP101), nonché di cambiamenti che non sono necessariamente critici per il consenso, ma che possono essere rilevanti per le discussioni “core dev” (ad esempio, la strategia minere/nodo cambia 2, 3 e 4 dell'EIP86).
Networking: Questo include miglioramenti intorno a devp2p (EIP8) e al sottoprotocollo Light Ethereum, nonché miglioramenti proposti alle specifiche del protocollo di rete di Whisper e Swarm.
Interfaccia: Questo si riferisce a miglioramenti intorno alle specifiche e agli standard API/RPC client, e anche a determinati standard a livello di lingua come i nomi dei metodi (EIP6) e gli ABI dei contratti. L'etichetta “interfaccia” si allinea con il repository dell'interfaccia e la discussione dovrebbe avvenire principalmente in quel repository prima che un EIP venga inviato al repository EIP.
ERC: si tratta di standard e convenzioni a livello di applicazione, compresi gli standard contrattuali come gli standard token (ERC20), i registri dei nomi (ERC137), gli schemi URI (ERC681), i formati di libreria/pacchetto (EIP190) e i formati di portafoglio (EIP85).
Meta: Questo descrive un processo che circonda Ethereum o che propone una modifica a (o un evento in) un processo. Gli EIP di processo sono come gli EIP di traccia standard, ma si applicano ad aree diverse dal protocollo Ethereum stesso. Possono proporre un'implementazione, ma non alla base di codice di Ethereum. Spesso richiedono il consenso della comunità. A differenza degli EIP informativi, sono più di raccomandazioni e gli utenti in genere non sono liberi di ignorarli. Esempi includono procedure, linee guida, modifiche al processo decisionale e modifiche agli strumenti o all'ambiente utilizzati nello sviluppo di Ethereum. Qualsiasi Meta EIP è anche considerato un EIP di processo.
Informazioni: questo tipo di EIP descrive un problema di progettazione di Ethereum, o fornisce linee guida generali o informazioni alla comunità di Ethereum, ma non propone una nuova funzionalità. Gli EIP informativi non rappresentano necessariamente il consenso della comunità di Ethereum o una raccomandazione, quindi gli utenti e gli implementatori sono liberi di ignorare gli EIP informativi o seguire i loro consigli.
Condizioni relative allo status EIP
C'è molto da capire se vuoi capire pienamente quali EIP sono implementati, quali ERC sono incorporati su ciascuno e, naturalmente, quali sono finali e live. Gli stati EIP più importanti sono:
Bozza - un EIP che è aperto a prendere in considerazione e sta subendo iterazione rapida e cambiamenti.
Ultima chiamata - un EIP che viene fatto con la sua iterazione iniziale e pronto per la revisione da parte di un vasto pubblico.
Accettato - un EIP di base che è stato in ultima chiamata per almeno due settimane e qualsiasi modifica tecnica che è stata richiesta sono state affrontate dall'autore. Il processo per gli sviluppatori core di decidere se codificare un EIP nei loro client come parte di un hard fork non fa parte del processo EIP. Se tale decisione viene presa, il PEI passerà alla Finale.
Finale (non-core) - un EIP che è stato in Ultima Call per almeno due settimane e tutte le modifiche tecniche che sono state richieste sono state affrontate dall'autore.
Finale (Core) - un EIP che gli sviluppatori core hanno deciso di implementare e rilasciare in un futuro hard fork o è già stato rilasciato in un hard fork.
Ritardato - un PEI che non viene preso in considerazione per l'adozione immediata. Può essere riconsiderato in futuro per una successiva forcella dura.
Nella prossima guida, esaminerò diversi ERC, come funzionano, ci scopo, e i molteplici tipi di standard che ci sono e come possono essere utilizzati.
Restate sintonizzati.