Resumen: El paradigma existente para actualizar 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 están efectivamente bloqueados después de la implementación. En el desarrollo de software tradicional, la API del cliente está desacoplada del backend. Puedes cambiar invisiblemente un esquema de backend o agregar migraciones a una base de datos. En la programación de Solana, puedes intentar preparar un contrato para el futuro: - Agregando relleno de estructura y esperando que haya suficientes bits vacíos en los datos de la cuenta para futuros cambios - Requiriendo que los usuarios firmen manualmente para migrar el estado de la aplicación (horrible experiencia de usuario) - Implementando acciones administrativas a nivel de aplicación para migrar esquemas Ten en cuenta que todo lo anterior tiene el potencial de romper la composabilidad a nivel de VM. También requieren lógica compleja y propensa a errores para ejecutarse de manera segura. No solo introduce riesgo lógico de datos, sino también riesgo de gestión de claves. Un argumento es nunca cambiar el código después de la implementación. Después de todo, el marco existente hace que sea extremadamente difícil modificar de manera segura los formatos de datos existentes. Sin embargo, incluso si la inmutabilidad es deseable, es ingenuo y temerario pensar que no hay errores catastróficos que arreglar o características críticas que agregar en el futuro (algunas de las cuales pueden requerir cambios en el cableado). Las empresas que construyen sobre este stack se ven obligadas a elegir entre seguridad, velocidad y calidad. Hoy en día, las herramientas para permitir el mantenimiento y el desarrollo continuo de un contrato inteligente suficientemente complejo no existen. Aquí hay algunas de las características que consideraría incluir si estuviera construyendo este entorno desde los primeros principios: - Debería haber API's separadas en la VM para leer y escribir datos de cuentas. Esto permite cambios de esquema sin romper el formato de cableado tanto para consumidores en cadena como fuera de cadena. - Algunas funciones de contratos inteligentes administrativas (optativas) deberían existir a nivel del sistema, no a nivel de aplicación. - En la actualización ejecutable, debería haber simultáneamente una migración atómica opcional de cuentas propiedad de ese programa. Incluso si el objetivo es la inmutabilidad, construir herramientas a nivel de sistema para permitir actualizaciones de software seguras es crítico para aplicaciones de consumo con estado en evolución. El sistema actual es tan frágil que el mejor consejo para estos desarrolladores es nunca tocar los esquemas en cadena a menos que realmente sepan lo que están haciendo.

Buena tecnología, es una locura que nos haya llevado 5 años llegar aquí @solana 😭

La definición de DEX ha evolucionado verdaderamente a lo largo de los años. 2021: La coincidencia se ejecuta y valida en una red distribuida globalmente. 2025: Deposita tokens en Solana, Arbitrum o BSC, y el intercambio lo registrará en una tabla SQL. La coincidencia ocurre en ap-northeast-1.