Pasamos la mayor parte de esa semana trabajando en estos problemas anteriores, y mantuvimos el clúster de TdS fuera de línea durante varios días hasta que tuvimos una solución para algunos de los ataques críticos destacados identificados gracias a nuestra comunidad Validator, incluidos varios problemas de estabilidad de alta prioridad relacionados con las instantáneas .
Estas soluciones se capturaron en la versión v0.23.6 y se utilizaron para volver a poner en línea el clúster Tour de SOL durante el fin de semana para una prueba de esfuerzo final que funcionó bien Obviamente, todavía hay varios problemas conocidos que aún deben rectificarse (como se destacó anteriormente) en esta versión, pero en general hemos recorrido un largo camino desde que comenzamos la Etapa 1.
¡¿Qué es lo siguiente?!
Con la nueva versión probada bajo estrés, la hemos usado para actualizar el clúster SLP1 a SLP2 para que los socios que se integran en Solana también puedan cosechar los beneficios de estas últimas mejoras.
En cuanto a la red TdS, tenemos la intención de hacer una transición pronto para probar nuestra versión beta de Mainnet v1.0.X, sin embargo, conservaremos el mismo libro de contabilidad después de la actualización (lo que significa que todos los que actualmente están delegados siguen siéndolo). La línea de lanzamiento v1.0.x (anteriormente conocida como v0.24.0) es una versión extremadamente importante para nosotros, ya que será fundamental para el lanzamiento de Mainnet Beta de Solana después de las pruebas de estrés. Por lo tanto, en las próximas semanas, ¡esperamos volver a reunirnos con nuestra comunidad Validator existente y dar la bienvenida a nuevos participantes!
Nota: También planeamos armar un bot de delegación después de implementar la versión v1.0.X que agregará automáticamente una delegación a los nuevos Validadores actuales y eliminará la delegación de los Validadores morosos.
Bienvenido de nuevo a todos los que han estado siguiendo nuestro progreso durante el Tour de SOL. Ha sido otra semana llena de eventos. Hemos enviado varias soluciones a problemas identificados en los últimos días, mientras que algunos problemas siguen pendientes, ya que esperamos que tarden más en solucionarse.
PROGRESO EN ERRORES CRÍTICOS
El ataque DoS de Certus Ones
Durante los primeros días de la semana pasada, mantuvimos la red fuera de línea mientras intentamos solucionar rápidamente el error resaltado por el exitoso ataque DoS de Certus One, sin embargo, después de trabajar en ello durante varios días, concluimos que la solución requeriría algo de tiempo y esfuerzo adicionales para ser resuelto. Por lo tanto, decidimos restaurar la red primero:
Como teníamos varias otras soluciones para otros problemas listos para ser implementados, permítanos continuar identificando más errores Con un acuerdo junto con la comunidad del Validador de que el ataque DoS estaría prohibido hasta que se indique lo contrario
Otros problemas de estabilidad de alta prioridad
Fuera del ataque mencionado anteriormente, todavía tenemos varios otros problemas en los que nos centraremos en las próximas semanas:
ACTUALIZACIONES DE RED
Tofino v0.23.4
El clúster se reinició el 12 de febrero con la versión v0.23.4, capturando arreglos en las siguientes áreas:
SnapshotsRepairGossip Network
Actualizamos con éxito el clúster con la nueva versión al día siguiente, y nuestro nodo Validator bootstrap finalmente logró distribuir su participación al resto del clúster de modo que representara menos del 33% de la participación activa.
Tofino v0.23.5
Seguimos con otra versión el 14 de febrero con otra actualización para rectificar un problema de falta de memoria que afectaba a algunos Validadores.
Comentarios finales
A partir de hoy, la red aún está inactiva debido al problema mencionado anteriormente, en el que los validadores recuperan accidentalmente instantáneas de nodos delincuentes. Hasta que esto se resuelva, no reiniciaremos la red todavía, ya que probablemente hará que la red se bloquee nuevamente después de unos días.
Estamos oficialmente una semana en la Etapa 1 del Tour de SOL (TdS), y qué semana ha sido. Nuestro objetivo era comenzar a probar nuestra última versión v0.23.3 y resolver cualquier problema importante en esta versión con el objetivo de usarla para actualizar nuestro clúster Soft Launch Phase 1 (SLP1) al Global Cluster (GC), el primer lanzamiento importante de nuestro clúster. A partir de ahora, hemos tenido 2 reinicios de clúster, 1 error crítico identificado y una serie de errores más pequeños identificados en los que estamos trabajando actualmente. Basta decir que ha sido todo lo que esperábamos que fuera cuando comenzamos a lanzar este evento.
ATAQUES / ERRORES
¡Felicitaciones al equipo de Certus One, que presentó con éxito el primer RP por un error crítico! Con este ataque, lograron armar un error de pérdida de memoria en la red de chismes para matar de hambre al asignador del núcleo, que eliminaría cualquier Validador en el clúster (ya sea uno a la vez o todos a la vez).
Enlace a la edición 9
Si se refiere al diagrama a continuación, así es como reacciona el clúster cuando se realiza este ataque. El diagrama a la izquierda muestra una brecha cada vez mayor entre el último bloque y la última vez que se finalizó un bloque cuando un grupo sano mostraría una línea plana. El diagrama de la derecha debería verse como una función que aumenta linealmente, en cambio, es una línea plana que indica que no se está logrando el consenso.
Diagrama 1: Consecuencias del ataque
OTROS ASUNTOS IDENTIFICADOS
La buena noticia es que, a pesar de los siguientes 2 problemas, el clúster logró mantenerse con vida, sin embargo, provocó una cantidad razonable de fricción de incorporación para los Validadores:
Claves públicas mixtas en grupos de SolanaLas redes de chismes en TdS y SLP1.1 se fusionaron en un clúster más grande durante el período de incorporación. Hace algunas semanas, algunos de ustedes pudieron haber visto nuestro anuncio sobre el lanzamiento de nuestro clúster SLP1 1, que se ejecuta en paralelo a TdS . Para conectarnos a esto y a cualquiera de nuestros otros clústeres, el proceso es que generalmente requerimos que los Validadores nos proporcionen su clave pública, un identificador público para su nodo. Por lo tanto, cuando los Validadores comenzaron a conectarse al nuevo clúster TdS durante la configuración inicial Durante el período de incorporación de 24 horas, recolectamos sus claves públicas con anticipación para poder delegarles tokens y hacerlos estacar. Algunos de los Validadores que se conectaron en línea, reutilizaron las mismas claves públicas que estaban usando para el clúster SLP1. Como resultado, estos Validadores, que no pudieron identificar que el grupo SLP1 y los grupos TdS estaban separados, fusionaron los grupos de chismes entre los dos en un todo más grande, y finalmente convirtieron a los Validadores en delincuentes.Punto de entrada RPC sobrecargadoEl punto de entrada RPC para el Validador tds.solana.com se agregó para cotillear varias veces, lo que condujo a un tráfico entrante excesivo, la gestión ineficiente del tráfico adicional finalmente llevó a que nuestro Validador se quedara sin memoria. Para los Validadores que se unen al grupo Tour de SOL , hay dos métodos para conectar su Validador: Usar el punto de entrada RPC existente provisto por Solana Configurar su propio punto de entrada RPC La primera opción es, con mucho, la más conveniente. Sin embargo, durante las primeras 48 horas de la puesta en línea del clúster, los validadores descubrieron que estaban teniendo un éxito intermitente en la utilización del único punto de entrada RPC que habíamos preparado después de múltiples intentos. Mientras todavía estamos depurando esto, observamos dos problemas clave. Primero fue que nuestro punto de entrada RPC se agregaba a la red de chismes varias veces (al menos 10 veces), lo que generaba una cantidad significativa de tráfico incrementado, lo que se debía a un problema con la instantánea. El segundo problema que se hizo evidente como consecuencia de eso fue que el nodo RPC no pudo administrar adecuadamente el tráfico adicional y, como resultado, se quedó sin memoria. Es posible que haya otros factores involucrados, sin embargo, todavía estamos investigando a partir de este momento.
REPOSICIONES DE CLUSTER
Migración fallida del nodo líder BootstrapEn un intento de migrar el nodo de rutina de carga de Google Cloud a una configuración de ubicación conjunta, lo que hace que retransmita un bloque y el resto del clúster se bifurca, por lo que pierde el consenso de forma permanente.Interrupción del clúster en el centro de datosDebido a una interrupción del clúster en nuestro Centro de datos que alojaba nuestro nodo de arranque, el clúster dejó de avanzar y nos obligó a reiniciar el clúster.