Resumen; DR: El paradigma existente para mejorar los programas de Solana es un desastre. Lo más peligroso de escribir código de contratos inteligentes es que los modelos de datos del programa quedan efectivamente bloqueados tras el despliegue. En el software tradicional, la API cliente se desacopla del backend. Puedes cambiar invisiblemente un esquema backend o añadir migraciones a una base de datos. En programación Solana, puedes intentar proteger un contrato para el futuro mediante: - Añadir relleno de estructuras y esperar que haya suficientes bits vacíos en los datos de la cuenta para futuros cambios - Exigir a los usuarios que firmen manualmente para migrar el estado de la aplicación (experiencia de usuario horrible) - Implementar acciones administrativas a nivel de aplicación para migrar esquemas Ten en cuenta que todo lo anterior tiene el potencial de romper la componibilidad a nivel de VM. También requieren una lógica compleja y propensa a errores para ejecutarse con seguridad. No solo introduce un riesgo lógico de datos, sino también un riesgo de gestión clave. Un argumento es no cambiar nunca el código después del despliegue. Al fin y al cabo, el marco existente hace extremadamente difícil modificar los formatos de datos existentes de forma segura. Sin embargo, aunque la inmutabilidad sea deseable, es ingenuo e imprudente pensar que no hay errores catastróficos que corregir ni características críticas que añadir en el futuro (algunas de las cuales pueden requerir cambios en los cables). Las empresas que construyen sobre esta pila se ven obligadas a elegir entre seguridad, velocidad y calidad. Hoy en día, las herramientas que permitan el mantenimiento y desarrollo continuo de un contrato inteligente suficientemente complejo son inexistentes. Aquí tienes algunas de las características que se me ocurriría, incluyendo si estuviera construyendo este entorno a partir de principios básicos: - Debe haber APIs separadas en la VM para leer y escribir datos de cuenta. Esto permite cambios en el esquema sin romper el formato de cable tanto para consumidores on-chain como off-chain. - Algunas funciones administrativas de contratos inteligentes (opt-in) deberían existir a nivel de sistema, no a nivel de aplicación. - En la actualización ejecutable, debe haber simultáneamente una migración atómica opcional de las cuentas propiedad de ese programa. Aunque el objetivo sea la inmutabilidad, incorporar herramientas a nivel de sistema para permitir actualizaciones seguras de software es fundamental para aplicaciones de consumo con estado en evolución. El sistema actual es tan frágil que el mejor consejo para estos desarrolladores es no tocar los esquemas en cadena a menos que realmente sepan lo que hacen.