O que é uma Ethereum Improvements Proposals (EIP)?

O EIP ou Ethereum Improvements Proposals, é uma estrutura documental que permite padronizar o desenvolvimento de melhorias dentro do Ethereum, permitindo a qualquer pessoa apresentar as suas propostas e assim melhorar o desenvolvimento desta blockchain.

Unão dos processos mais importantes no desenvolvimento de Ethereum (ETH), ocorre nos conhecidos Propostas de melhorias EIP ou Ethereum. Estes são documentos técnicos nos quais a comunidade de desenvolvimento Ethereum apresenta suas propostas de melhoria para este projeto. Esta é uma ideia que foi adotada a partir da experiência de Bitcoin (BTC), onde existem Propostas de melhorias de bitcoin (BIP), que têm o mesmo propósito e sobre os quais já falamos na Bit2Me Academy.

A razão para a adoção deste modelo organizacional deve-se à demanda por um alto nível de organização nas comunidades de desenvolvimento descentralizadas para gerenciar e decidir sobre as próximas melhorias que serão integradas ao projeto. Desta forma, qualquer desenvolvedor pode apresentar uma proposta de melhoria que será discutida na comunidade e, dependendo do seu impacto, pode ou não estar incluída no protocolo Ethereum.

Para isso, o desenvolvedor da ideia deve explicar detalhadamente sua proposta, argumentar porque sua implementação no projeto é positiva e demonstrar claramente sua viabilidade e impacto. Assim, a criação desses documentos é explícita e tem um objetivo muito claro e definido: propor à comunidade o futuro do projeto e dar a todos a oportunidade de discuti-lo.

Início das propostas de melhorias Ethereum ou EIP

Como mencionamos a ideia por trás da criação das Propostas de Melhorias Ethereum ou EIP, ela vem das experiências aplicadas em Bitcoin. Lembremos que, no Bitcoin, os BIPs têm como objetivo permitir à comunidade mostrar aos demais membros as melhorias que desejam incluir no protocolo Bitcoin. A ideia dos BIPs foi proposta inicialmente por Amir Taaki, que desenhou o protocolo inicial para apresentá-los, criando o Bitcoin BIP-001.

Então o desenvolvedor Luke Dashjr, melhorou essa ideia graças à sua experiência de desenvolvimento em comunidades livres (especialmente, sua experiência no Gentoo GNU / Linux), criando o BIP-002. Desse ponto até o presente, os BIPs têm sido o veículo usado para incluir novos aprimoramentos no Bitcoin.

A ideia foi tão bem-sucedida que foi replicada em outras criptomoedas, e Ethereum não escapou dela. É assim que em 27 de outubro de 2015, o EIP-001, criado por Martin Becze e Hudson Jameson, dois grandes desenvolvedores do Ethereum. No referido EIP, pode ser lido o seguinte título:

Objetivo e Diretrizes EIP

Ou seja, este primeiro EIP estabeleceu as linhas gerais e a finalidade do que seriam os EIPs dentro do Ethereum. Na verdade, sua introdução não poderia ser mais clara a esse respeito:

EIP significa Proposta de Melhoria Ethereum. Um EIP é um documento de design que fornece informações para a comunidade Ethereum, ou que descreve um novo recurso para Ethereum ou seus processos ou ambiente. O EIP deve fornecer uma especificação técnica concisa do recurso e uma justificativa para isso. O autor do EIP é responsável por criar consenso dentro da comunidade e documentar opiniões divergentes.

Classificação EIP

Tal como acontece com os BIPs do Bitcoin, os EIPs da Ethereum respeitam uma série de classificações que especificam para onde vão as melhorias apresentadas. Nesse caso, a classificação Ethereum EIP é dividida em três classes que são:

Padrão EIP

Esses EIPs são usados para descrever as mudanças que afetam a maioria ou todas as implementações Ethereum. Lembremos que Ethereum é um protocolo, e sua implementação oficial é dada no software Gethin. Mas, como este software, existem outras implementações como a que podemos ver em Hyperledger Besu o Paridade.

As melhorias descritas em um EIP do tipo Padrão, geralmente incluem mudanças no protocolo de rede ou uma mudança nas regras de validação de bloqueio ou transação. Também se aplica a alterações de padrões de aplicativos propostas ou quaisquer alterações ou adições que afetam a interoperabilidade de aplicativos. Assim, os EIPs do tipo Standard são os que têm maior abrangência no desenvolvimento do Ethereum.

Além disso, os EIPs do tipo padrão são divididos nas seguintes subcategorias:

Básico- Nesta subcategoria estão os EIPs que buscam melhorias que requerem uma mudança de consenso dentro do Ethereum. Um bom exemplo desses EIPs são EIP-005 e EIP-0101). No entanto, os aprimoramentos em que as alterações não são necessariamente críticas para o protocolo de consenso também estão incluídos. Um exemplo deste último pode ser visto em EIP-086 e EIP-090.
networking: esta subcategoria inclui melhorias em torno do devp2p (EIP-8) e do protocolo de rede, isso inclui as melhorias propostas para as especificações do protocolo de fofoca e enxame de Ethereum.
Interface: Esta subcategoria inclui aquelas melhorias nas especificações e padrões de API / RPC do cliente Ethereum. Além disso, as alterações no nível de ABI e API do mesmo também estão incluídas. Um bom exemplo desses EIPs pode ser visto no EIP-006.
ERC- Padrões e convenções de nível de aplicativo, incluindo padrões de contrato como; padrões de tokens (ERC-20, ERC-721 y ERC-1155), registros de nomes (ERC-26, ERC-137), esquemas de URI (ERC-67), formatos de biblioteca / pacote (EIP-82) e formatos de carteira (EIP-75, EIP-85).

Objetivo EIP

A outra classificação de EIPs é conhecida como Meta EIPs. Esses EIPs descrevem um processo em torno do Ethereum ou propõem uma mudança nele. Esses EIPs geralmente propõem mudanças em uma implementação, mas não na base de código do Ethereum. Freqüentemente, isso exige consenso da comunidade; ao contrário dos EIPs informativos, os usuários não são livres para ignorá-los.

Um bom exemplo desse tipo de EIP pode ser visto nas mudanças de procedimentos e diretrizes no processo de tomada de decisão e nas mudanças nas ferramentas ou ambiente utilizado no desenvolvimento do Ethereum. Qualquer EIP de objetivo também é considerado um EIP de processo.

Informativo

Um EIP informativo descreve um problema de design do Ethereum ou fornece orientações gerais ou informações para a comunidade do Ethereum, mas não propõe um novo recurso. Os EIPs informativos não representam necessariamente o consenso ou recomendação da comunidade Ethereum, portanto, os usuários e implementadores são livres para ignorar os EIPs informativos ou seguir seus conselhos.

Como funcionam as propostas de melhorias Ethereum ou EIP

A operação dos EIPs é claramente definida no EIP-001. Este processo começa com o processo de geração da ideia ou proposta pelo autor do EIP. Nesse ponto, a responsabilidade pelo desenvolvimento começa no autor, cabendo a ele apresentar os argumentos necessários para demonstrar a necessidade de sua proposta, bem como defendê-la. Por isso, o autor do EIP deve criar uma ideia claramente explicada e apresentá-la no corpo do EIP, juntamente com uma justificativa e elementos que embasem sua apresentação.

Assim, neste ponto temos as seguintes etapas:

Como funcionam as propostas de melhorias Ethereum ou EIP

Assim, neste ponto temos as seguintes etapas:

Primeira etapa: Apresentação da ideia

É o estágio mais básico e não polido de um EIP. É basicamente apresentar a atualização como uma sugestão nos fóruns do Ethereum. O objetivo é obter feedback da comunidade, para dar continuidade ou não ao desenvolvimento da proposta de forma mais elaborada.

Segunda etapa: Criação do rascunho

Neste ponto, a ideia já está incorporada e executada seguindo os parâmetros organizacionais esperados de um EIP. É um trabalho em andamento ativo, no qual você pode enviar solicitações de acompanhamento com outras alterações em seu rascunho até o ponto em que você acha que o EIP está maduro e pronto para passar para o próximo estado.

Terceira etapa: última chamada

Neste ponto, o rascunho corrigido é apresentado no site EIPS Ethereum. A ideia desta etapa é apresentar o EIP ao maior número de pessoas da comunidade, fazer correções e criar uma implementação totalmente funcional e revisada do EIP.

Quarta etapa: Aceitação

Este status indica que as mudanças materiais são improváveis e os desenvolvedores do cliente Ethereum devem considerar este EIP para inclusão. Seu processo para decidir se deve modificá-lo em seus clientes como parte de um hard fork não faz parte do processo EIP. Este status é aplicável apenas a EIPs para processos centrais de blockchain.

Quinto estágio: Apresentação final

Este ponto representa um estado em que o EIP só deve ser atualizado para corrigir erros de impressão. Além disso, outros status podem ser marcados como:

Ativo: Em alguns EIPs informativos e de processo, eles também podem ter um status de "Ativo" se nunca forem concluídos.
abandonado: Os autores originais não procuram mais implementar este EIP ou pode não ser mais uma opção (tecnicamente) preferida.
Rejeitado: Um EIP que está fundamentalmente quebrado ou um EIP principal que foi rejeitado pelos Core Devs e não será implementado.
Substituído: Um EIP que era anteriormente Final, mas não é mais considerado de ponta. Outro EIP estará no estado Final e fará referência ao EIP Substituído.

Formato de uma Proposta de Melhorias Ethereum ou EIP

Obviamente, as Propostas de Melhorias Ethereum ou EIPs, por serem documentos técnicos, têm um formato de apresentação padrão que indica claramente todas as informações necessárias para a compreensão da melhoria por ela proposta. Assim temos que o formato EIP contém as seguintes linhas:

Preâmbulo. Esta é a introdução ao EIP. Eles são formatados de acordo com o guia de estilo estabelecido pela norma RFC 822. Este preâmbulo inclui todos os dados básicos do EIP, como o seu número, o seu autor, o nome e uma breve descrição.
Resumo. Neste ponto, encontraremos uma breve descrição (não mais do que 200 palavras) do problema técnico que está sendo tratado no EIP.
Motivação. Este ponto é opcional e só deve ser obrigatório se você quiser alterar o protocolo Ethereum. Neste ponto, o autor do EIP deve explicar claramente por que a especificação do protocolo existente é inadequada para resolver o problema que o EIP resolve. Submissões de EIP sem motivação convincente neste ponto podem ser rejeitadas inteiramente.
especificação. Neste ponto, o autor do EIP deve criar e explicar a sintaxe e a melhoria que está propondo. Deve ser claro e conciso, demonstrável e reproduzível. Se a especificação não respeitar esses princípios, ela será simplesmente rejeitada.
Justificação. A justificação desenvolve a especificação descrevendo o que motivou o projeto e por que determinadas decisões de projeto foram tomadas. Deve descrever projetos alternativos que foram considerados e trabalhos relacionados. A justificativa também pode fornecer evidências de consenso dentro da comunidade e deve abordar objeções ou preocupações importantes levantadas durante a discussão.
Compatibilidade com versões anteriores. Todos os EIPs que apresentam incompatibilidades com versões anteriores devem incluir uma seção que descreve essas incompatibilidades e sua gravidade. O EIP deve explicar como o autor se propõe a abordar essas inconsistências. Submissões de EIP sem um tratado de compatibilidade com versões anteriores podem ser rejeitadas inteiramente.
Casos de teste. Os casos de teste para uma implementação são necessários para EIPs que afetam as mudanças de consenso. Outros EIPs podem optar por incluir links para casos de teste, se aplicável.
Implementações. As implantações devem ser concluídas antes que qualquer EIP receba o status "Final", mas não precisam ser concluídas antes que o EIP seja mesclado como um rascunho. Embora a abordagem de chegar a um consenso sobre a especificação e a justificativa antes de escrever o código tenha mérito, o princípio de “consenso geral e execução do código” ainda é útil quando se trata de resolver muitos argumentos sobre os detalhes da API.
Considerações de segurança. todos os EIPs devem conter uma seção discutindo implicações/considerações de segurança relevantes para a mudança proposta. Inclua informações que possam ser relevantes para discussões de segurança, riscos superficiais e que possam ser usadas durante todo o ciclo de vida da proposta. Por exemplo. Eles incluem decisões de design relevantes para a segurança, preocupações, discussões importantes, orientações e armadilhas de implementação específicas, um resumo de ameaças e riscos e como eles estão sendo tratados. Os envios de EIP ausentes na seção "Considerações de segurança" serão rejeitados. Um EIP não pode passar para o estado "Final" sem uma discussão das considerações de segurança que os revisores considerem suficientes.
Isenção de direitos autorais. Todos os EIPs devem ser de domínio público.

Algumas propostas importantes de melhorias Ethereum ou EIPs

Embora você possa ver todos os EIPs clique aquiAqui explicamos alguns dos EIPs mais importantes.

EIP-606: Objetivo Hard Fork: Homestead

El EIP-606 é um EIP do tipo Meta. Isso descreve todos os pontos necessários para realizar a atualização de Homestead no Ethereum. Sendo um EIP do tipo Meta, refere-se a outros EIPs que explicam todas as alterações que serão feitas. Nesse caso, o EIP-606 invoca os seguintes EIPs:

EIP-2: Alterações Hard-fork de Homestead
EIP-7: CHAMADA DE DELEGAÇÃO
EIP-8: Requisitos de compatibilidade futura devp2p para Homestead

Cada um desses EIPs explica individualmente as mudanças que serão feitas e, juntos, levam à atualização de Homestead.

EIP-20: Padrão de Token ERC-20

El EIP-20 é talvez um dos EIPs mais conhecidos no mundo de Ethereum, uma vez que foi criado para implementar o conhecido Token padrão ERC-20. Este desenvolvimento marcou o início para a Ethereum criar uma ferramenta padrão para implantar tokens em seu blockchain. Como resultado, Ethereum se tornou o blockchain com o maior número de tokens que existe hoje.

EIP-137: Ethereum Domain Name Service - Especificação

El EIP-137 deu origem à especificação do sistema de nomes de domínio Ethereum. A partir daqui, toda a infraestrutura necessária seria criada para que o Ethereum possa se tornar um gigantesco serviço de nomes de domínio (DNS) completamente descentralizado e focado na privacidade. Mas não só isso, também permitiria associar um endereço legível a um endereço criptográfico para receber e enviar criptomoedas com ele. Este trabalho resultou no Estamos.

EIP-721: Padrão de Token Não Fungível ERC-721

El EIP-721 é outro EIP amplamente conhecido porque ele mesmo criou o padrão para os tokens não fungíveis do Ethereum, o ERC-721. Deste token, projetos como CryptoKitties nasceram.

EIP-779: Alvo Hard Fork: DAO Fork

Este é talvez o EIP mais controverso do Ethereum. o EIP-779 Ele foi responsável por "consertar" o problema do hack multimilionário do DAO. Para fazer isso, o EIP reescreveu toda a história do blockchain Ethereum momentos antes de o DAO ser hackeado.
Isso com o objetivo de devolver os fundos roubados aos seus proprietários. Como resultado da aplicação deste hard fork, Ethereum foi dividido em duas comunidades, cada uma com seu próprio blockchain. Aquele que aplicou o patch (Ethereum) e o que não aplicou (Ethereum Classic).

EIP-1155: Padrão de vários tokens

El EIP-1155 Também conhecido como token ERC-1155, é um EIP do tipo padrão que visa projetar um novo tipo de token, que reúne as capacidades dos tokens ERC-20 e ERC-721 no mesmo padrão. Desta forma, os tokens ERC-1155 têm propriedades fungíveis e não fungíveis.

EIP-1559: Alteração de mercado de taxas ETH 1.0

Este EIP visa mudar a forma como as comissões são tratadas dentro da rede. Para isso, o EIP-1559 cria um mecanismo de queima de comissão que evita que o Ethereum tenha uma inflação mais alta e, ao mesmo tempo, expande ou reduz a capacidade dos blocos do Ethereum de incluir mais transações para diminuir o congestionamento da rede.