Fuente de:

• https://validator.info/terra-classic/governance/12162
• https://station.terraclassic.community/proposal/columbus-5/12162
• https://common.xyz/terra-luna-classic-lunc/discussion/26630

Actualización del SDK v0.50.X por Antier Solutions

Después de orbit labs unfork proponemos una actualización en cadena al SDK más reciente

https://common.xyz/terra-luna-classic-lunc/discussion/26630

Por cookie FrgValidator y Luncvers3

Actualización SDK 0.50.x Final

Documento Propuesta actualizada:

Terra Classic SDK & Wasm Upgrade Resumen ejecutivo Esta propuesta esboza una actualización segura y compatible con versiones anteriores de la infraestructura central de Terra Classic a Cosmos SDK v0.50.9 y Wasm Module v0.53.2, abordando los problemas no resueltos de la actualización a v0.47, mejorando la seguridad y garantizando la sostenibilidad a largo plazo. La actualización depende de que Orbit Labs termine el unforking e incluye correcciones de la deuda técnica, mitigación de cambios de ruptura y mejoras centradas en los desarrolladores. La propuesta garantiza la plena compatibilidad con las dApps existentes. Especificaciones técnicas e implicaciones

1. Actualización del SDK de Cosmos Actual: v0.47.14 Propuesta: v0.50.9 Justificación: La versión actual contiene algunas vulnerabilidades de seguridad. La actualización a la v0.50.9 aborda estos problemas de forma exhaustiva. Cambios: Actualizaciones del módulo x/params (requiere la migración a nuevos parámetros basados en la gobernanza). Actualizaciones de x/authz y x/feegrant (afecta a las dApps que utilizan delegación/permisos). Ajustes en los módulos personalizados (por ejemplo, Oracle, Market, Staking) debido a la refactorización del SDK. Consideraciones sobre Terra Classic: Garantiza la plena compatibilidad con las características y funcionalidades existentes de la cadena.
2. Módulo Wasm y Máquina Virtual Actual: v0.46.0 / wasmvm v1.5.8 Propuesta: v0.53.2 / wasmvm v2.1.4 Impacto de la dApp: Los contratos CosmWasm existentes siguen siendo funcionales. Los contratos se ajustarán a las normas más recientes, manteniendo la compatibilidad con las limitaciones existentes. Compatibilidad con los enlaces personalizados de Terra Classic Wasm: Se mantendrán los enlaces personalizados para los módulos de oráculo, impuestos y mercado.
3. IBC-GO IBC-GO: v7.4.0 → v8.4.0 Preserva la compatibilidad entre cadenas sin introducir cambios que rompan el IBC. Mejoras en el rendimiento, optimizando el rendimiento de los repetidores y reduciendo la latencia de las transacciones. A prueba de futuro, garantizando la compatibilidad con las próximas cadenas Cosmos que adopten IBC v8.4.0. Mejoras de seguridad en IBC-GO v8.4.0: Corrige una vulnerabilidad crítica de ataque de reentrada en los ganchos IBC, garantizando una gestión segura del ciclo de vida de los paquetes para evitar la pérdida de fondos o la acuñación involuntaria de tokens. La actualización mitiga estos riesgos, reforzando la seguridad entre cadenas de Terra Classic
4. Módulos personalizados de Terra Classic y plan de actualización Los módulos personalizados de Terra Classic requieren un manejo cuidadoso durante esta actualización: Módulo Oracle: Gestiona la alimentación de los tipos de cambio de las stablecoins. Requiere pruebas de compatibilidad con la nueva estructura del SDK para garantizar que los precios enviados al validador siguen siendo precisos. Módulo Mercado: Facilita los intercambios de stablecoins. Necesita validación de parámetros y optimización del rendimiento con el nuevo modelo de ejecución del SDK. Módulo de Tesorería: Gobierna las políticas económicas, incluidos los tipos impositivos. Debe conservarse sin pérdida de funcionalidad y probarse bajo los nuevos parámetros de gobernanza. También se actualizarán todas las demás personalizaciones que se hayan hecho en los distintos módulos, como la estaca, el tajo, la ceca, etc. Estrategia de actualización: Pruebas unitarias detalladas y refactorización: Realiza pruebas unitarias en los módulos Oracle, Mercado y Tesorería para verificar que funcionan correctamente con el nuevo SDK. Identificar las áreas que necesitan refactorización para alinearse con el SDK v0.50.9. Implementación de la capa de compatibilidad con versiones anteriores: Desarrollar calzas de compatibilidad temporales para los módulos x/tesorería y x/mercado para evitar interrupciones en la dApp. Asegúrate de que los parámetros de gobierno existentes permanezcan inalterados durante la actualización. ¿Por qué esta actualización?
5. Sinergia del Unforking de Terra Classic-Specific Research: El unforforking de Orbit Labs elimina los parches originales de Terra, lo que permite una integración perfecta del SDK v0.50.
6. Capa de compatibilidad con versiones anteriores de mitigación de riesgos: Calzas temporales para módulos obsoletos para evitar la interrupción de la dApp. Medidas de seguridad: Auditoría de Oak Security (centrada en la migración v0.47 → v0.50). Flujo de trabajo y calendario Fase 1: Preparación previa a la actualización (2 semanas) Tareas: Auditoría del código (post-unforking), corrección de problemas heredados, documentación de compatibilidad con versiones anteriores, configuración de la red de pruebas. Fase 2: Ejecución de la actualización del núcleo (5 semanas) Tareas: Integración del SDK v0.50.9. Actualización del módulo Wasm v0.53.2. Migración de módulos personalizados para las características únicas de Terra Classic. Garantizar que los contratos CosmWasm 1.0-1.5 sigan siendo funcionales. Fase 3: Actualizaciones progresivas, pruebas y validación (9 semanas) Tareas: Configurar la cadena en la versión compatible con los contratos 0.16, instanciar esos contratos y luego actualizar la cadena progresivamente hasta la v0.50.9, seguida de pruebas simuladas.Actualizaciones progresivas de la cadena hasta la v0.50.9, seguidas de pruebas simuladas Auditorías de seguridad, pruebas de validación, pruebas de migración de dApp, recompensas por errores. Fase 4: Despliegue de la Testnet (2 semanas) Tareas: Lanzamiento público de la red de pruebas, incorporación del validador y la dApp, supervisión. Fase 5: Despliegue de la Mainnet (2 semanas) Tareas: Votación de gobernanza, coordinación de CEX, actualización de la mainnet, supervisión posterior al lanzamiento. Calendario total: 20 semanas (~5 meses) Fase Duración Actividades clave Coste

Fases

• Pre-Actualización : 2 Semanas Auditar código post-unforking, corregir errores SDK v0.47, documentar cambios de ruptura, configuración testnet. $6,000
• Actualización del núcleo : 5 Semanas Integrar SDK v0.50.9, Wasm v0.53.2, CometBFT v0.38.11, capas de compatibilidad con versiones anteriores. $25,000
• Pruebas y validación: 9 semanas Auditorías de seguridad, pruebas de validación, pruebas de migración de dApp, recompensas por errores. $12,000
• Despliegue de la Testnet : 2 Semanas Lanzamiento de la testnet pública, incorporación del validador/dApp, supervisión. $8,000
• Despliegue de la red principal: 2 semanas Voto de gobernanza, coordinación CEX, actualización de la red principal, supervisión posterior al lanzamiento. $6,000

Tras este debate de 48 horas, la propuesta se someterá a votación.

Esta propuesta la hacen el equipo #Cookie #FRGValidator y #LUNCVERS3 para luna classic

Actualización realizada por Antier Solutions

Consideración importante: La actualización del wasmd sólo puede comenzar después de que se haya realizado el “wasmd unfork” de Orbit labs, o alternativamente en coordinación con Orbit labs como parte de un esfuerzo conjunto para combinar el wasmd unfork con el sdk y la actualización del wasmd.

Se presentará una nueva propuesta de Gasto después de cada Hito