The news is by your side.

Ethereum 2.0 Testnet ahora tiene que forzarse – Trustnodes


La falla del consenso de la red de prueba de ethereum 2.0 parece ser fatal con la red aún sin estar en funcionamiento después de tres días después de un error que derribó los nodos.

Ese error tuvo el efecto de bloquear instantáneamente todos los nodos prysm, que eran la gran mayoría, pero también aumentó los requisitos de recursos de otros clientes de nodos con nodos Lighthouse, por ejemplo, que necesitan 70 GB de almacenamiento y algo de memoria de 14 GB en algún momento.

Entonces, haciendo que la cadena se rompa en 4 bifurcaciones o más, con la única solución ahora aparentemente siendo una bifurcación dura como al explicar la elección de la bifurcación, Vitalik Buterin dijo anteriormente:

“Una cosa importante a tener en cuenta es que la elección de la horquilla no es una función pura; es decir, lo que aceptas como cadena canónica no depende solo de los datos que tengas, sino también de cuándo los recibiste.

La razón principal por la que se hace esto es para hacer cumplir la finalidad: si acepta un bloque como finalizado, nunca lo revertirá, incluso si luego ve un bloque en conflicto como finalizado.

Tal situación solo ocurriría en los casos en los que hay un ataque activo> 1/3 en la cadena; en tales casos, esperamos que se requieran medidas adicionales al protocolo para que todos los clientes vuelvan a la misma cadena ".

La explicación en sí misma no establece cuáles son estas medidas extraprotocoloras, pero en el único sutil comentario Buterin hizo sobre los eventos, se vincula a un artículo de 2016 que básicamente dice que si hay un ataque de 1/3, entonces simplemente te bifurcas.

En este caso, no hay un ataque como tal, o al menos no que sepamos, probablemente solo Peter Todd está haciendo algunas pruebas gratuitas, pero el código obviamente no puede diferenciar entre un ataque 'malicioso' y todo estos nodos caen repentinamente debido a un error "inocente".

Es decir, no puede diferenciar entre un ataque y un accidente, por lo que trata a ambos por igual.

Ciertos mecanismos complejos se han activado ahora con una parte del protocolo, el FFG de seguridad, que evita la finalización del bloque, mientras que la otra parte, el subárbol observado más pesado codicioso (GHOST), sigue contando votos.

"Dado que GHOST está en vivo, pero no es seguro, puede cambiar de opinión sobre el jefe de la cadena; esto se debe a que continuamente se agregan nuevos bloques a la cadena, lo que significa que los nodos siguen aprendiendo nueva información", Carl Beekhuizen, desarrollador de eth 2 , dijo anteriormente.

En resumen, GHOST no tiene ni idea de lo que está pasando, ya que FFG lo sabe y, por lo tanto, dice que la red no puede seguir avanzando.

Algunos desarrolladores sugieren que una vez que todos los clientes se sincronizan, pueden ver todo lo que está sucediendo y GHOST deja de cambiar de opinión, pero parece que incluso si los clientes se sincronizan con la sugerencia, todavía se quedan atrás de vez en cuando. Raul Jordan, un desarrollador de eth 2.0 para prysm, dice:

“Hoy estamos analizando por qué los nodos se quedan atrás una vez que se sincronizan con la cabeza de la cadena. Estamos recopilando la mayor cantidad de datos posible …

Tenemos varias preguntas sin respuesta aquí sobre las que necesitamos información:

1. ¿Por qué los nodos se sincronizan bien pero finalmente terminan rezagados? (Siempre pasa, es solo cuestión de tiempo).

2. ¿Este retraso se correlaciona con otros eventos, como el consumo de recursos, los pares con los que está conectado, etc.

3. Observe la propagación de objetos y la resolución de la bifurcación.

4. Analice el estado de las solicitudes de bloqueo principal y la rapidez con la que podemos resolverlas.. Hoy voy a mirar muchas listas de éxitos ".

No hay confirmación por parte de los desarrolladores de que esto tenga que ser difícil, siendo esa nuestra sugerencia basada en la información disponible y las declaraciones anteriores, y esto aparentemente es un poco como si una actualización de bitcoin sale mal y ahora tenemos dos cadenas como en 2013 o 2015 con ambas parecen ser cadenas válidas inicialmente hasta que una de ellas "gana".

Por supuesto, puede dejar que este proceso siga su curso y esperar semanas o más durante las cuales no es seguro usar la red, o puede tener alguna coordinación social para elegir un tenedor / cliente y descartar el otro.

A medida que suceden errores, y como se ha producido una falla de consenso y puede ocurrir en un entorno en vivo, arreglar ese proceso ahora debería hacer que la ejecución en vivo sea mucho más fluida.

Así que no hay prisa, ya que se trata de una red de prueba y es importante obtener toda la información sobre si todo funcionó y está funcionando como debería, y además, aunque esta es una red de prueba, tienen que hacerlo bien porque estamos seguros de que Todd et al está mirando.

Con la pregunta aquí siendo qué bifurcación elige y cómo, y también cómo tiene este cliente de hardfork, ¿qué cambia?

Esos son para que otros respondan, incluido quizás el propio Vitalik Buterin, que todavía es un desarrollador de eth 2, así como para otros desarrolladores de diseño o protocolo de eth 2.

Además, se pueden tolerar días en testnet, pero en un entorno en vivo, incluso una hora o dos es demasiado una vez que pasamos la fase 1.5, ya que hasta entonces sigue siendo una especie de testnet pero con eth real en la medida en que no haya transacciones o intercambios de valor y, por lo tanto, no hay historial completo o un libro mayor completo como tal.

Entonces, en ese punto, presumiblemente tendrá que haber una especie de cliente hardfork de respaldo que se active tan pronto como quede claro que ha habido una falla en el consenso.

Lo que significa que, aunque la óptica aquí no es excelente, en cierto modo no parece ser muy diferente de lo que sucedería en bitcoin, dependiendo, por supuesto, de cómo los desarrolladores resuelvan ahora esta situación en testnet.

Eso también significa que, conceptualmente, no debería haber ningún retraso en el lanzamiento en vivo, ya que todo parece haber funcionado como debería hasta ahora, con el error que lo pateó siendo muy pequeño y resuelto hace días, mientras que el resto parece ser el protocolo haciendo su trabajo.





Los comentarios están cerrados.