¿Qué es un Ethereum Improvements Proposals (EIP)?

11 de junio de 2021 rssfeed

Uno de los procesos más importantes dentro del desarrollo de Ethereum (ETH), tiene lugar en los conocidos EIP o Ethereum Improvements Proposals (Propuesta de Mejora de Ethereum). Estos son documentos técnicos en los que la comunidad de desarrollo de Ethereum realiza sus propuestas de mejoras para este proyecto. Esta es una idea que fue adoptada de la experiencia de Bitcoin (BTC), donde existen los Bitcoin Improvements Proposals (BIP), los cuales tienen el mismo fin y de los cuales hemos hablado ya en Bit2Me Academy.

La razón para adoptar este modelo de organización es debido a la exigencia de un alto nivel de organización en las comunidades descentralizadas de desarrollo para manejar y decidir las próximas mejoras que se integrarán al proyecto. De esta manera, cualquier desarrollador puede presentar una propuesta de mejora que será discutida en la comunidad, y dependiendo de su impacto, esta puede o no ser incluida dentro del protocolo de Ethereum.

Para ello, el desarrollador de la idea debe explicar detalladamente su propuesta, argumentar porqué es positiva su implementación en el proyecto, y demostrar claramente su viabilidad e impacto. De allí que la creación de estos documentos sea explícita y tenga un objetivo bien claro y definido: proponer ante la comunidad el futuro del proyecto y darles la oportunidad a todos para discutirlo.

Inicio de los Ethereum Improvements Proposals o EIP

Tal como mencionamos la idea detrás de la creación de los Ethereum Improvements Proposals o EIP, proviene de las experiencias aplicadas en Bitcoin. Recordemos que, en Bitcoin, los BIP tienen como objetivo permitir a la comunidad mostrar al resto de miembros mejoras que se desean incluir en el protocolo de Bitcoin. La idea de los BIP fue propuesta inicialmente por Amir Taaki, quien diseño el protocolo inicial para presentar los mismos, creando el BIP-001 de Bitcoin.

Luego, el desarrollador Luke Dashjr, mejoró esta idea gracias a su experiencia de desarrollo en comunidades libres (en especial, su experiencia en Gentoo GNU/Linux), creando el BIP-002. Desde ese punto hasta la actualidad, los BIP han sido el vehículo que se ha usado para incluir nuevas mejoras dentro de Bitcoin.

La idea tuvo tal éxito, que se replicó en otras criptomonedas, y Ethereum no escapó de ello. Fue así como el 27 de octubre de 2015, se publicó el EIP-001, creado por Martin Becze y Hudson Jameson, dos importantes desarrolladores de Ethereum. En dicho EIP, se puede leer el siguiente título:

EIP Purpose and Guidelines

Es decir, este primer EIP asentaba las líneas generales y el propósito de lo que serían los EIP dentro de Ethereum. De hecho, su introducción no puede ser más clara en este sentido:

EIP son las siglas de Ethereum Improvement Proposal. Un EIP es un documento de diseño que proporciona información a la comunidad de Ethereum, o que describe una nueva característica para Ethereum o sus procesos o entorno. El EIP debe proporcionar una especificación técnica concisa de la característica y una justificación de la misma. El autor del EIP es responsable de crear un consenso dentro de la comunidad y de documentar las opiniones discrepantes.

Clasificación de los EIP

Al igual que pasa en los BIP de Bitcoin, los EIP de Ethereum respetan una serie de clasificaciones que especifican hacia dónde se dirigen las mejoras que presentan. En ese caso, la clasificación de los EIP de Ethereum está repartidos en tres clases que son:

EIP Estándar

Estos EIP son usados para describir cambios que afecten a la mayoría o todas las implementaciones de Ethereum. Recordemos que Ethereum es un protocolo, y su implementación oficial está dada en el software Geth. Pero como este software existen otras implementaciones como la que podemos ver en Hyperledger Besu o Parity.

Las mejoras descritas en un EIP del tipo Estándar, generalmente incluyen cambios en el protocolo de red o un cambio en las reglas de validación de bloque o transacción. También aplica a los cambios de estándares de aplicación propuestos o cualquier cambio o adición que afecte la interoperabilidad de las aplicaciones. Así, los EIP del tipo Estándar son los que mayor alcance tienen en el desarrollo de Ethereum.

Adicionalmente, los EIP del tipo Estándar se dividen en las siguientes subcategorías:

Básico: en esta subcategoría se encuentran los EIP que buscan mejoras que requieren un cambio de consenso dentro de Ethereum. Un buen ejemplo de estos EIP, son los EIP-005 y EIP-0101). Sin embargo, también se incluyen aquellas mejoras en las que los cambios no son necesariamente críticos para el protocolo de consenso. Un ejemplo de esto último se puede ver en los EIP-086 y el EIP-090.
Redes: esta subcategoría incluye mejoras en torno a devp2p (EIP-8) y el protocolo de redes, esto incluye aquellas mejoras propuestas a las especificaciones del protocolo gossip y swarm de Ethereum.
Interfaz: en esta subcategoría se incluye aquellas mejoras en las especificaciones y estándares de API / RPC del cliente Ethereum. Además también se incluyen los cambios a nivel de ABI y API de los mismo. Un buen ejemplo de estos EIP lo podemos ver en el EIP-006.
ERC: estándares y convenciones de nivel de aplicación, incluidos estándares de contrato como; estándares de token (ERC-20, ERC-721 y ERC-1155), registros de nombres (ERC-26, ERC-137), esquemas de URI (ERC-67), formatos de biblioteca / paquete (EIP-82) y formatos de billetera (EIP-75, EIP-85).

Meta EIP

La otra clasificación de los EIP es conocida como los Meta EIP. En estos EIP se describe un proceso que rodea a Ethereum o propone un cambio en el mismo. Generalmente estos EIP proponen cambios en una implementación, pero no a la base de código de Ethereum. A menudo estos requieren el consenso de la comunidad, a diferencia de los EIP informativos, los usuarios no tienen la libertad de ignorarlos.

Un buen ejemplo de este tipo de EIP lo podemos ver en los cambios de procedimientos y pautas en el proceso de toma de decisiones y cambios en las herramientas o el entorno utilizado en el desarrollo de Ethereum. Cualquier Meta EIP, también se considera un EIP de proceso.

Informativos

Un EIP informativo describe un problema de diseño de Ethereum, o proporciona pautas generales o información a la comunidad de Ethereum, pero no propone una nueva característica. Los EIP informativos no representan necesariamente el consenso de la comunidad de Ethereum o una recomendación, por lo que los usuarios e implementadores tienen la libertad de ignorar los EIP informativos o seguir sus consejos.

Funcionamiento de los Ethereum Improvements Proposals o EIP

El funcionamiento de los EIP está claramente definido en el EIP-001. Dicho proceso comienza con el proceso de generación de la idea o propuesta por parte del autor del EIP. En este punto, comienza la responsabilidad de desarrollo sobre el autor, y será él quien deba presentar los argumentos necesarios para demostrar la necesidad de su propuesta, así como defenderla. Debido a ello, el autor del EIP debe crear una idea claramente explicada y exponerla en el cuerpo del EIP, junto con una justificación y elementos que sustenten su presentación.

Así, tenemos que en este punto se presentan las siguientes etapas:

Funcionamiento de los Ethereum Improvements Proposals o EIP

Así, tenemos que en este punto se presentan las siguientes etapas:

Primera etapa: Presentación de la idea

Es la etapa más básica y no pulida de un EIP. Básicamente es la presentación de la mejora como una sugerencia en los foros de Ethereum. El objetivo de esto es obtener un feedback por parte de la comunidad, para seguir o no con el desarrollo de la propuesta de forma más elaborada.

Segunda etapa: Creación del borrador

En este punto la idea ya se encuentra plasmada y ejecutada siguiendo los parámetros de organización que se esperan de un EIP. Es un trabajo en proceso y activo donde pueden enviar solicitudes de seguimiento con más cambios a su borrador hasta el punto en que crea que el EIP está maduro y listo para pasar al siguiente estado.

Tercera etapa: Última llamada

En este punto el borrador ya corregido pasa a ser destacado en el sitio web EIPS Ethereum. La idea de esta etapa es presentar el EIP al mayor número de personas dentro de la comunidad, terminar correcciones y crear un implementación completamente funcional y revisada del EIP.

Cuarta etapa: Aceptación

Este estado indica que los cambios materiales son poco probables y los desarrolladores de clientes de Ethereum deben considerar este EIP para su inclusión. Su proceso para decidir si modificarlo en sus clientes como parte de un hard fork no es parte del proceso EIP. Este estado sólo es aplicable a los EIP para procesos centrales de la blockchain.

Quinta etapa: Presentación final

Este punto representa un estado en el que el EIP solo debe actualizarse para corregir las erratas. Adicionalmente se pueden marcar otros estados como:

Activo: En algunos EIP informativos y de proceso también pueden tener un estado de “Activo” si nunca deben completarse.
Abandonado: Los autores originales ya no buscan implementar este EIP o puede que ya no sea una opción (técnicamente) preferida.
Rechazado: Un EIP que está fundamentalmente roto o un EIP Core que fue rechazado por Core Devs y no se implementará.
Reemplazado: Un EIP que anteriormente era Final pero que ya no se considera de vanguardia. Otro EIP estará en estado Final y hará referencia al EIP Reemplazado.

Formato de un Ethereum Improvements Proposals o EIP

Por supuesto los Ethereum Improvements Proposals o EIP, al ser documentos técnicos tienen un formato de presentación estándar que indique claramente toda la información necesaria para entender la mejora propuesta por el mismo. Así tenemos que el formato de los EIP contiene los siguientes renglones:

Preámbulo. Esta es la introducción al EIP. Están formateados siguiendo la guía de estilos establecida por el estándar RFC 822. Dicho preámbulo incluye todos los datos básicos del EIP, como lo son su número, su autor, el nombre y una breve descripción.
Resumen. En este punto nos hallaremos con una descripción breve (no más de 200 palabras) del problema técnico que se está abordando en el EIP.
Motivación. Este punto es opcional y solo debe ser puesta de forma obligatoria en caso de que se desee alterar el protocolo Ethereum. En este punto, el autor del EIP debe explicar claramente por qué la especificación de protocolo existente es inadecuada para abordar el problema que resuelve el EIP. Los envíos de EIP sin una motivación convincente en este punto pueden ser rechazados por completo.
Especificación. En este punto el autor del EIP debe crear y explicar la sintaxis y la mejora que está proponiendo. Debe ser clara y concisa, demostrable y reproducible. Si la especificación no respeta estos principios simplemente será rechazada.
Justificación. La justificación desarrolla la especificación al describir lo que motivó el diseño y por qué se tomaron decisiones particulares de diseño. Debe describir diseños alternativos que se consideraron y trabajos relacionados. La justificación también puede proporcionar evidencia de consenso dentro de la comunidad, y debe discutir importantes objeciones o inquietudes planteadas durante la discusión.
Compatibilidad con versiones anteriores. Todos los EIP que introducen incompatibilidades con versiones anteriores deben incluir una sección que describa estas incompatibilidades y su gravedad. El EIP debe explicar cómo el autor propone tratar estas incompatibilidades. Los envíos EIP sin un tratado de compatibilidad con versiones anteriores suficientes pueden ser rechazados por completo.
Casos de prueba. Los casos de prueba para una implementación son obligatorios para los EIP que afectan los cambios de consenso. Otros EIP pueden elegir incluir enlaces a casos de prueba, si corresponde.
Implementaciones. Las implementaciones deben completarse antes de que cualquier EIP reciba el estado “Final”, pero no es necesario completarlo antes de que el EIP se fusione como borrador. Si bien el enfoque de alcanzar un consenso sobre la especificación y la justificación antes de escribir el código tiene mérito, el principio de “consenso general y código en ejecución” sigue siendo útil cuando se trata de resolver muchas discusiones sobre los detalles de la API.
Consideraciones de seguridad. todos los EIP deben contener una sección que discuta las implicaciones / consideraciones de seguridad relevantes para el cambio propuesto. Incluya información que pueda ser importante para las discusiones de seguridad, los riesgos superficiales y que se pueda utilizar durante todo el ciclo de vida de la propuesta. P.ej. incluyen decisiones de diseño relevantes para la seguridad, inquietudes, debates importantes, orientación y dificultades específicas de implementación, un resumen de amenazas y riesgos y cómo se están abordando. Los envíos EIP que faltan en la sección “Consideraciones de seguridad” serán rechazados. Un EIP no puede pasar al estado “Final” sin una discusión de Consideraciones de seguridad que los revisores consideren suficiente.
Exención de derechos de autor. Todos los EIP deben ser de dominio público.