Actualización de Ingeniería del Hub y Lanzamiento de la Primera Cadena de Consumidores

https://medium.com/the-interchain-foundation/hub-engineering-update-first-consumer-chain-launch-ae680a3020bc

Es hora de una actualización de ingeniería del equipo del Cosmos Hub de Informal Systems.

Utilizando la Seguridad Replicada por primera vez, Neutron fue lanzado oficialmente como una cadena de consumidores el 11 de mayo. Esta actualización cubre la actualización de ingeniería para el período de abril a mayo de 2023, ¡que incluyó el lanzamiento de Neutron!

¡La Primera Cadena ICS! - Retrospectiva del Lanzamiento de Neutron El lanzamiento de cadenas de consumidores se ha realizado en un gran número de ocasiones en las testnets y, de hecho, se realiza cientos de veces a la semana en nuestras pruebas automatizadas. Por lo general, los detalles técnicos de un lanzamiento de cadena de consumidores son demasiado aburridos para escribir sobre ellos. Sin embargo, la vida real inevitablemente difiere de las pruebas. Tuvimos algunas complicaciones durante el lanzamiento de Neutron, pero nada que causara problemas permanentes, y los problemas no deberían repetirse en futuros lanzamientos. Aquí resumiré el lanzamiento y las complicaciones.

Nota: cuando digo "nosotros" en este artículo, no me refiero solo al equipo de Informal. Fue un esfuerzo de muchos equipos liderados por Neutron, incluyendo nosotros, la ICF, Hypha, Strangelove, CryptoCrew y, por supuesto, todo el conjunto de validadores.

Problemas de multisig reportados y solucionados - del 25 de abril al 4 de mayo Un par de semanas antes del lanzamiento, comenzamos a recibir informes de que los validadores tenían problemas para usar multisig y dispositivos Ledger para firmar transacciones de asignación de claves. Por defecto, los validadores utilizan las mismas claves en las cadenas de consumidores que en el Hub, pero se considera una buena práctica de seguridad utilizar una clave diferente para las cadenas de consumidores, y eso es lo que permiten las transacciones de asignación de claves.

Resultó que los dispositivos Ledger y las multisig no podían firmar transacciones de asignación de claves debido a complicaciones relacionadas con Amino, un formato de datos que ha sido ampliamente eliminado de Cosmos, pero que todavía se utiliza en dispositivos Ledger y multisig. La solución a esto implicó un pequeño cambio en el formato de las transacciones de asignación de claves.

Terminamos este cambio alrededor del 4 de mayo, la semana antes del lanzamiento, y enviamos un aviso de una actualización de emergencia que se llevaría a cabo el lunes 8 de mayo, la fecha originalmente programada para el lanzamiento de Neutron. Esta actualización también contenía una corrección para un error que potencialmente podría detener el Hub.

Actualización de emergencia del Hub - 8 de mayo El equipo de Neutron sabiamente decidió posponer su lanzamiento durante unos días, hasta el miércoles 10, para evitar complicaciones con la actualización.

La actualización del lunes se llevó a cabo relativamente sin problemas, con un tiempo de inactividad mínimo y sin incidentes importantes. Inmediatamente después de la actualización, los validadores pudieron utilizar la transacción de asignación de claves desde sus multisig y dispositivos Ledger. ¡Gracias al equipo de Notional por consultar con Neutron sobre la postergación del lanzamiento y ayudar a coordinar la actualización!

Sin embargo, la "hora de inicio" de Neutron fue el lunes, a pesar de que su lanzamiento real se retrasó. En el momento de inicio, se crea el cliente IBC y el archivo genesis para la cadena de consumidores en el Hub, y a partir de este punto, no se pueden cambiar. Todos los validadores que no pudieron utilizar la transacción de asignación de claves antes de la corrección estaban en el archivo genesis con sus claves del Hub.

Esto significa que, para ejecutar Neutron, necesitarían poner sus claves del Cosmos Hub en su validador de Neutron. Esto no es un problema para el software, pero en términos de seguridad operativa, la mayoría de los validadores preferiría no estar moviendo claves entre diferentes computadoras.

Lanzamiento de Neutron - Del 10 de mayo al 11 de mayo Realizamos la actualización de emergencia del Hub tan rápido porque no queríamos que los validadores que no habían podido asignar claves fueran castigados injustamente por el tiempo de inactividad. Sin embargo, pronto nos dimos cuenta de que podríamos tener un problema más grande. Un gran número de validadores no había podido asignar claves antes de la hora de inicio y, después de la hora de inicio, el archivo génesis quedó bloqueado. Las asignaciones de claves aún se podían realizar, pero solo tendrían efecto después de que Neutron hubiera comenzado.

Se necesita al menos el 67% de los validadores del Hub para ejecutar una cadena de consumidores de seguridad replicada para que pueda comenzar. Este 67% debería provenir de los validadores que no estaban usando multisigs o Ledgers, o de validadores que estaban dispuestos a ejecutar temporalmente la cadena de consumidores con sus claves del Hub. Con una gran difusión durante el día 10, pudimos reunir suficiente poder para poner en marcha la cadena, aunque tomó muchas horas. Gracias a todos los validadores que nos ayudaron aquí.

Decidimos esperar hasta el día siguiente antes de iniciar el relayer. Una vez que el relayer comenzara, comenzaría a ponerse al día con todos los paquetes de seguridad replicados que actualizan el conjunto de validadores de la cadena de consumidores. Estos paquetes actualizarían las claves de los validadores que habían utilizado la transacción de asignación de claves del consumidor después de la hora de inicio del lunes. Esto es algo bueno, pero nuestra preocupación era que podría ser posible que los validadores que nos ayudaron usando su clave del Hub en lugar de su clave del consumidor pudieran quedar fuera de línea una vez que se actualizaran las claves. Dado que estábamos funcionando con una mayoría mínima, esto podría causar una parada. Queríamos tener a tantas personas como fuera posible en línea y descansadas para ayudar a lidiar con esto.

El 11 de mayo, tuvimos algunas dificultades para que los relayers comenzaran, pero son demasiado aburridas para entrar en detalles aquí. Pero una vez que los relayers estuvieron en funcionamiento, los paquetes comenzaron a circular muy rápidamente y la cadena se sincronizó. Neutron es ahora oficialmente la primera cadena de consumidores de Seguridad Replicada, asegurada por el Cosmos Hub.

Una nota sobre el desbloqueo Algunos usuarios desbloquearon sus ATOMs apostados durante la ventana de lanzamiento de Neutron (del 8 al 11 de mayo). Estos tokens se desbloquearán por completo antes del 1 de junio.

Neutron se convirtió oficialmente en una cadena de consumidores el 8 de mayo. Esto se conoce como su hora de inicio. Sin embargo, no comenzó a funcionar hasta el 11 de mayo. Cuando comenzó, recibió todos los paquetes de VSC para los desbloqueos que ocurrieron después de la hora de inicio y comenzó la cuenta regresiva del período de desbloqueo de 20 días. 20 días después del 11 de mayo es el 31 de mayo, por lo que el 1 de junio es cuando se completará el período de desbloqueo de todos los paquetes de VSC recibidos el 11 de mayo.

¿Cómo funciona el desbloqueo con Seguridad Replicada? Una parte fundamental del protocolo de Seguridad Replicada es la preservación del período de desbloqueo de la cadena de consumidores en todas las circunstancias. Esto se hace de una manera simple:

Cuando un usuario envía una transacción de desbloqueo, se crea un registro de la operación de desbloqueo pendiente. Esta operación de desbloqueo puede completarse cuando se cumplen dos condiciones: a. Han pasado 21 días en el Cosmos Hub. b. Cada cadena de consumidores informa que también han pasado sus períodos de desbloqueo. Al final del bloque en el que se inició el desbloqueo, se envía un paquete de cambio de conjunto de validadores (paquete VSC) a todas las cadenas de consumidores. Esto contiene el cambio de poder causado por el desbloqueo y cualquier otro cambio de poder de ese bloque. Una vez que la cadena de consumidores recibe el paquete de cambio de conjunto de validadores, comienza su propio período de desbloqueo. En Neutron, el período de desbloqueo es de 20 días. Después de que haya transcurrido este período, la cadena de consumidores envía un paquete VSC maduro al Cosmos Hub. Ahora, cualquier operación de desbloqueo correspondiente puede completarse, una vez que también haya pasado el período de desbloqueo del Hub. Este protocolo garantiza que, independientemente de lo que suceda, se respete el período de desbloqueo de la cadena de consumidores.

¿Cómo se puede evitar esto en el futuro? Si bien este mecanismo garantiza la seguridad de las cadenas de consumidores en el más alto grado, los retrasos en el desbloqueo pueden ser inconvenientes y probablemente deberían evitarse. Debe tenerse en cuenta que una cadena de consumidores no puede retrasar el desbloqueo indefinidamente. Si una cadena de consumidores ha retrasado el desbloqueo durante más de 5 semanas, será eliminada del Cosmos Hub y se liberarán todos los desbloqueos.

Para evitar el tipo de retraso menor discutido aquí, la forma más sencilla es reducir el período de desbloqueo en las cadenas de consumidores. A modo de ejemplo, si los períodos de desbloqueo de las cadenas de consumidores fueran una semana más cortos que el período de desbloqueo del Cosmos Hub, entonces una cadena de consumidores tendría que detenerse durante una semana antes de que se retrasaran los desbloqueos en el Hub. Teóricamente, esto reduce la seguridad en cierta medida, pero es muy probable que no sea significativo.

También estamos estudiando el protocolo para ver si es posible eliminar por completo el mecanismo de pausa del desbloqueo. Esto probablemente requerirá hacer suposiciones de que los relojes están siempre sincronizados y dificultará la cuantificación exacta de la seguridad de las cadenas de consumidores, pero podría valer la pena.

Otras actualizaciones de ingeniería Gran parte del trabajo en abril y mayo se centró en la preparación y el lanzamiento de la primera cadena de consumidores, Neutron.

Opt-out suave Neutron eligió lanzarse con la función de opt-out suave discutida en la última actualización, que permite a los 5% más pequeños de los validadores en el Hub optar por no ejecutar la cadena de consumidores. Lo implementamos a tiempo para el lanzamiento de Neutron: #833

Código de migración de independiente a consumidor completado La migración de independiente a consumidor permitirá que las cadenas que actualmente se ejecutan de forma independiente se conviertan en cadenas de consumidores. Stride lo utilizará durante su lanzamiento. Hemos estado trabajando en esto con Stride en los últimos meses, pero en abril lo fusionamos: #757, #794, #832

Revisión de la auditoría de Oak Oak Security recibió recientemente fondos para hacer una auditoría de Seguridad Intercadena por parte de la comunidad del Cosmos Hub. Recibimos su informe inicial, lo revisamos y discutimos con el equipo de auditoría. Encontraron algunos problemas en los que una cadena de consumidores maliciosa podría detener potencialmente el Cosmos Hub, pero esto está dentro del modelo de seguridad actual de Seguridad Replicada. Estamos solucionando estos problemas y otros para avanzar hacia un paradigma de "cadena de consumidores no confiables", pero este trabajo está en curso.

Uno de los problemas que identificó Oak Security es donde un atacante podría detener una cadena de consumidores creando millones de spam denoms (tipos de tokens). Este problema era muy similar a uno que ya estábamos investigando en el lado de la cadena proveedora de ICS. Ahora podemos confirmar que estos problemas se han abordado y solucionado tanto en el Cosmos Hub como en Neutron.

Neutron testnet y correcciones En la red de prueba Neutron, encontramos un error donde varios mensajes de asignación de claves podían provocar una detención en el consumidor (esto también se encontró en la auditoría de Oak unas semanas después). Solucionamos este problema tanto en el consumidor como en el proveedor: #850, #846

Problema de multisig A finales de mes, comenzamos a recibir informes de que la asignación de claves no funcionaba para los validadores que utilizaban multisigs y dispositivos Ledger. Comenzamos a trabajar en una solución para este problema modificando ligeramente el formato de la transacción de asignación de claves.

Preparando la actualización de emergencia Comenzamos a prepararnos para una actualización de emergencia del Hub que contenía las correcciones de denom y multisig mencionadas anteriormente. Sin embargo, la mayor parte del trabajo en esta actualización se llevó a cabo en mayo. Hemos publicado información al respecto en otros lugares, pero no la cubriré aquí, ya que estará en la actualización de mayo.