简而言之：现有的升级 Solana 程序的范式是一场灾难。 编写智能合约代码最危险的事情是，程序数据模型在部署后实际上是锁定的。 在传统的软件工程中，客户端 API 与后端是解耦的。您可以在不被察觉的情况下更改后端架构或向数据库添加迁移。 在 Solana 编程中，您可以通过以下方式尝试使合约具备未来适应性： - 添加结构填充，并希望账户数据中有足够的空位以便未来更改 - 要求用户手动签名以迁移应用状态（糟糕的用户体验） - 实施应用级的管理员操作以迁移架构 请注意，上述所有方法都有可能破坏虚拟机级的可组合性。它们还需要复杂且容易出错的逻辑来安全执行。这不仅引入了逻辑数据风险，还带来了密钥管理风险。 一个观点是，部署后绝不要更改代码。毕竟，现有框架使得安全地修改现有数据格式极其困难。 然而，即使不可变性是可取的，认为未来没有灾难性错误需要修复或关键功能需要添加（其中一些可能需要更改线路）是天真和鲁莽的。在这个堆栈上构建的企业被迫在安全性、速度和质量之间做出选择。 今天，能够维护和持续开发足够复杂的智能合约的工具是不存在的。 如果我从第一原则构建这个环境，以下是我会考虑包括的一些功能： - 在虚拟机中应该有单独的 API 来读取和写入账户数据。这使得架构更改不会破坏链上和链下消费者的线路格式。 - 系统级别上应该存在一些（可选）管理智能合约功能，而不是应用级别。 - 在可执行升级时，应该同时有一个可选的原子迁移，迁移由该程序拥有的账户。 即使目标是不可变性，构建系统级工具以实现安全的软件升级对于具有不断演变状态的消费者应用至关重要。当前系统如此脆弱，以至于对这些开发者的最佳建议是，除非他们真的知道自己在做什么，否则绝不要触碰链上架构。

好的技术，真疯狂，我们花了5年才到这里 @solana 😭

去中心化交易所（DEX）的定义确实随着时间的推移而演变。 2021年：匹配在全球分布的网络上执行和验证。 2025年：在Solana、Arbitrum或BSC上存入代币，交易所将其记录在SQL表中。匹配发生在ap-northeast-1。