The news is by your side.

Ethereum 2.0 Testnet se divide en 4 bifurcaciones – Trustnodes


Actualmente, hay cuatro o cinco bifurcaciones principales en la red de prueba ethereum 2.0 (en la imagen) después de un error que derribó los nodos de Prysm y toda la red.

“Necesitamos que todos los clientes estén de acuerdo con el jefe actual. También está causando estragos en la sincronización con los compañeros que se unen y reclaman diferentes vistas de la cadena. Hay una variedad de casos extremos y soluciones que implementaremos durante toda la semana para abordar todos estos ”, dice Age Manning de Lighthouse.

"Salta arriba y abajo por todas partes … es como si no pudiera decidir", dice alguien que ejecuta el cliente prysm con Nishant Das, un desarrollador de prysm, diciendo: "Sí, muchas reorganizaciones".

"Hay muchas bifurcaciones diferentes en este momento y algunos nodos se quedan muy atrás, así que obtienes todas estas solicitudes de bloqueo principal para intentar resolverlo, pero la principal se muestra actualmente en eth2stats, que tiene consenso entre lighthouse y prysm ”, dice Raul Jordan, otro desarrollador de prysm.

Debido a todas estas horquillas, los requisitos de ram se dispararon alrededor de la medianoche de hoy, hora de Londres:

Bifurcaciones Ethereum 2.0 testnet, aumento de los requisitos de recursos de nodo, agosto de 2020

“Las técnicas de compresión de bases de datos más efectivas ocurren después de la finalidad”, dice Paul Hauner de Lighthouse. "También hemos visto algunos problemas con la base de datos que impiden la poda, pero no estoy seguro de que eso influya".

La situación ahora parece haber mejorado significativamente desde hace unas 12 horas, con más personas alcanzando la punta de la cadena.

A los corredores de nodo se les pide que lo dejen correr si pueden, en lugar de reiniciar, ya que eso simplemente pierde toda la sincronización hasta ese punto. También:

“Estoy usando –block-batch-limit = 512 & –p2p-max-peers = 200 parece estar avanzando”, dice un corredor de nodos.

El parámetro de par máximo no es parte de la recomendación de los desarrolladores, pero el límite de bloque de lotes es, con Das indicando:

"Entonces, cuando te quedas atascado, es un ciclo entre tus pares para tratar de despegarte, el uso de lotes de mayor tamaño pasará a través de esos pares más rápido".

Varias personas afirman haber recibido algún error sobre la solicitud de bloqueo principal. Se les pide que simplemente lo ignoren ya que el nodo está pasando por todas las bifurcaciones y Preston Van Loon publica un árbol de la red.

Aparentemente puedes conseguir este árbol yendo a localhost:8080/tree, que le permite ver cómo va la cadena.

Como era de esperar, eso muestra inicialmente una cadena funcionando bien, y luego tenemos dos, y tienen su propia cadena, todas las cuales finalmente desaparecen con una cadena ejecutándose nuevamente.

Cadena permanente de la red de prueba Ethereum 2.0, agosto de 2020
Cadena permanente de la red de prueba Ethereum 2.0, agosto de 2020

Los nuevos nodos aparentemente solo necesitan pasar por la sincronización, y necesitan ser conscientes de estas bifurcaciones, y luego dejan esas bifurcaciones con el nodo y luego saltan a la punta válida.

Aparentemente, esto debe llegar a una tasa de participación del 66%, y aquellos que han disminuido serán recortados hasta entonces:

El corredor de nodos de la red de prueba Ethereum 2.0 está siendo reducido.

Este etéreo estaba ganando bastante dinero al no hacer nada después de activar la configuración del nodo.

Además, incluso después de la reducción, todavía tiene ganancias, pero puede ver que el camino hacia arriba fue mucho más lento que el camino hacia abajo. Estaba ganando por día, ahora está perdiendo por horas.

Eso significa que tiene grandes incentivos para volver a sincronizarse, ya que cuanto antes él y otros puedan llegar a la punta de la cadena, más rápido volverá a ganar en lugar de perder dinero.

Los desarrolladores están haciendo todo lo posible para ayudarlo en el camino, probando diferentes trucos y soluciones al mismo tiempo que ayudan a cualquiera que necesite ayuda en su discordia.

Algunos anunciaron con orgullo que llegaron a la punta, con lo que era un efecto dominó en el camino hacia abajo, ahora potencialmente un efecto dominó en el camino hacia arriba, ya que cuantos más nodos haya en la punta, más nodos se pueden sincronizar con él.

“Medalla está lejos de estar muerta, se puede arreglar”, dice Loon y tiene que ser reparado porque esto también podría suceder en vivo.

Bitcoin, por ejemplo, ha tenido bifurcaciones divididas en cadena dos veces o más en la red principal después de que un error durante una actualización hizo que los mineros estuvieran en diferentes versiones.

Sin embargo, la red bitcoin sigue funcionando durante ese tiempo, lo que lleva a anuncios en las redes sociales que le dicen a las personas que esperen 100 confirmaciones o más.

Mientras que aquí, si se eliminan el 34%, la red deja de funcionar hasta que se comportan.

Esta es una historia en desarrollo, por lo que aún no se sabe cómo se comportan exactamente porque no se han encontrado nuevas ranuras / bloques ya que la cadena no se está finalizando actualmente.

Hacer de todo esto un simulacro de lo que podría suceder en vivo a medida que ocurren los errores a pesar del mayor cuidado con las lecciones aprendidas, como tener algún método para exportar claves rápidamente a otros clientes. Un desarrollador de prysm dice:

“El objetivo de tener varios clientes es que puede cambiar a una alternativa en caso de que algo no funcione correctamente en su cliente principal.

Cuando ayer tuvimos los problemas de tiempo de ejecución, podría haber sido una buena idea cambiar a otro cliente para evitar la penalización de la vida ".

Roughtime, por lo que es una forma descentralizada de sincronizar el tiempo que resultó no estar muy descentralizada, ya que seis fuentes de tiempo diferentes, por alguna razón, hicieron que los nodos prysm se adelantaran cuatro horas, dando un error y, por lo tanto, la falla de la red. Das dice:

“El bloque que llega también tiene un número de ranura a través del cual determinamos si es válido o no. Básicamente genesis_time + slot_Num * slot_time.

Si un nodo piensa que está 4 horas en el futuro, rechaza ese bloque ya que parece que proviene del pasado.

Esto también arruina la propuesta de bloqueo de validadores de prysm, ya que ahora el reloj local según el validador está 4 horas adelantado ".

La solución para eso fue algo simple al no incumplir el tiempo de ejecución, lo que llevó a los desarrollos interesantes que ahora se están desarrollando en testnet, que es con eth falso, por lo que no se pierde nada y se gana mucho.

Además, si la red vuelve a la vida a través de los mecanismos codificados que se activan, esto no debería retrasar el lanzamiento en vivo, ya que todo habría sucedido como se supone que debe suceder con el error en sí siendo muy, muy pequeño, suponiendo que no haya complicaciones relacionadas con el código con los mecanismos que se activaron.



Los comentarios están cerrados.