La falla del consenso de la testnet 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 los 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 14 GB de memoria en algún momento.
Así que la cadena se dividió en 4 bifurcaciones o más, con la única solución ahora aparentemente siendo una horquilla dura como al explicar la elección de la horquilla, Vitalik Buterin dijo previamente:
“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 sucedería en los casos en que hay un ataque activo> 1/3 en la cadena; en tales casos, esperamos que se requieran medidas extra-protocolo para que todos los clientes vuelvan a la misma cadena ”.
La explicación en sí no establece cuáles son estas medidas extra-protocolo, pero en el único comentario sutil que hizo Buterin sobre los eventos, enlaza con un artículo de 2016 que básicamente dice que si hay un 1/3 de ataque, entonces simplemente te bifurcas.
En este caso no hay un ataque como tal, o al menos no que sepamos de él. probablemente solo Peter Todd está haciendo algunas pruebas gratuitas, pero el código obviamente no puede diferenciar entre un ataque "malicioso" y todos estos nodos que caen repentinamente debido a un error "inocente".
Es decir, no puede diferencia entre un ataque y un accidente, por lo tanto, trata a ambos de la misma manera.
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 Greedy Heaviest Subárbol observado (GHOST), sigue contando votos.
“Since GHOS T está activo, pero no 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 ”, dijo Carl Beekhuizen, un desarrollador de eth 2. 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 moviéndose.
Algunos desarrolladores sugieren que una vez que todos los clientes se sincronizan pueden ver todo lo que continúa 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 …
Aquí tenemos varias preguntas sin respuesta 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. ¿Se correlaciona este retraso con otros eventos, como el consumo de recursos, los pares a 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 mucho los gráficos ”.
No hay confirmación por parte de los desarrolladores de que esto tenga que ser difícil, ya que esa es nuestra sugerencia basada en la información disponible y las declaraciones anteriores, y esto aparentemente es un poco como si se hiciera una actualización de bitcoin. mal y ahora tenemos dos cadenas como en 2013 o 2015, y ambas parecen ser cadenas válidas inicialmente hasta que una de ellas "gane".
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 podría tener cierta coordinación social para elegir un cliente / cliente y descartar el otro.
A medida que ocurren errores y fallas en el consenso, se han producido y pueden ocurrir en un entorno en vivo, arreglando ese proceso ahora debería hacer que la ejecución en vivo sea mucho más fluida.
Por lo tanto, no hay prisa, ya que esta es una red de prueba y obtener toda la información sobre si todo funcionó y se está ejecutando como debería es importante, y además, aunque esto es un testnet que hacen tienes que hacerlo bien porque estamos seguros de que Todd et al están observando.
Con la pregunta aquí siendo qué bifurcación eliges y cómo, y también cómo tienes este cliente hardfork, ¿qué cambia? [19659004] Esos son para que otros los 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 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 hay transacciones o intercambios de valores 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 la óptica aquí no es excelente , en cierto modo no parece ser muy diferente de lo que sucedería en bitcoin, depende ding, por supuesto, sobre cómo los desarrolladores ahora resuelven 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, por lo que se sabe hasta ahora, con el error que lo pateó todo siendo en sí mismo muy pequeño y resuelto instantáneamente hace días, mientras que el resto parece ser el protocolo haciendo su trabajo.