Ethereum, una de las principales plataformas blockchain del ecosistema, ha destacado no solo por lo innovador que resulta el protocolo de los contratos inteligentes, sino porque fue además una de las primeras que procedió a bifurcar forzadamente su cadena por otro motivo diferente a lo técnico, en ocasión de resarcir fondos robados a la Organización Autónoma Descentralizada que su comunidad creó.
Desde entonces, una gran parte de los mineros y usuarios de esta criptomoneda decidieron mantenerse en el protocolo original, haciéndose llamar Ethereum Classic, mientras que Ethereum siguió su camino con éxito.
Sin embargo, situaciones de robos y extravío de fondos han sido relativamente frecuentes en clientes de esta red, por lo que ha surgido un debate sobre cómo pueden resolverse estas contingencias sin tener que pasar por todo lo que una bifurcación forzada (hardfork) de blockchain requiere.
Parity
Uno de los casos más recientes, ocurrido el año pasado, es el de Parity, cliente de carteras y DApps del entorno Ethereum, en el que un hacker logró extraer 153 mil ethers (ETH) de varias carteras multifirma pertenecientes a los proyectos Edgeless, Aeternity y Swarm City. En su momento, el monto robado equivalía a unos $32 millones de dólares.
La falla surgió en la herramienta Parity 1.5, que permite la creación de monederos dentro de su plataforma, atribuido a una falla mínima en sus contratos inteligentes, pero suficiente para haber permitido esta situación.
Más tarde, casi a finales de 2017, un usuario cometió un error de programación congelando para siempre 500 mil ETH, ante lo que Parity propuso realizar una bifurcación forzada para recuperar los fondos bloqueados. Esta iniciativa se basó en la propuesta EIP 156 (Propuesta de Mejoramiento de Ethereum, según sus siglas en inglés), creada por el mismo fundador de Ethereum, Vitalik Buterin.
Esta propuesta permite a los usuarios de ether u otros activos que tengan cuentas “trabadas” retirar sus activos. El primer caso cubre los contratos accidentalmente creados sin código, así como algunas pérdidas de ataques de repetición en los que un contrato fue creado en ETC [Ethereum Classic], fondos enviados a ETH [Ethereum] sin que el contrato se haya creado en ETH; el segundo caso cubre las pérdidas generadas por errores de cómputo en la vieja librería de javascript […]
Vitalik Buterin
Cofundador
El cofundador de Ethereum está consciente de lo polémica que puede resultar esta propuesta, aunque la define como “mucho menos invasiva que las propuestas anteriores” y explica que la intención es debatir sobre sus implicaciones.
Particularmente, el usuario Aribo entró en detalle con respecto a que recuperar los fondos no es la función de la plataforma y sus desarrolladores:
El principal objetivo de Ethereum es ser una plataforma descentralizada para la ejecución final de contratos inteligentes. Para crear y sostener la plataforma, es necesario crear un sistema económico basado en las criptomonedas y sus incentivos. La principal función de los desarrolladores es crear, mantener y sostener esta plataforma según ese objetivo, incluyendo el funcionamiento correcto de este ecosistema criptoeconómico, mas no la de garantizar beneficios o exigir tareas a los actores de este sistema y los usuarios de la plataforma.
Vitalik Buterin
Cofundador
El uso del verbo exigir podría referirse a que no se puede obligar a los desarrolladores a realizar cambios en el protocolo si no están de acuerdo, en tanto la naturaleza abierta del código permite elaborar actualizaciones, proponerlas, debatirlas y votarlas, en ese orden, de forma libre y pública.
Aribo, del mismo modo, indica una difícil realidad para las víctimas de robos o afectados por el congelamiento de ethers al afirmar que: “si alguien pierde dinero en el sistema económico creado en Ethereum, es su propia responsabilidad” recalcando que la creación e implantación de nuevos estándares no debería estar entre las responsabilidades de los desarrolladores de una blockchain.
Luego, el usuario admite que la recuperación de fondos es una responsabilidad, pero solamente cuando su función es la de salvar la plataforma de su colapso, evitar que la plataforma deje de comportarse de acuerdo al objetivo inicialmente acordado. Seguido, se refiere al caso de la DAO, el motivo principal de una bifurcación forzada en Ethereum, que si bien recuperaba los fondos robados, buscaba proteger al sistema de una amenaza seria y sin precedentes. De esto dependía que esta red siguiera funcionando.
En qué consiste la EIP 867
La propuesta debatida en la EIP 156 fue echada al olvido, pero volvió a surgir con la EIP 867. La nueva propuesta ocasionó incluso que un desarrollador japonés, Yoichi Hirai, renunciara al verse en una contradicción con el código penal de su país. Sus preocupaciones acerca de un documento legal que leyó, pero no citó, le impidieron continuar insertando actualizaciones en el código de Ethereum.
Hirai veía en las bases de la EIP 867 una violación a la ley de registros digitales, además de considerar que la propuesta no era afín con la filosofía de Ethereum, según anunció. “Un guardia no debería renunciar luego de ver algo sospechoso, pero esto es mucho para mí”, dijo el desarrollador nipón antes de renunciar.
El debate derivó también hacia la necesidad de la comunidad y los desarrolladores de formar una especie de autoridad para deliberar en casos que afecten a la red en general (no solo para las propuestas EIP), en tanto se enfrentan la visión que apoya la prevalencia del desarrollo de código y quienes están a favor de la comunidad.
Yoichi Hirai, bajo el pseudónimo ‘pirapira’, respondió de la siguiente manera a otros comentarios en el debate:
Creo que esta propuesta entra en desacuerdo con la filosofía de Ethereum. Los puntos únicos de fallo y la necesidad de confiar es lo que Ethereum intenta evitar. Así, no puedo aprobarle el estatus EIP a esta propuesta por no “mantenerse junto a la filosofía de Ethereum.”
Vitalik Buterin
Cofundador
La EIP 867 fue presentada por el desarrollador Dan Phifer, perteneciente al proyecto Musiconomi, además de otros dos desarrolladores de TapTrust, una plataforma de foros descentralizados para discutir sobre fichas ERC20, y busca modificar el registro histórico de la blockchain de Ethereum de una manera más simple, en lugar de tener que realizar una bifurcación.
Phifer llega a construir esta propuesta debido a que Musiconomi fue afectada por el bloqueo de la cartera multifirmas de Parity, ocurrida en junio del 2017. Al igual que la EIP 156, la propuesta fue recibida con opiniones enfrentadas entre sí, denotando un debate basado en el potencial efecto negativo de integrar una característica al protocolo de Ethereum según los ideales la plataforma y la visión de algunas víctimas de robos o errores de programación, cuestión la cual es comprensible debido a las enormes cantidades de dinero perdidas.
Otro caso ocurrió el 24 de noviembre de 2015, cuando James Levy recibió 40,000 ETH por parte de la Fundación Ethereum, como agradecimiento por haber creado una herramienta para contratos inteligentes, en la época en que esta era sumamente innovadora. Sin embargo, tres semanas después, los fondos fueron extraídos en lo que fue quizá el peor hackeo de la historia de Ethereum. Fue por causa de la debilidad de una contraseña. Ahora, Levy es uno de los principales promotores de la EIP 867.
¿Qué opinan los desarrolladores principales de Ethereum?
El desarrollador Nick Johnson explica que revertir contratos es sumamente dificil en Ethereum debido a que esta plataforma tiene diversas invariables o códigos ejecutables cuya función en el tiempo no puede modificarse en ningún caso fuera de su programación.
Una de las invariables que la propuesta desea cambiar, según señala Johnson, es la que reza que el código de un contrato nunca cambiará a menos que el contrato se destruya a sí mismo y, la otra, que el creador de un contrato no tiene acceso especial o privilegios sobre este.
Ambas invariables son sustituidas por la siguiente máxima en la EIP 867: “El código de un contrato puede ser borrado si el contrato se autodestruye y después podría sustituirse por el código elegido por el creador original o por un contrato estandar”, algo que Johnson asegura es retroactivo y que afecta a numerosos contratos escritos previamente.
En ese sentido, el desarrollador afirma que algunos sistemas como Etherdelta, cuyo protocolo es actualizado automáticamente al emitir un nuevo contrato y destruyendo el anterior, serían afectados. Esto debido a que los usuarios no tendrían oportunidad de verificarlo, lo que permitiría que los desarrolladores puedan cambiar el código del contrato sin hacerlo del conocimiento de sus usuarios.
Debido a los riesgos y el nivel de incertidumbre, no puedo recomendar personalmente ninguna de las cuatro variantes de esta propuesta para ser adoptada. Soy escéptico sobre si alguna de estas variantes de la propuesta puede aliviar los riesgos involucrados como para que valga la pena, aunque estoy dispuesto a considerar nuevas variantes con mente abierta.
Vitalik Buterin
Cofundador
Si en algo coinciden tanto Parity como los detractores de la propuesta EIP 867 es en la integridad del protocolo de Ethereum, lo cual lo hace libre de responsabilidades por lo ocurrido; aunque Parity piense que puede hacerse un esfuerzo por compensar a los usuarios afectados.
No debemos tener la ilusión de que desbloquear estos fondos pasará por otra cosa que no sea una operación de rescate, pues esto es solo posible con una bifurcación forzada. En ninguno de estos casos fue falla específica del protocolo. Las cuestiones acerca de la usabilidad, los problemas del código base de las entidades privadas y el código de la fundación, el inesperado surgimiento de una red competidora y el error de los usuarios ha contribuido a lo que llegamos hoy. Ethereum es hoy en día un protocolo sólido y continúa evolucionando.
Vitalik Buterin
Cofundador
A pesar de que más adelante desestiman las bifurcaciones forzadas, sí señalan que muchos de los fondos perdidos son recuperables, ante lo que propusieron tres soluciones: la primera, emplear la EIP 156 puesta sobre la mesa por Vitalik Buterin. La segunda, tomar como objetivos direcciones específicas donde se almacenen fondos robados y extraerlos forzadamente de allí, sin cambiar el protocolo de Ethereum. La tercera, es la EIP 856, basada en “resucitar” los contratos inteligentes autodestruidos con un cambio de código en el protocolo.
Ante este panorama, el equipo de desarrolladores de Ethereum no ha tomado una decisión definitiva. Aunque las discusiones al respecto no han cesado en la comunidad y se espera que se obtenga una posición unitaria al final del camino, que permita la continuación de esta plataforma sin la necesidad de llegar a sufrir una nueva separación de la cadena y de la comunidad.
Imagen destacada por: Alexander Limbach / stock.adobe.com
Ingresar
Suscribirme
