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 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 of Lighthouse.
" Salta arriba y abajo por todas partes … es como si no pudiera decidir ", alguien que ejecuta el cliente de prysm dice con Nishant Das, un desarrollador de prysm, y dice: "Sí, muchas reorganizaciones".
"Hay muchas bifurcaciones diferentes en este momento y algunos nodos están atascados muy atrás por lo 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 para todas estas bifurcaciones, los requisitos de RAM se dispararon alrededor de la medianoche de hoy, hora de Londres, alcanzando los 70 u 80 gigabytes.
“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 aquí".
La situación ahora parece haber mejorado significativamente desde hace unas 12 horas con más llegando a la cadena. tip head.
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. Además:
“Estoy usando –block-batch-limit = 512 & –p2p-max-peers = 200 parecen 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, está pasando por tus pares para tratar de despegarte, el uso de tamaños de lotes más grandes pasará por esos pares más rápido".
Varias personas afirman haber recibido algún error sobre el bloqueo de la solicitud principal. Se les pide que simplemente lo ignoren ya que el nodo está pasando por todas las bifurcaciones con Preston Van Loon publicando un árbol de la red.
Aparentemente, puede obtener este árbol yendo a localhost: 8080 / tree lo que le permite ver cómo avanza la cadena.
Como era de esperar, eso muestra inicialmente una cadena funcionando bien, y luego tenemos dos, y ellos tienen su propia cadena, todo lo cual eventualmente
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 deben 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 las que han caído se reducen drásticamente hasta entonces: [19659020] El corredor de nodos de la red de prueba Ethereum 2.0 está siendo cortado.
Este ether ean 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 abajo. Estaba ganando por día, ahora está perdiendo por hora.
Eso significa que tiene grandes incentivos para volver a sincronizar, ya que cuanto antes él y otros puedan alcanzar la punta de la cadena, más rápido volverá a ganar en lugar de perdiendo 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 pueden sincronizarse con él.
“Medalla está lejos de estar muerta, se puede arreglar, Loon dice y tiene que arreglarse porque esto podría suceder potencialmente en vivo también.
Bitcoin, por ejemplo, ha tenido bifurcaciones divididas en cadena dos o más veces en la red principal después de que un error durante una actualización provocó que los mineros estuvieran en diferentes versiones. [19659004] Sin embargo, la red bitcoin sigue funcionando durante ese tiempo, lo que lleva a soci todos los anuncios en los medios que le dicen a la gente que espere 100 confirmaciones o más.
Mientras que aquí, si el 34% es eliminado, la red deja de funcionar hasta que se comporta.
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 está finalizando actualmente.
Haciendo de todo esto un simulacro de lo que podría potencialmente suceden en vivo cuando ocurren errores a pesar del mayor cuidado con las lecciones aprendidas, como tener algún método para exportar rápidamente las claves 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 tuvimos los problemas de tiempo de ejecución ayer, 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 hizo que los nodos prysm saltaran cuatro horas antes, dando un error y, por tanto, la red se bloquea. Das dice:
“El bloque de llegada que ingresa 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 cree que está 4 horas en el futuro, rechaza ese bloque ya que parece que viene del pasado.
Esto también ensucia la propuesta del bloque de validadores de prysm, ya que ahora el local el reloj de acuerdo con el validador está 4 horas adelantado ”.
La solución para eso fue algo simple en simplemente no incumplir con 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 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í muy, muy pequeño, suponiendo que no haya complicaciones relacionadas con el código con los mecanismos que se activaron.