Кратко: Существующая парадигма обновления программ Solana — это катастрофа. Самое опасное в написании кода смарт-контрактов заключается в том, что модели данных программы фактически заблокированы после развертывания. В традиционной разработке ПО клиентский API отделен от бэкенда. Вы можете незаметно изменить схему бэкенда или добавить миграции в базу данных. В программировании на Solana вы можете попытаться защитить контракт от будущих изменений, сделав следующее: - Добавить выравнивание структур и надеяться, что в данных аккаунта достаточно пустых битов для будущих изменений - Требовать от пользователей вручную подписывать миграцию состояния приложения (ужасный UX) - Реализовать действия администратора на уровне приложения для миграции схем Обратите внимание, что все вышеперечисленное может нарушить совместимость на уровне виртуальной машины. Это также требует сложной и подверженной ошибкам логики для безопасного выполнения. Это не только вводит риск логических данных, но и риск управления ключами. Одним из аргументов является то, что код никогда не следует изменять после развертывания. В конце концов, существующая структура делает крайне сложным безопасное изменение существующих форматов данных. Тем не менее, даже если неизменность желательна, наивно и безрассудно думать, что в будущем не будет катастрофических ошибок, которые нужно исправить, или критических функций, которые нужно добавить (некоторые из которых могут потребовать изменения проводки). Бизнесы, строящие на этом стеке, вынуждены выбирать между безопасностью, скоростью и качеством. Сегодня инструменты, позволяющие поддерживать и непрерывно развивать достаточно сложный смарт-контракт, отсутствуют. Вот некоторые функции, которые я бы подумал о включении, если бы строил эту среду с нуля: - В виртуальной машине должны быть отдельные API для чтения и записи данных аккаунта. Это позволяет изменять схемы, не нарушая проводку как для ончейн, так и для оффчейн потребителей. - Некоторые (по желанию) административные функции смарт-контрактов должны существовать на системном уровне, а не на уровне приложения. - При исполняемом обновлении должна одновременно происходить необязательная атомарная миграция аккаунтов, принадлежащих этой программе. Даже если цель — неизменность, создание системных инструментов для безопасных обновлений программного обеспечения критически важно для потребительских приложений с развивающимся состоянием. Текущая система настолько хрупка, что лучший совет для этих разработчиков — никогда не трогать ончейн схемы, если они действительно не знают, что делают.

Хорошая технология, безумие, что нам понадобилось 5 лет, чтобы добраться сюда @solana 😭

Определение DEX действительно эволюционировало за эти годы. 2021: Сопоставление выполняется и проверяется в глобально распределенной сети. 2025: Депозит токенов на Solana, Arbitrum или BSC, и обмен запишет это в таблицу SQL. Сопоставление происходит в ap-northeast-1.