TL;DR : Le paradigme existant pour la mise à niveau des programmes Solana est un désastre. La chose la plus dangereuse à propos de l'écriture de code de contrat intelligent est que les modèles de données du programme sont effectivement verrouillés après le déploiement. Dans le développement logiciel traditionnel, l'API client est découplée du backend. Vous pouvez changer invisiblement un schéma backend ou ajouter des migrations à une base de données. Dans la programmation Solana, vous pouvez tenter de rendre un contrat à l'épreuve du futur en : - Ajoutant du remplissage de structure et en espérant qu'il y a suffisamment de bits vides dans les données du compte pour des changements futurs - Exigeant que les utilisateurs signent manuellement pour migrer l'état de l'application (expérience utilisateur horrible) - Implémentant des actions administratives au niveau de l'application pour migrer les schémas Notez que tout ce qui précède a le potentiel de briser la composabilité au niveau de la VM. Cela nécessite également une logique complexe et sujette aux erreurs pour s'exécuter en toute sécurité. Cela introduit non seulement un risque de données logiques, mais aussi un risque de gestion des clés. Un argument est de ne jamais changer le code après le déploiement. Après tout, le cadre existant rend extrêmement difficile la modification des formats de données existants en toute sécurité. Cependant, même si l'immuabilité est souhaitable, il est naïf et imprudent de penser qu'il n'y a pas de bogues catastrophiques à corriger ou de fonctionnalités critiques à ajouter à l'avenir (certaines d'entre elles pouvant nécessiter des changements de câblage). Les entreprises construisant sur cette pile sont forcées de choisir entre sécurité, vitesse et qualité. Aujourd'hui, les outils permettant la maintenance et le développement continu d'un contrat intelligent suffisamment complexe n'existent pas. Voici quelques-unes des fonctionnalités que je penserais à inclure si je construisais cet environnement à partir de principes fondamentaux : - Il devrait y avoir des API séparées dans la VM pour lire et écrire des données de compte. Cela permet des changements de schéma sans casser le format de câblage pour les consommateurs à la fois sur chaîne et hors chaîne. - Certaines fonctions de contrat intelligent administratives (sur option) devraient exister au niveau système, et non au niveau application. - Lors de la mise à niveau exécutable, il devrait simultanément y avoir une migration atomique optionnelle des comptes détenus par ce programme. Même si l'objectif est l'immuabilité, intégrer des outils au niveau système pour permettre des mises à jour logicielles sûres est essentiel pour les applications consommateurs avec un état évolutif. Le système actuel est si fragile que le meilleur conseil pour ces développeurs est de ne jamais toucher aux schémas sur chaîne à moins qu'ils ne sachent vraiment ce qu'ils font.

Bonne technologie, c'est fou qu'il nous ait fallu 5 ans pour arriver ici @solana 😭

La définition de DEX a vraiment évolué au fil des ans. 2021 : Le matching est exécuté et validé sur un réseau mondialement distribué. 2025 : Déposez des tokens sur Solana, Arbitrum ou BSC, et l'échange l'enregistrera dans une table SQL. Le matching se fait dans ap-northeast-1.