簡而言之：現有的 Solana 程式升級範式是一場災難。 撰寫智能合約代碼最危險的事情是，程式數據模型在部署後實際上是鎖定的。 在傳統的軟體工程中，客戶端 API 與後端是解耦的。您可以在不顯示的情況下更改後端架構或向數據庫添加遷移。 在 Solana 編程中，您可以通過以下方式嘗試未來保護合約： - 添加結構填充，並希望帳戶數據中有足夠的空位以便未來更改 - 要求用戶手動簽名以遷移應用狀態（糟糕的用戶體驗） - 實施應用級管理操作以遷移架構 請注意，上述所有方法都有可能破壞虛擬機級的可組合性。它們還需要複雜且容易出錯的邏輯來安全執行。這不僅引入了邏輯數據風險，還有密鑰管理風險。 一種觀點是，部署後永遠不要更改代碼。畢竟，現有的框架使得安全地修改現有數據格式變得極其困難。 然而，即使不變性是可取的，認為未來沒有災難性錯誤需要修復或關鍵功能需要添加（其中一些可能需要線路更改）是天真和魯莽的。在這個堆棧上構建的企業被迫在安全性、速度和質量之間做出選擇。 今天，能夠維護和持續開發足夠複雜的智能合約的工具是不存在的。 如果我從第一原則開始構建這個環境，這裡有一些我會考慮包括的功能： - 在虛擬機中應該有單獨的 API 來讀取和寫入帳戶數據。這使得架構變更不會破壞鏈上和鏈下消費者的線路格式。 - 應該在系統級別而不是應用級別存在一些（選擇性）管理智能合約功能。 - 在可執行升級時，應同時進行由該程序擁有的帳戶的可選原子遷移。 即使目標是不可變性，構建系統級工具以實現安全的軟體升級對於具有不斷演變狀態的消費者應用至關重要。當前系統如此脆弱，以至於對這些開發者的最佳建議是，除非他們真的知道自己在做什麼，否則永遠不要觸碰鏈上架構。

好的技術，瘋狂的是我們花了 5 年才到達這裡 @solana 😭

去中心化交易所（DEX）的定義確實隨著時間的推移而演變。 2021年：匹配在全球分佈的網絡上執行和驗證。 2025年：在Solana、Arbitrum或BSC上存入代幣，交易所將在SQL表中記錄它。匹配發生在ap-northeast-1。