Actualización de Ingeniería del Cosmos Hub — Febrero de 2023

https://medium.com/the-interchain-foundation/cosmos-hub-engineering-update-feb-2023-3487bf13933e

¡Es hora de la actualización de febrero del equipo Informal del Cosmos Hub! El mes pasado estuvimos ocupados con las actualizaciones v8 y v9, así como con la planificación a largo plazo del producto y la resolución de algunos problemas menores.

Actualización v8 en vivo La actualización v8 se aprobó y se puso en marcha en febrero. Fue una actualización fluida, sin tiempo de inactividad. Sin embargo, hubo varios validadores que no pudieron actualizar a tiempo y estuvieron fuera de servicio durante un corto período después. No fue suficiente para provocar un tiempo de inactividad en la cadena en sí, pero destacó algunas deficiencias en nuestro proceso que ahora hemos corregido.

Problemas de Cosmovisor Cosmovisor es un software que los validadores utilizan para cambiar automáticamente la cadena a un nuevo binario en el momento adecuado para realizar una actualización exitosa. Muchos validadores utilizan Cosmovisor, pero algunos aún cambian los binarios manualmente. A partir de la versión 1.2.0, Cosmovisor cambió la forma en que maneja la capitalización de las carpetas donde busca la nueva versión de la cadena. Esto causó problemas para algunos validadores.

Deriva del tiempo Debido a que los tiempos de bloque del Cosmos Hub se aceleraron ligeramente durante el período de votación, la hora de inicio de la v8 se adelantó en 13 horas. Esto es algo normal que puede suceder en cualquier cadena de Cosmos. Algunos validadores no estaban al tanto de esto y no actualizaron a tiempo. Todos los validadores deben verificar las alturas de los bloques para estar al tanto de los cambios en los horarios de actualización, pero para facilitar las cosas, nos pondremos en contacto proactivamente con los validadores en el futuro para informarles de las estimaciones de tiempo más recientes para las actualizaciones.

Aprobación de la actualización v9 Junto con nuestros socios en Hypha, quienes se encargan de las redes de prueba y las versiones de actualización, presentamos la versión v9 con Replicated Security para su votación, ¡y fue aprobada! Esto se ha discutido extensamente en otros lugares, así que solo proporcionaré un enlace a la propuesta . El nuevo código estará en vivo alrededor del 15 de marzo, puedes consultar la cuenta regresiva para la actualización aquí.

Actualización v10 en desarrollo Actualmente estamos preparando la versión v10. Proporcionaremos más detalles sobre lo que contendrá la v10 a medida que nos acerquemos a su lanzamiento.

Verificación de la equivocación Hemos estado trabajando en el código necesario para permitir que la evidencia de equivocación (doble firma, etc.) de las cadenas consumidoras sea verificada criptográficamente en el Cosmos Hub. La incorporación de este código nos permitirá eliminar la regulación de las sanciones de las cadenas consumidoras que se discutió aquí .

Trabajando junto con los equipos de Hermes, Comet e IBC-Go, descubrimos que gran parte del código necesario para generar pruebas de equivocación ya existe en Hermes, y gran parte del código necesario para verificarlos existe en IBC-Go. Con suerte, esto acelerará la implementación. Actualizaremos cuando tengamos un plan de implementación concreto.

Problema de spam Desafortunadamente, ha habido algo de spam creado en las propuestas de gobernanza del Cosmos Hub. Esto ha ocurrido de dos maneras: spam en el período de depósito y spam en el período de votación. Son diferentes, y los abordaré por separado.

Spam en el período de depósito Antes de que una propuesta se someta a votación, primero debe recibir un depósito de 250 Atoms. Este depósito se quemará si la propuesta es vetada por la gobernanza. El depósito tiene como objetivo evitar que las propuestas de spam ingresen al período de votación, ya que el spam será vetado, lo que costará al remitente del spam una gran cantidad de dinero. En el diseño actual de la gobernanza de Cosmos-SDK, se pretende que las propuestas de spam permanezcan en el período de depósito y nunca lleguen al período de votación.

Sin embargo, en muchas carteras y exploradores de bloques, es posible ver propuestas que todavía están en el período de depósito. Aunque parte del diseño previsto originalmente en la gobernanza era que podría haber spam en el período de depósito, no se ve bien y podemos hacer un poco más para solucionarlo. Al hacer que las propuestas deban recibir un depósito mínimo por parte del creador de la propuesta para incluso ingresar al período de depósito, podemos hacer que sea más costoso presentar propuestas de spam, incluso en el período de depósito. Esta corrección se implementó en Juno y otras cadenas.

Este es un cambio que debe hacerse como parte de una actualización coordinada. Ya tenemos la actualización v9 que se implementará pronto, por lo que, en consulta con Notional y otros equipos principales, hemos decidido no convocar una actualización de emergencia solo para solucionar el problema de spam en el período de depósito.

Sin embargo, nuestro equipo ha encontrado una manera de solucionar el problema sin una actualización coordinada . Pronto lanzaremos un parche que los validadores pueden instalar de forma individual sin una actualización coordinada y que detendrá el spam en el período de depósito una vez que todos los validadores lo hayan instalado.

Spam en el período de votación Recientemente, una propuesta de spam ha ingresado al período de votación. Este es un asunto completamente diferente a lo discutido anteriormente. El remitente de spam decidió que valía la pena pagar 250 Atoms ($ 3000) para que esta propuesta llegara al período de votación. Le recomendamos que vote "No con veto" en esta propuesta, para que el remitente de spam pierda sus fondos.