Desarrollador de Eth2 habla sobre los desafíos y las lecciones aprendidas antes del lanzamiento de la red principal

Luego de años de retrasos y cambios de planes, finalmente se acerca al lanzamiento de Ethereum 2.0 este 1 de diciembre.

La Fase 0 de Ethereum 2.0 presenta el tan esperado mecanismo de participación en la plataforma de contrato inteligente, además de lanzar el esqueleto de una futura cadena de bloques de Eth2, la Beacon Chain.

El progreso en 2020 se aceleró de manera constante a medida que se introdujeron e iteraron más y más redes de prueba. Si bien tuvieron éxito en conjunto, no estuvieron exentas de problemas relacionados con la sincronización y la producción de bloquese.

Parte de esos problemas provienen del desafío de mantener el mismo ritmo entre siete clientes diferentes, o el software de nodo Ethereum 2.0, trabajando con diferentes lenguajes de programación y tecnología.

Cointelegraph habló con Zahary Karadjov, desarrollador de investigación de Nimbus, uno de esos clientes, para obtener más información sobre el camino que Ethereum 2.0 ha recorrido hasta ahora y las próximas etapas del viaje.

La entrevista ha sido ligeramente editada por su extensión y contexto.

Cointelegraph: Nimbus parece haber tenido algunos problemas más para ponerse al día con las especificaciones compartidas de Ethereum 2.0. ¿Por qué crees que es?

Zahary Karadjov: Estábamos muy ocupados preparando a Nimbus para la mainnet. Es justo decir que ha sido un poco más desafiante para nosotros porque nos tomó un tiempo desarrollar algunos de los componentes que los otros equipos ya tenían disponibles, más específicamente, la capa de red Libp2p.

Esto es algo que tuvimos que construir desde cero, y nos llevó bastante tiempo estabilizarlo. Hubo algunos meses en los que tuvimos problemas con el rendimiento. Solo recientemente publicamos nuestra versión estable inicial. Pero en este momento, nos sentimos confiados para llevarlo a mainnet: estamos trabajando en el último de los pequeños problemas y nuestra auditoría también se completó.

CT: Prysm y Lighthouse, que de forma similar a los clientes existentes de Ethereum 1.0 se crearon en Go y Rust, respectivamente, parecen haber estado por delante de los demás hasta ahora. ¿Eso se debe a que pudieron aprovechar el trabajo realizado para Ethereum 1.0?

ZK: Mi explicación será una simplificación, ya que hay muchos factores involucrados. Pero diría que el desarrollo de Libp2p ha sido la fuente más importante de retrasos para nosotros. Y la lógica es fácil de ver aquí: Teku, que está desarrollado en Java, tampoco tenía una implementación de Libp2p, y también estuvo listo en una etapa ligeramente posterior.

El equipo de Prysm tuvo el lujo de tener Libp2p desarrollado hace mucho tiempo, como se desarrolló originalmente en Go, mientras que Lighthouse pudo aprovechar la implementación creada, nuevamente, hace bastante tiempo por el equipo de Parity para su trabajo en Polkadot.

Libp2p es la capa de red de Ethereum 2.0; se puede decir que es una tecnología completamente diferente a la que se usa en Ethereum 1.0. En términos más prácticos, es una tecnología de publicación y suscripción llamada Gossipsub, que es una forma optimizada de transmitir información en la red.

CT: Hablemos de la red de prueba de Medalla. ¿Qué lecciones aprendieron Nimbus y la comunidad Eth2, especialmente considerando los períodos en los que la cadena de bloques no proporcionaba garantías de finalidad de bloque?

ZK: Bueno, las dificultades con la finalidad comenzaron con un problema técnico. Está el famoso incidente de Cloudflare Roughtime, que demostró exactamente lo que estábamos discutiendo en nuestra conversación anterior. Si todo el mundo en la red está usando el mismo cliente, un problema técnico en este cliente en particular podría poner fuera de línea a muchos validadores, lo que puede hacer que la red pase inmediatamente a un estado de no finalización.

Tuvimos este problema con el cliente de Prysm y también enseñó una lección valiosa sobre la importancia de la comunicación. El equipo de Prysm pudo solucionar este problema en muy poco tiempo, solo un par de horas. Pero la comunidad tardó bastante en darse cuenta de que había un problema e implementar la solución.

Este fue el incidente inicial que generó un largo período de no finalización para Medalla. Pero esto fue realmente muy útil para los clientes porque cuando la red no está finalizando, los clientes tienen que considerar muchas bifurcaciones posibles diferentes e historias alternativas, y esto pone mucho estrés en los clientes. Entonces, estos largos períodos de no finalización nos permitieron ver y optimizar a los clientes para estos momentos estresantes en la red donde todo no está funcionando como se esperaba.

CT: Durante el período de prueba y de no finalidad, algunos usuarios se quejaron de que su participación se redujo incluso si estaban en línea. ¿Es eso un error o una característica del sistema?

ZK: Podría describirlo como una consecuencia imprevista. Básicamente, el problema es que el cliente es recompensado por las certificaciones difundidas en la red. Pero se supone que estas atestaciones se incluyen en bloques. Si no hay nadie para producir bloques, sus certificaciones no terminan en la cadena. Entonces, parece que no estás activo.

Creo que este problema está bien reconocido por el equipo de implementación y el equipo de investigación. Debería abordarse en el futuro de Ethereum, en la Fase 1, o incluso en la Fase 0.5, una de las primeras actualizaciones de la red. Pero no debemos olvidar que sería bastante inesperado si vemos tasas de participación bajas en la red principal, ya que cuando hay un interés real involucrado, los incentivos para que los validadores estén en línea son mucho más fuertes.

CT: ¿Crees que estas complejidades y el requisito de estar constantemente en línea podrían alejar a las personas de apostar con sus propios dispositivos?

ZK: Bueno, este es un concepto erróneo muy común de que creo que deberíamos hacer un mejor trabajo en la comunicación. En realidad, los riesgos de no estar en línea todo el tiempo no son tan grandes. Obtendrás ganancias si estás en línea más del 50% del tiempo. Piénsalo: puedes estar desconectado durante la mitad del año y todavía estarás en cero. No ganarás dinero, pero tampoco perderás dinero. El protocolo es bastante indulgente en este sentido.

CT: ¿Qué viene después del lanzamiento de la red principal de la Fase 0? ¿Sharding es la próxima actualización de la lista o espera que se requiera más trabajo para esta cadena de bloques inicial?

ZK: Ciertamente habrá actualizaciones con la integración de la Fase 1, y requeriría cambios importantes, o llamémoslos simplemente una bifurcación dura, donde los equipos de clientes lanzarán nuevo software a medida que se incorporen más funcionalidades. Esperamos el lanzamiento del dispositivo de finalidad en algún momento, que finalizará la cadena Ethereum 1.0 a través del mecanismo de consenso de Ethereum 2.0. Todos estos lanzamientos en curso se realizarán en paralelo. Son un poco independientes entre sí y forman parte de la hoja de ruta de Ethereum para los próximos años.

Sigue leyendo: