Historia de Ethereum (Parte 3: Final)

En las dos entregas anteriores de nuestra serie “Historia de Ethereum”, describimos las primeras tres fases de la transición de la red al algoritmo PoS, recordamos los problemas que enfrentó la comunidad Ethereum en el proceso de desarrollo de la red y formación de ecosistemas, y describimos eventos importantes. que ocurrió desde el inicio del proyecto hasta principios de 2019.

En el artículo de hoy, hablaremos sobre la última actualización importante de la red, que precede a la transición por fases a Ethereum 2.0, describiremos las principales fases de esta transición y hablaremos sobre los eventos y cambios recientes que se han producido en el proyecto..

Estambul hardfork

El 8 de diciembre de 2019 se llevó a cabo la primera etapa del hardfork de la red principal Ethereum. Se llamaba Estambul y constaba de seis actualizaciones. Estambul es la última actualización de red antes de una transición gradual a Ethereum 2.0.

Con el crecimiento de la red Ethereum, algunos contratos inteligentes se han vuelto demasiado intensivos en recursos. Dado que los costos computacionales de adquisición de datos y el tamaño del bloque aumentaron, mientras que el precio del gas no ha cambiado, existe un desequilibrio entre el consumo de recursos y los precios operativos. Esta falta de coincidencia permite una serie de ataques al sistema. Para eliminar la posibilidad de ataques, se aumentó el precio del gas para ciertos códigos operativos..

La actualización agregó la interoperabilidad de Ethereum y ZCash, así como la interoperabilidad con otras criptomonedas basadas en Equihash.. 

Además, se agregó el código de operación ChainID, que permite usar un identificador de cadena para evitar el llamado “ataque de repetición”. Este ataque fue posible porque la red hardfork dio lugar a la aparición de dos blockchains paralelas. Dado que las cuentas Ethereum y Ethereum Classic tienen las mismas direcciones y claves privadas y tienen dos redes separadas con dos cadenas de bloques separadas, cualquiera que tuviera fondos en la primera iteración se convirtió en propietario de los fondos en la segunda. El problema era que cuando una transacción se transmitía utilizando una de las redes, existía el riesgo de que se incluyera en ambas iteraciones..

La segunda fase del cambio de red central, denominada Berlín, que estaba programada para el 29 de mayo de 2020, se trasladó al otoño de ese mismo año. Berlín es la última y más importante actualización de Ethereum 1.0, necesaria para el lanzamiento de la fase cero de Ethereum 2.0 – Serenity.

Se planeó que la actualización de Berlín incluyera un algoritmo de prueba de concepto para reemplazar Ethash – ProgPoW (Prueba de trabajo programática).

ProgPoW es un algoritmo Ethash modificado para trabajar con la GPU. Al implementar este algoritmo, Ethereum se volverá más resistente a ASIC. En la red Ethereum, la implementación de ProgPoW es necesaria para evitar una bifurcación al cambiar al protocolo PoS.

Además del nuevo algoritmo, Berlín tuvo que traer las firmas modificadas requeridas para el funcionamiento del contrato de depósito ETH 2.0, que es utilizado por los validadores para interactuar con la cadena de bloques, así como para la participación contable de transacciones..

Además, antes de la actualización de Berlín, los desarrolladores tenían que ejecutar una red de prueba YOLO para comprobar la estabilidad de la red principal. Esto permitiría a los desarrolladores sincronizar las diferentes versiones, pero el plan falló debido a la falta de coordinación de los EIP aportados..

Es importante señalar que la llamada “Edad de Hielo” comenzó en la red Ethereum, un aumento en la dificultad de producción de ETH. Por este motivo, la red requiere una actualización.. 

Ethereum 2.0 – Serenidad

Serenity es una actualización de Ethereum 2.0 para cambiar el protocolo de contratos inteligentes y mover la red del algoritmo de consenso de PoW a PoS. La transición a PoS está destinada a resolver el problema de escalabilidad mejorando la capacidad de la red para confirmar, verificar y realizar transacciones..

Serenity se dividió en 3 fases:

  1. Fase cero – Cadena de balizas
  2. Fase uno: cadenas de fragmentos
  3. Fase dos: eWASM (Nueva máquina virtual Ethereum)

Cadena de balizas

Beacon Chain es una cadena separada en el protocolo Proof of Stake, que existirá en paralelo con la cadena de bloques PoW de Ethereum. Estará diseñado para controlar el trabajo de los validadores, seleccionar el siguiente creador de bloque, garantizar la distribución de recompensas y optimizar la red para una transición sin problemas a un nuevo protocolo. La fase de depuración del sistema se completó en enero de 2020. El protocolo Casper será el nuevo algoritmo de PoS, que reemplazará a Ethash y activará la “bomba de dificultad”.

Casper está diseñado para regular la red y consta de dos versiones:

  1. Casper FFG (Finality Friendly Gadget): una actualización que se implementará en la etapa de transición inicial. En esta etapa, se utilizará un algoritmo híbrido para lograr el consenso. Los bloques en la cadena de bloques se formarán a expensas de los mineros, pero se establecerá un punto de control para aplicar mecanismos de PoS..
  2. GHOST o CBC (correcto por construcción): una actualización para reemplazar a Casper FFG. Este paso está destinado a pasar al algoritmo de consenso de PoS.

Cadenas de fragmentos

Sin profundizar en los detalles, la fragmentación es un mecanismo que permite que conjuntos individuales de nodos procesen transacciones por segmentos. Esto significa que los nodos solo necesitan almacenar y procesar una determinada parte de una transacción, lo que aumenta el ancho de banda de la red. Los validadores de red utilizarán mecanismos de fragmentación para procesar transacciones y mantener la red..

Un mecanismo de fragmentación con integración de Plasma (un análogo de la red Lightning en Ethereum) puede aumentar significativamente la capacidad de la red. Gracias a Plasma, es posible crear contratos inteligentes para procesar datos en la segunda capa y enviar los resultados a la cadena de bloques principal..

En esta etapa, se lanzarán los mecanismos básicos de Shard Chains para un mayor despliegue de eWASM.

eWASM (montaje web de Ethereum)

Esta es una actualización de la especificación para EVM (Ethereum Virtual Machine), un entorno virtual, que facilita el funcionamiento y la interacción de los contratos inteligentes, así como el almacenamiento de transacciones. eWASM se ejecuta en WebAssembly y brinda la capacidad de crear contratos inteligentes en lenguajes de programación populares, lo que le permite integrar contratos inteligentes en navegadores web y sitios web.

El desarrollo de esta etapa está en los primeros días y es solo un concepto.

Conclusiones

Por el momento, todos los ojos están puestos en Ethereum debido al boom de DeFi: Ethereum es la principal plataforma que facilita numerosos proyectos de DeFi, aunque TRON y Binance ya han entrado en la carrera..

El interés en DeFi ha provocado un aumento en las comisiones de la red Ethereum y retrasos en su trabajo. La red ya se ha enfrentado a un problema de este tipo en 2017, debido a la aparición de tokens NFT y el proyecto CryptoKitties, que representó aproximadamente el 12% de toda la red..

A principios de agosto, se lanzó la red de prueba Ethereum 2.0, Medalla. Más de 42 mil validadores se unieron a la red, lo que estaba destinado a garantizar un proceso de transición sin problemas a PoS. Para llevar a cabo y ejecutar la fase de Serenity, la red de prueba tuvo que funcionar sin fallas durante 90 días, pero dos semanas después del lanzamiento, una falla provocó una bifurcación y los validadores perdieron su ETH. Por lo tanto, la red aún está en proceso de preparación para la fase cero..

La billetera móvil Metamask también se presentó recientemente para funcionar con tokens Ethereum y ERC-20. 

El proceso de transición a PoS, el bombo de DeFi, los problemas de ancho de banda y el aumento de los costos de transacción hicieron de Ethereum el tema de discusión este verano. Se pospone la transición a Ethereum 2.0, a la espera de la corrección de errores en la red de prueba.

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
map