В сумерках только что запустили кошелёк и SDK, но почему они сделали это не так, как делает рынок — вот что действительно стоит прочитать
Большая часть того, что я писал о Dusk в рамках этой кампании, сводилась к протоколу: нативная эмиссия, модель приватности, институциональные партнёры. Но была одна вещь, которую я постоянно обходил стороной — то, что в итоге определяет, будет ли протокол реально использоваться разработчиками: developer experience (опыт разработчика).
В апреле 2026 Dusk выпустил бета-версию Dusk Wallet и Dusk Connect SDK. Расширения для Chrome и Firefox, один кодбаза, поддержка и публичных, и защищённых аккаунтов в одном интерфейсе.
API провайдера смоделирован по EIP-1193 — точному интерфейсу, который использует MetaMask, знакомому большинству Web3-разработчиков. Поскольку Dusk не является EVM, методы используют префикс dusk_*, а протокол обнаружения работает на событиях: несколько совместимых кошельков могут спокойно сосуществовать на одной странице без конфликтов.
Более выделяющаяся часть — архитектура драйверов: разработчики развёртывают смарт-контракт вместе с «драйвером», который пользователи устанавливают в кошелёк, чтобы взаимодействовать ровно так, как задумал разработчик. Это решает реальную проблему: ZK-доказательства изначально требовали prover keys (ключи провайдера), размер которых превышал 200 MB. Команда сжала их до нескольких КБ, используя технологию circuit descriptor.
Это также объясняет, почему Dusk не пошёл по тренду встраиваемых кошельков, доминирующему в 2026 году, где пользователи заходят по email или через Google, а кошелёк «тихо» создаётся за кулисами через SDK. Эта модель переносит генерацию ZK-доказательств на сервер третьей стороны. В Dusk доказательства должны выполняться на стороне клиента — вы не можете делегировать это и при этом сохранить модель приватности.
Вопрос, с которым я остаюсь: скорость, с которой реальные разработчики реально развёртывают dApps, будет более честным показателем, чем любые бенчмарки протоколов.
@Dusk $DUSK #dusk $BTC $BNB
#dusk @Dusk
Большая часть того, что я писал о Dusk в рамках этой кампании, сводилась к протоколу: нативная эмиссия, модель приватности, институциональные партнёры. Но была одна вещь, которую я постоянно обходил стороной — то, что в итоге определяет, будет ли протокол реально использоваться разработчиками: developer experience (опыт разработчика).
В апреле 2026 Dusk выпустил бета-версию Dusk Wallet и Dusk Connect SDK. Расширения для Chrome и Firefox, один кодбаза, поддержка и публичных, и защищённых аккаунтов в одном интерфейсе.
API провайдера смоделирован по EIP-1193 — точному интерфейсу, который использует MetaMask, знакомому большинству Web3-разработчиков. Поскольку Dusk не является EVM, методы используют префикс dusk_*, а протокол обнаружения работает на событиях: несколько совместимых кошельков могут спокойно сосуществовать на одной странице без конфликтов.
Более выделяющаяся часть — архитектура драйверов: разработчики развёртывают смарт-контракт вместе с «драйвером», который пользователи устанавливают в кошелёк, чтобы взаимодействовать ровно так, как задумал разработчик. Это решает реальную проблему: ZK-доказательства изначально требовали prover keys (ключи провайдера), размер которых превышал 200 MB. Команда сжала их до нескольких КБ, используя технологию circuit descriptor.
Это также объясняет, почему Dusk не пошёл по тренду встраиваемых кошельков, доминирующему в 2026 году, где пользователи заходят по email или через Google, а кошелёк «тихо» создаётся за кулисами через SDK. Эта модель переносит генерацию ZK-доказательств на сервер третьей стороны. В Dusk доказательства должны выполняться на стороне клиента — вы не можете делегировать это и при этом сохранить модель приватности.
Вопрос, с которым я остаюсь: скорость, с которой реальные разработчики реально развёртывают dApps, будет более честным показателем, чем любые бенчмарки протоколов.
@Dusk $DUSK #dusk $BTC $BNB
#dusk @Dusk
