要約:DR:Solanaプログラムのアップグレードに関する現行のパラダイムは大失敗です。 スマートコントラクトコードを書く際の最も危険な点は、プログラムのデータモデルが展開後も事実上固定されていることです。 従来のSWEでは、クライアントAPIはバックエンドから切り離されています。バックエンドスキーマを目に見えずに変更したり、データベースにマイグレーションを追加したりできます。 ソラナプログラミングでは、契約の将来性を以下のように試みることができます: - 構造体パディングを追加し、将来の変更のためにアカウントデータに十分な空ビットがあることを期待すること - ユーザーがアプリケーション状態を移行するために手動署名を義務付けること(ひどいユーザー体験) - スキーマの移行のためのアプリケーションレベルの管理者アクションの実装 上記はすべてVMレベルのコンポジビリティを壊す可能性があることに注意してください。また、安全に実行するには複雑で誤りやすいロジックが必要です。論理データリスクだけでなく、鍵管理リスクもも生じさせます。 一つの理由は、デプロイ後にコードを絶対に変更しないことです。結局のところ、既存のフレームワークでは既存のデータフォーマットを安全に変更することが非常に困難です。 しかし、不変性が望ましいとしても、修正すべき壊滅的なバグや将来に追加すべき重要な機能(その一部は配線の変更が必要かもしれません)がないと考えるのは甘く無謀です。このスタック上で構築する企業は、セキュリティ、速度、品質の三者択一を迫られます。 現在では、十分に複雑なスマートコントラクトの保守や継続開発を可能にするツールは存在しません。 もし私がこの環境を基本から構築するなら、私が考える特徴のいくつかを挙げます。 - 仮想マシン内にアカウントデータの読み書き用の別APIがあるべきです。これにより、オンチェーンおよびオフチェーンの消費者の両方で、ワイヤーフォーマットを壊すことなくスキーマ変更が可能になります。 - 一部の(オプトインによる)管理スマートコントラクト機能は、アプリケーションレベルではなくシステムレベルに存在すべきです。 - 実行可能ファイルのアップグレード時に、同時にそのプログラムが所有するアカウントの任意の原子移行が行われるべきです。 たとえ目標が不変性であっても、進化する状態を持つ消費者向けアプリケーションにおいて、安全なソフトウェアアップグレードを可能にするシステムレベルのツールを組み込むことは極めて重要です。現行のシステムは非常に脆弱なので、開発者たちへの最良のアドバイスは、本当に知識がない限りオンチェーンスキーマに手を出さないことです。

良い技術ですが、ここまで来るのに5年もかかったとは信じられません@solana 😭

DEX の定義は、長年にわたって真に進化してきました。 2021年:マッチングは、グローバルに分散されたネットワーク上で実行および検証されます。 2025: Solana、Arbitrum、または BSC にトークンを入金すると、取引所はそれを SQL テーブルに記録します。マッチングは ap-northeast-1 で行われます。