¿Que son los EIPs en Ethereum?

José Maldonado
14 MAY 2020
¿Que son los EIPs en Ethereum?
1.

Introducción

Las Propuestas de Mejora de Ethereum o Ethereum Improvements Proposals (EIP, por sus siglas en inglés), son documentos técnicos en los que la comunidad de Ethereum realiza sus propuestas de mejoras en el diseño y desarrollo de Ethereum.

En pocas palabras, un EIP sirve para que su desarrollador plasme y explique detalladamente una nueva función o mejora para Ethereum. Pero no solo eso, este documento proporciona una prueba de concepto o, incluso mejor, la implementación funcional de las mismas.

De allí que la creación de estos documentos tenga un objetivo bien claro y definido: proponer ante la comunidad el futuro del proyecto y darles la oportunidad a todos para discutirlo. Para lograr esto último, el autor de un EIP se hace responsable de generar consenso dentro de la comunidad. Además de documentar las opiniones disidentes y ofrecer respuestas claras que echen por tierra cualquier argumento en contra de su propuesta.

Gracias a estas características, los EIP se han transformado en una interesante herramienta. Ya que permiten a los desarrolladores, trazar y el explicar el futuro de Ethereum. Además de esto, permite documentar todo y dejar disponible dicha información al alcance de todos para todos.

2.

Origen de los Ethereum Improvements Proposals o EIP

Los Ethereum Improvements Proposals o EIP, proviene de las experiencias aplicadas en Bitcoin y sus Propuestas de Mejoras de Bitcoin (Improvements Proposals Bitcoin o BIP). Estos documentos en Bitcoin fueron desarrollados por el criptoanarquista Amir Taaki. El trabajo de Taaki llevó a la creación de estos documentos basándose en la experiencia de la comunidad Python y sus conocidos PEP (Python Enhancement Proposal). Sin embargo, la propuesta inicial de Taaki fue mejorada por el desarrollador de Bitcoin Luke Dashjr.

En tal sentido, la comunidad Ethereum también crea esto documentos con el fin de organizar el trabajo de las propuestas de desarrollo. Los responsables de esta tarea fueron los desarrolladores Martin Becze y Hudson Jameson, dos importantes figuras dentro de Ethereum.

Fueron ellos quienes el 27 de octubre de 2015 publicaron el primer EIP, el EIP-1. En el mismo describen las razones detrás de la creación de los EIP y como sería el sistema de funcionamiento de los mismos. Además, explicaron que los mismos servirían para recopilar información técnica de la comunidad sobre un tema y para documentar las decisiones de diseño que se han incluido en Ethereum. Y gracias a que estos son alojados en sistemas de almacenamiento versionado, es posible rastrear todos los cambios realizados a los mismos de principio a fin.

Relacionado: ¿Qué es Ethereum?

3.

Clasificación de los EIP

Los EIP se clasifican en tres tipos que están claramente definidos. Estos son:

Estándar

Los EIPs estándar se usan para describir cualquier cambio que afecte a la mayoría o todas las implementaciones de Ethereum. Esto incluye 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. Es decir, son el tipo de EIP de mayor y más amplio alcance en Ethereum.

Debido a ello, los EIP estándar se dividen en las siguientes subcategorías:

  1. Básico: mejoras que requieren una bifurcación de consenso (por ejemplo, los EIP-5 y EIP-101). También incluyen los cambios que no son necesariamente críticos por consenso, pero que pueden ser relevantes para las discusiones de “desarrollo central”. Un ejemplo de esto último se puede ver por ejemplo en el EIP-86 y el EIP-90.
  2. Redes: incluye mejoras en torno a devp2p (EIP-8) y el subprotocolo Light Ethereum, así como mejoras propuestas a las especificaciones de protocolo de red de susurros y enjambres.
  3. Interfaz: incluye mejoras en las especificaciones y estándares de API / RPC del cliente, y también ciertos estándares de nivel de idioma como nombres de métodos (EIP-6) y ABI de contrato. La etiqueta “interfaz” se alinea con el repositorio de interfaces y la discusión debe ocurrir principalmente en ese repositorio antes de que se envíe un EIP al repositorio de EIP.
  4. ERC: estándares y convenciones de nivel de aplicación, incluidos estándares de contrato como estándares de token (ERC-20), 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

Un Meta EIP describe un proceso que rodea a Ethereum o propone un cambio en un proceso o evento. Los EIP de proceso son como los EIP de seguimiento de estándares, pero se aplican a áreas distintas al protocolo Ethereum. 

Estos pueden proponer 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. 

Los ejemplos incluyen procedimientos, pautas, cambios 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.

4.

¿Cómo funcionan los Ethereum Improvements Proposals o EIP?

El proceso de funcionamiento de un Ethereum Improvements Proposals o EIP, comienza con la generación de la idea por parte del autor del EIP. La responsabilidad de desarrollo recae en esta persona. Por esa razón, lo primero que un autor de EIP debe hacer es examinar su idea y crear una explicación y justificación que deje todo en claro.

En el EIP-1 incluso se sugiere que se abra una discusión en el foro de Ethereum Magicians, en el subreddit de Ethereum o el chat de Gitter. En definitiva, el primer paso, es dar a conocer la idea básica y desde allí crear el EIP siguiendo los parámetros para su presentación.

A partir de este punto, el EIP pasa por algunas de estas etapas:

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.

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.

Última llamada

En este punto el borrador ya corregido pasa a ser destacado en el sitio web EIPS Ethereum. En este punto las mejoras al EIP pueden ser fácilmente añadidas.

Aceptado

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 codificarlo 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.

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:

  1. Activo. En algunos EIP informativos y de proceso también pueden tener un estado de "Activo" si nunca deben completarse.
  2. Abandonado. Los autores originales ya no buscan implementar este EIP o puede que ya no sea una opción (técnicamente) preferida.
  3. Rechazado. In EIP que está fundamentalmente roto o un EIP Core que fue rechazado por Core Devs y no se implementará.
  4. 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.

https://lh5.googleusercontent.com/KqvnuXe5-2i9jPetJBgEZvQrHlt4820cnhwAxGUpPXBPuFGgAQNH-MN9brtwf3Dji-cc--TQyPkXLk6r0nR9kIJcOL2xe3AGcHWyFBx8W3dTF4IJRTGZ5bNErQ_fsAwhrMrUXwpy

5.

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:

  1. 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.

    https://lh4.googleusercontent.com/dxo8U5W0c1Syhat_u-bnWQxqOL6h9U18sQyNDQ_yjG9Ahdpt6IM1X1Zx6hVIp0WPyc5Wn89MBTJisXHUHUO9xTzh_UfTehQnszsU8LeDPV3yvlHTD7IPGfoTyeDqD4lJpRNNcYhI
  2. 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.

    https://lh5.googleusercontent.com/uCCPgqIZS8QJxwAaAdQ73Rg2CsVyH2-YEyduJM7YOFv2SfMk63ysPUMScfm27uwVi3kdYAfcWN8XHqnm-3jpDfW5foGOflSeztemUPTEVbDRUtWDMerhbg4upk1VyiUxWXwRfITN
  3. 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.

    https://lh5.googleusercontent.com/Zsr5n1Tg2KTPi6IADGv3tBgkQCAEbN7HD8MwJ4ZAu_GuE1uDUvZZh0FtwYNATjEv7RzE1V1BJwLTstpfKdRA6SH1upTN3FOl1pFz5oifBzesYFBvfChLohhXiD4niEB6HHlQEO4t
     
  4. 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.

    https://lh3.googleusercontent.com/eh4SJPin3ssGsrQDWvVt81SyBOJ8CX2lMA1cRi-c_HLtGTcpqs1FPIdDzF-0sc965dNpBq7W4VwXSGiohpO3qE_DSn2SOuThRRC6a1JgWj0tqsw1PuhLhbZZWnf33MzROpm1cyVy
     
  5. 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.
     
  6. 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 suficiente pueden ser rechazados por completo.
     
  7. 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.
     
  8. 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.
    https://lh5.googleusercontent.com/oUyETUUYNl11F2YQZ7RYu7EtiTrH2uEYzJpmkQmj1AaF64gztoUIufFctD2zU1oUGjJacMDQUxKHK66WdaeO6NQDU4MsWRMEguaWLr9yZDDsHx_Uo3TivfjDBFePgjHAcwvlhX92
  9. 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.
     
  10. Exención de derechos de autor. Todos los EIP deben ser de dominio público. 

https://lh3.googleusercontent.com/LGDXm0I6I9Yp0Gf3cjBzUa2ChHOVzuFln1hVB-qONTrp4OypOKw7hiqAhAiBGzAy3MqBm_eeejhhNxy9qI_KEmD59LVQ_eiqnu-bBRgFp5ZslCs3k0OJZPBf6YtXzUJej5b23mjP

Relacionado: ¿Quíen es Vitalik Buterin?

6.

Algunos Ethereum Improvements Proposals o EIP importantes

EIP-606: Hard Fork Meta: Homestead

El EIP-606 es un EIP del tipo Meta, que describe todos los puntos necesarios para llevar a cabo la actualización Homestead en Ethereum. Al ser un EIP del tipo Meta, este hace referencia a otros EIP que explican la totalidad de los cambios que se realizarán. En este caso, el EIP-606 invoca a los siguientes EIP:

EIP-2: Homestead Hard-fork Changes

EIP-7: DELEGATECALL

EIP-8: devp2p Forward Compatibility Requirements for Homestead

Cada uno de estos EIP explica de forma individual los cambios que se realizarán y en conjunto, llevan a la actualización Homestead.

EIP-20: ERC-20 Token Standard

El EIP-20 es quizás uno de los EIP más conocidos del mundo de Ethereum puesto que fue creado para implementar al conocido token estándar ERC-20. De este desarrollo se marcó el inicio para que Ethereum creará una herramienta estándar para desplegar tokens en su blockchain. Como resultado Ethereum se ha convertido en la blockchain con más tokens que existe en la actualidad.

EIP-137: Ethereum Domain Name Service - Specification

El EIP-137 dio nacimiento a la especificación del sistema de Nombre de Dominio de Ethereum. Desde acá se crearía toda la infraestructura necesaria para que Ethereum se pueda convertir en un gigantesco servicio de nombres de dominio (DNS) completamente descentralizado y centrado en la privacidad. Pero no solo eso, este también permitiría asociar una dirección legible con una dirección criptográfica para recibir y enviar criptomonedas con ella. Este trabajo dio como resultado el ENS.

EIP-609: Hard Fork Meta: Byzantium

El EIP-609, es un EIP del tipo meta describe todos los EIP necesarios para la activación de la actualización (hard fork) Byzantium.

EIP-649: Metropolis Difficulty Bomb Delay and Block Reward Reduction

Este EIP-649 aplica el primer delay a la bomba de dificultad para evitar la era de hielo de Ethereum, un punto en el cual le resultaría imposible a los mineros de Ethereum seguir minando los bloques en un tiempo y ganancias prudenciales. Este EIP fue duramente discutido pero su aplicación fue necesaria para evitar que la red Ethereum se quebrará.

EIP-721: ERC-721 Non-Fungible Token Standard

El EIP-721 es otro EIP ampliamente conocido debido a que él mismo creó el estándar de los tokens no-fungibles de Ethereum, el ERC-721. De este token nacieron proyectos como CryptoKitties.

EIP-779: Hard Fork Meta: DAO Fork

Este es quizás el EIP más controvertido de Ethereum. El EIP-779 fue el responsable de "solucionar" el problema del hackeo multimillonario de The DAO. Para ello, EIP llevó a cabo una reescritura de todo el historial de la blockchain de Ethereum desde momentos antes de que se hiciera el hackeo a The DAO.

Esto con el objetivo de devolver los fondos robados a sus dueños.  Como resultado de la aplicación de este hard fork, Ethereum se dividió en dos comunidades cada una con su propia blockchain. La que aplicó el parche (Ethereum) y la que no lo aplico (Ethereum Classic).

Una lista completa de todos los EIP puede ser accedida desde esta web.