Como comprobación de validez, verificamos qué nodos adicionales reciben este mensaje (es decir, no confirme bloques a través del algoritmo de consenso). Descubrimos que otros nodos ocasionalmente también reciben bloques a través de la sincronización de bloques. Está bien que esto suceda de vez en cuando, pero el nodo A lo mostró para el 100% de los bloques.
En este punto, establecimos que el Nodo A no logra alcanzar el consenso el 100% del tiempo, por lo que era el momento de profundizar en los registros del algoritmo de consenso de Lean Helix para seguir el flujo del Nodo A y comprender qué es lo que no funciona.
Ahora nos centramos solo en los registros de Lean Helix para limitar la investigación. Todos los registros de Lean Helix tienen una propiedad llamada lhlib que se establece en verdadero, por lo que es fácil filtrar solo estos mensajes agregando una condición de que exista la propiedad lhlib; consulte a continuación:
Centrémonos en un bloque específico que el Nodo A tuvo que recibir de la sincronización de bloques, pero otros nodos lograron comprometerse por consenso: 454927. Obtuvimos este número de bloque de la captura de pantalla con los mensajes de "bloqueo confirmado con éxito mediante la sincronización" arriba. Observe la cadena de búsqueda "H = 454927" en la siguiente captura de pantalla:
Podemos ver que el Nodo A está ignorando los mensajes de consenso (como el mensaje de COMPROMISO descrito en la captura de pantalla anterior), ya que "PREPREPARE no está almacenado" (igual que "no se recibió en absoluto" para nuestros propósitos). Para entender lo que significa este mensaje de registro, aquí hay otra nota técnica:
Cuando el nodo líder propone un bloque a los otros nodos, lo hace transmitiendo un mensaje de PREPARACIÓN que contiene el bloque, a los otros nodos. Luego, los otros nodos "debaten" entre ellos, ya sea que estén de acuerdo con el bloque propuesto o no, al pasar por más tipos de mensajes, como PREPARAR y COMPROMETAR (no es necesario discutirlos aquí). PREPARACIÓN es el mensaje inicial enviado por el líder y contiene el bloque propuesto. Si no fue recibido por algún otro nodo, ese otro nodo rechazará recibir cualquier otro mensaje de consenso posterior relacionado con ese bloque, porque no tiene sentido participar en el consenso si el nodo no tiene el bloque propuesto, para comenzar con .
A continuación, llegó el momento de entender. por qué PREPARACIÓN no fue recibida por el Nodo A.
Otra nota técnica más: Como dijimos, el líder de la primera vista (V = 0) envía un mensaje de PREPARACIÓN que contiene el bloque propuesto. Ahora, si el líder no logra un consenso dentro del límite de tiempo, es reemplazado por otro líder, ahora en V = 1. Aquí hay un giro: por lo general, ese nuevo líder de V = 1 utilizará el mismo bloque propuesto por el líder anterior (más barato que crear un nuevo bloque en sí). Enviará el bloque reutilizado a los otros nodos dentro de un mensaje NEW_VIEW. Ese mensaje NEW_VIEW contiene en su interior el mensaje PREPREPARE del líder anterior junto con el bloque reutilizado (esencialmente el nuevo líder dice: "Oye, el bloque propuesto del último líder era válido, simplemente no logramos llegar a un acuerdo a tiempo, así que intentémoslo de nuevo")
Luego, llegó el momento de buscar dónde el Nodo A recibió realmente una PREPARACIÓN (si es que lo hizo) del líder y descubrir qué fue lo que falló.
Resulta que el nodo A recibió PREPARACIÓN del líder.
Aquí está, vamos a romper esta captura de pantalla hacia abajo:
A las 16: 05: 23.988, el nodo A recibe un mensaje NEW_VIEW del líder de V = 1 (remitente = "ff33c7"). Como se explica en la última nota técnica, esto se espera. Lo siguiente que debería suceder es que el Nodo A desempaquetar el mensaje interno de PREPARACIÓN, y de ella, a desempacar el bloque y validar eso.
NEW_VIEW fue desempaquetado y su contenido PREPREPARE también fue desempaquetado (simplemente no está registrado), sin embargo El intento de validar el bloque contenido. falla, debido a la marca de tiempo del bloque. ¡Esto es raro! Ningún otro nodo falló en validar este bloque.
Entendamos el mensaje de error descrito:
currentTimestamp = 159df14e0fab5b36 se traduce al 12 de mayo de 2019 13:06:03 (con la ayuda de una calculadora hex → decimal y este sitio que convierte milis desde la época a la cadena de tiempo ISO8601). prevTimestamp = 159df14bde5aed90 Se traduce al 12 de mayo de 2019 13:05:54. Hasta ahora todo bien: la marca de tiempo del bloque actual es posterior a la marca de tiempo del bloque anterior, lo que tiene sentido.
A continuación, vemos: ahora 2019–05–12 13: 05: 23.989402103.
¡Esto no tiene sentido! ¿Cómo puede ser "ahora" en la máquina? más temprano ¿Por 40 segundos que el tiempo del bloque actual? más adelante en esa línea, puede ver la tolerancia entre "ahora" y la marca de tiempo del bloque es de 30 segundos ( jitter 30s) y debido a que la diferencia es mayor (40 años), la validación falla y todo lo anterior resulta de ello.
Nota: este mensaje de error es ciertamente confuso y ya se ha hecho legible para los humanos como resultado de esta investigación.
En este punto, estábamos casi convencidos de que se trata de un error de reloj de la máquina en el Nodo A, ya que este código funciona correctamente en todos los demás nodos.
Después de contactar con el departamento de TI del nodo A, identificaron una desviación de 29 segundos en el reloj de la máquina y lo arreglaron de inmediato.
Unos minutos después de que fijaron la hora del reloj de la máquina, tomamos estas capturas de pantalla:
La captura de pantalla de arriba muestra que el síntoma V = 2 desapareció. Para estar en el lado seguro, la captura de pantalla a continuación muestra que el nodo A logró participar en un consenso y cometer un bloque, por lo tanto Ya no dependes de Block Sync.
Algunas conclusiones:
Escriba estudios de caso como este, para el beneficio de la comunidad, de modo que se puedan compartir y analizar los procesos de pensamiento del equipo central de Orbs. Mejore el tablero de mandos para que los problemas se puedan entender a partir de gráficos y medidores, a fin de posponer el costoso análisis de registros. gráfico y alerta contra la deriva del tiempo del nodo. Mejore los registros como un proceso iterativo
El propósito de este post fue arrojar algo de luz sobre la solución de problemas de la plataforma Orbs junto con notas técnicas sobre algunos trabajos internos.
Obviamente, tener un conocimiento detallado del sistema hace que este proceso sea más fácil, pero la lectura de gráficos del tablero y el filtrado a través de registros es una habilidad generalmente útil que se puede aplicar a cualquier sistema monitoreado.
¡Gracias a Ron Bresler por ayudarnos en la revisión de esta publicación!