A principios de este mes, el jefe del equipo de la Fundación Ethereum, Péter Szilágyi, confirmó la fecha de la próxima actualización de la red, Estambul. El octavo hard fork (bifurcación dura) de Ethereum y el segundo este año se celebrará el 4 de diciembre. Sin embargo, el 20 de noviembre, según el anuncio oficial, la fecha estimada se movió para el 7 de diciembre.

Estambul introducirá una serie de mejoras, como la interoperabilidad con Zcash, dos soluciones de escalabilidad más baratas de capa de zero-knowledge (cero conocimientos) y un precio ajustado del gas para determinadas operaciones, lo que marcará otro hito en el camino hacia Ethereum 2.0, una versión "definitiva" muy esperada de la red. ¿Cómo encaja exactamente Estambul en el gran esquema de las cosas?

Forks, liberaciones y fases

Ningún sistema complejo de código abierto está nunca en su estado final - el software está siempre en movimiento, siendo constantemente mejorado y actualizado. Esto es especialmente cierto en el caso de Ethereum, cuyo camino para convertirse en un "ordenador mundial" distribuido y en la plataforma ideal para aplicaciones descentralizadas se describió desde sus inicios como una serie de hitos consecutivos.

El objetivo actual que persigue la comunidad de desarrolladores de Ethereum es una versión avanzada de la red llamada Ethereum 2.0, Eth2 o Serenity. Se espera que la actualización vea una serie de desarrollos drásticos, como la transición de un algoritmo de Prueba de Trabajo (PoW) a un algoritmo de Prueba de Participación (PoS) más eficiente energéticamente, la realización de un nuevo paradigma de escalabilidad llamado sharding, y la introducción de una EVM (Ethereum Virtual Machine) más eficiente capaz de ejecutar contratos inteligentes de alto rendimiento. El investigador Danny Ryan ha formulado cinco objetivos generales de diseño para Ethereum 2.0: descentralización, resiliencia, seguridad, simplicidad y longevidad.

Las diferencias en el lenguaje utilizado para describir las etapas de las actualizaciones de la red pueden ser confusas: Hay forks que llevan el nombre de las grandes ciudades del mundo, fases numeradas, lanzamientos denotados por códigos de versión y etiquetas poéticas como "serenity" (serenidad en español). Sin embargo, en última instancia, todo se reduce a una estructura bastante sencilla.

El mayor incremento en el proceso de desarrollo se denomina "release". Se puede realizar una sola liberación por medio de uno o varios hard forks - makeovers del protocolo blockchain que marcan un cambio completo con respecto a su versión anterior.

Hasta la fecha, ha habido tres versiones -la actual Metropolis- que se han desplegado en dos etapas: Byzantium y Constantinople, con Istanbul por delante. Posteriormente, Berlín (programada provisionalmente para junio de 2020) y Londres, marcarán el advenimiento de la cuarta versión, Ethereum 2.0, o Serenity.

Los Hard Forks introducen cambios en la red principal Ethereum, actualmente en funcionamiento. La hoja de ruta de Ethereum 2.0, sin embargo, estipula la creación de nuevas cadenas separadas - como la eventual existencia de dos cadenas Ethereum activas con diferentes mecanismos de consenso. El despliegue de la cadena Ethereum 2.0 vendrá en una secuencia de fases especificadas en la hoja de ruta.

Istanbul: mejoras aceptadas

El principal vehículo de gobernanza en el que se basa la comunidad Ethereum para hacer avanzar la red son las Ethereum Improvement Proposals, (Propuestas de Mejora del Ethereum). Especifican sugerencias relacionadas con cambios en el protocolo central, APIs de clientes (Interfaces de Programación de Aplicaciones) y estándares de contratos inteligentes.

Los autores normalmente tratan de cronometrar las propuestas según el calendario de los forks y se centran en los forks específicos anunciados con antelación. En la actualidad, existe un impulso en la comunidad para cambiar a un enfoque "centrado en el EIP" en la actualización del sistema, en el que unos forks más frecuentes y más pequeños podrían permitir que las propuestas se desarrollen a su propio ritmo. Se espera que Berlín, el hard fork que seguirá a Istanbul, sea el primero en aplicar este paradigma.

Istanbul todavía sigue el enfoque "centrado en los forks", donde muchas propuestas en varias etapas de su ciclo de vida fueron presentadas y revisadas durante las convocatorias de All Core Devs. Los desarrolladores clasificaron a los EIPs como deseados y listos para entrar en el fork (aceptados), deseados pero aún no listos (tentativamente aceptados, asumiendo que van a vivir con el siguiente hard fork), o no deseados (permanentemente rechazados). De los 38 EIPs presentados, sólo seis fueron aceptados para su inclusión, y otros ocho fueron aprobados para el fork de Berlín. He aquí un resumen de las propuestas aceptadas:

EIP-152 ofrece la posibilidad de verificar el algoritmo de Prueba de Trabajo Equihash dentro de un contrato Ethereum, lo que permite la interoperabilidad entre las Blockchains de Zcash y Ethereum.

EIP-1108 reduce los costes de precompilación de gas, haciendo más barata la generación de pruebas no interactivas de zero-knowledge, o zk-SNARKs. Esta es una buena noticia por dos razones. Una es que el cambio mejorará el desarrollo de aplicaciones centradas en la privacidad que utilizan este tipo de criptografía.

Más consecuentemente, el uso de zk-SNARKs es una solución de segunda capa que puede ser instrumental para aliviar algunos de los problemas de escalabilidad de Ethereum al mover una cantidad significativa de trabajo computacional fuera de la Blockchain.

EIP-1344 añade un opcode que devuelve el identificador único de la cadena actual, introduciendo una forma de que los contratos rastreen la cadena Ethereum en la que se encuentran. Esto mejorará la resistencia del sistema a la repetición de los ataques a las transacciones firmadas.

EIP-1884 es quizás la más debatida de las propuestas aceptadas, causando controversia desde al menos agosto de este año. Presentada por Martin Holst Swende, responsable de seguridad de la Fundación Ethereum, esta propuesta tiene por objeto reevaluar determinados opcodes (instrucciones dadas a la Ethereum Virtual Machine que ejecuta contratos inteligentes) con el fin de "obtener un buen equilibrio entre el gasto en gas y el consumo de recursos".

El problema que se supone que el EIP-1884 debe resolver se debe a que algunas operaciones se han vuelto más intensivas en recursos con la expansión de la Blockchain de Ethereum. En este momento, los bloques con consumos de gas similares tardan mucho tiempo en terminar, lo que no sólo es un problema en sí mismo, sino que también puede ser un vector de un ataque de denegación de servicio.

La fricción surgió durante el encuentro 69 Core Dev del 23 de agosto, donde Wei Tang de Parity Technologies expresó su preocupación por la posibilidad de que el cambio en los costos del opcode rompiera algunos de los contratos que ya están desplegados. Sostuvo que debía preservarse la compatibilidad hacia atrás, permitiendo que los antiguos contratos funcionaran de acuerdo con los precios originales.

Hudson Jameson, el enlace con la comunidad de la Fundación Ethereum, respondió que existe un "precedente de que los precios de OPCODE pueden cambiar y cambiarán, por lo que sus contratos no deben basarse en la suposición de que no cambiarán", y añadió que la transición dejaría a la gente mejor preparada para los cambios más drásticos que son inminentes.

EIP-1884 afectará a un número limitado de contratos en una variedad de proyectos. Hubert Ritzdorf, de la empresa de seguridad Blockchain ChainSecurity, ha elaborado quizás la lista más completa de contratos de este tipo que pueden verse afectados.

EIP-2028 reduce el coste de las llamadas de datos en las transacciones, lo que puede dar lugar a bloques más grandes y, por lo tanto, a una mejor escalabilidad de la red. Esto también hará que las soluciones de escalabilidad de segunda capa (como zk-SNARKs) sean más accesibles.

El EIP-2200 implementa la medición neta de gas, cambiando la forma en que se calcula el costo de almacenamiento en la EVM. Esto permitirá nuevas funciones de almacenamiento contractual y reducirá algunos costes excesivos.

Aún en proceso de realización

Otra propuesta de alto perfil que la comunidad Ethereum consideró en la construcción del fork de Istanbul es EIP-1057, que busca reemplazar el actual algoritmo de minería Ethash con una nueva función de Prueba de Trabajo llamada ProgPoW, abreviatura de Programmatic Proof-of-Work (Prueba de trabajo programática). Los departamentos de desarrollo central han aceptado provisionalmente la iniciativa, a la espera de los resultados de la auditoría, para su inclusión en el hard fork de Berlín.

La idea detrás de esta actualización de algoritmos es ajustarla para hardware básico que utiliza unidades de procesamiento gráfico (GPU), lo que dificulta la extracción de datos para configuraciones equipadas con chips de circuitos integrados específicos de aplicaciones (ASICs).

Esta medida está diseñada para restaurar cierto grado de descentralización en la distribución de la energía minera, al mismo tiempo que se nivela el campo al hacer que la minería de Ethereum sea más atractiva para los usuarios individuales y las pequeñas empresas que no invierten en hardware especializado. Los equipos ASIC fueron uno de los principales impulsores de la industrialización de la minería en los últimos años, dando lugar a agrupaciones mineras masivas y centralizadas.

A principios de este año, el líder de seguridad de la Fundación Ethereum, Martin Holst Swende, dijo que la introducción de ProgPoW mitigaría el grado de dominio de los ASIC y otros aceleradores de hardware en la red. Añadió que otra razón para el cambio son las fallas de seguridad inherentes a Ethash.

Aunque parece haber acuerdo entre los principales desarrolladores con respecto a la conveniencia de ProgPoW, no todos en la comunidad están contentos con la perspectiva de que el algoritmo minero cambie antes del cambio a la Prueba de Participación de Ethereum 2.0.

El disidente más ruidoso hasta ahora ha sido Aragón, un proyecto de gestión de organizaciones autónomas descentralizadas (DAO), cuya comunidad votó el 2 de noviembre para oponerse a cualquier cambio en Ethash antes de la transición a Ethereum 2.0.

A pesar de algunas tensiones, no hay indicios de que una masa crítica de usuarios de Ethereum se oponga contundentemente al cambio propuesto, lo que hace poco probable que el desarrollo conduzca a una ruptura grave.

Si la auditoría independiente atestigua la robustez del nuevo algoritmo, es probable que se aplique con el fork de Berlín, ahora programado provisionalmente para junio de 2020, mientras Ethereum continúa su marcha hacia la codiciada versión 2.0 de la red.

Sigue leyendo: