Я читал документацию W3sper для Dusk @Dusk Dusk и однажды принял DuskVM Query за обычный JSON-интерфейс. При компиляции контракта Forge параллельно создаёт data-driver WASM; приложение регистрируется в W3sper, указав contract ID. Driver кодирует ввод в байты ABI, а затем декодирует возвращаемое значение, полученное от ноды.

Я воспринимал это как переводческую стойку для аэропорта. Пассажиры говорят JSON, а взлётное поле принимает только строго заданный формат загрузки; стойка пакует всё по схеме, а обратно уже распаковывает выходные данные и события. При отправке HTTP raw bytes это напрямую передаётся контракту; при отправке JSON — преобразование в автоматическом режиме доступно только когда используется driver. С помощью get_version можно узнать версию.

Проблема — не показывать себя после обновления. Старый driver может вернуть успех, но при этом интерпретировать данные по устаревшему ABI. Параметры driver_available и driver_signature в метаданных лишь помогают подтвердить личность драйвера. Я зафиксирую файловый хэш: на testnet с одним и тем же вводом буду сверять исходные bytes и результат декодирования. Тот факт, что страница доступна только для чтения, доказывает лишь, что переводческая цепочка работает, но состояние активов всё равно нужно независимо проверять.

#dusk $DUSK