Сегодня я прочитал документацию для разработчиков Kite от начала до конца, и больше всего мне запомнилось не быстродействие и не комиссии. А то, как полномочия разделены на три уровня. Пользователь обладает корневыми полномочиями, каждый агент получает собственный адрес, производный от кошелька пользователя по BIP-32, а для каждой сессии используется случайный ключ, срок действия которого истекает после использования. Если скомпрометируют сессию, вы потеряете одно делегирование. Если скомпрометируют агента, ущерб останется в пределах, заданных пользователем. Неограниченные потери связаны только с корневым ключом, поэтому документация рекомендует хранить его в локальном защищённом анклаве.
Та же логика лежит в основе платёжной системы. Вместо того чтобы проводить каждый запрос в блокчейне, две стороны открывают канал, обмениваются тысячами подписанных обновлений вне блокчейна, а затем закрывают его второй транзакцией.
В документации указана задержка менее 100 мс и стоимость примерно $1 за миллион запросов. Вот где я бы поумерил собственный энтузиазм. В документации также описаны условные правила, например снижение лимита агента при резком росте волатильности. Для такого правила нужны внешние данные, но я не смог выяснить, кто их предоставляет и что происходит, если эти данные неверны. Кроме того, внушительные показатели тестнета (сотни миллионов транзакций) были получены в тестовой среде, поэтому они мало что говорят о регулярном спросе в основной сети, запущенной 30 апреля 2026 года.
Что я буду отслеживать дальше: число активных Agent Passport в KiteScan, долю транзакций агентов, которые являются реальными платежами за услуги, а не тестовым трафиком, и то, укажет ли документация источник данных для условных лимитов расходов.
Экономика агентов работает, только если человек может передать кошелёк и спокойно спать. Это зависит не столько от скорости платежей агентов, сколько от того, как работают правила, когда источники данных дают сбой.
#dusk $DUSK @Dusk Many people who look at Dusk's consensus layer ask one question first - how fast is it? I kept thinking that speed is the wrong place to start. The more interesting question is what the design is actually protecting against.
Succinct Attestation runs every block through three steps - Proposal, Validation, Ratification. A provisioner creates a candidate block. A randomly selected committee checks its validity. A second, separately selected committee confirms the validation outcome and finalizes it. Two independent committees, same block, same round.
What slowed me down reading this was the word "independently." Most PoS systems use one committee to propose and approve. Dusk uses two separate committees for validation and ratification, meaning a block needs agreement from two groups who were selected randomly and separately before it is ever considered final. A single compromised committee cannot push through an invalid block alone.
The randomness matters more than it first appears. Provisioners are selected through sortition - weighted by stake, but non-deterministic. Nobody knows in advance which specific nodes will form the next validation or ratification committee. That uncertainty is the security mechanism. An attacker cannot bribe or target a committee that does not yet exist.
The minimum stake to participate is 1,000 DUSK. That number is not arbitrary - it sets the economic floor for what it costs to become a provisioner and potentially influence committee selection. The higher the total staked, the more expensive it becomes to accumulate enough weight to matter.
What I find genuinely unresolved is the relationship between stake concentration and sortition outcomes over time. If a small number of large provisioners dominate the stake weight, the "random" selection starts producing predictable patterns. The cryptography holds, but the economic assumptions underneath it require watching.
#dusk $DUSK @Dusk Многие люди, впервые взглянув на Dusk, сводят Phoenix и Moonlight к простому переключателю — режиму private и public. Я все время думал, что такое обрамление упускает самое интересное: то, как эти две модели уживаются в рамках одного протокола.
Phoenix — это не просто «private». Это полностью иная архитектура транзакций. Средства не хранятся на балансах — они существуют как зашифрованные ноты. Когда вы тратите, вы используете существующие ноты и создаёте новые, доказывая с помощью доказательств с нулевым разглашением, что не было двойных списаний и что суммы сходятся, при этом не раскрывается, кто отправил кому и сколько переместилось. Получатель видит ноту. Никто другой — не видит, если только вы не поделитесь ключом просмотра.
Moonlight работает наоборот: аккаунтно-ориентированная модель, полностью прозрачная — отправитель, получатель и сумма видны в сети on-chain. Это тот тип модели, который большинство людей уже понимают по Ethereum.
Меня же зацепило, что обе модели производят расчёты через один и тот же Transfer Contract на DuskDS. Это не отдельные цепочки и не отдельные реестры. Транзакция Phoenix и транзакция Moonlight могут обе существовать внутри одного и того же блока, завершённого в рамках того же раунда консенсуса, и при этом ни одной из моделей не нужно знать внутреннюю логику другой.
На что стоит задержаться, так это на том, что это означает для регулируемых активов. Для сделки с ценными бумагами регулятору может потребоваться полная прозрачность, а контрагенту — полная конфиденциальность. Ключи просмотра Phoenix позволяют делать выборочное раскрытие: вы показываете ровно то, что нужно, ровно тому, кому требуется, и ничего лишнего. Moonlight обрабатывает потоки, где прозрачность по умолчанию является требованием.
Сложнее ответить, примут ли регуляторы раскрытие на основе ключей просмотра как эквивалент традиционных аудиторских следов. Криптография работает. А вот поспеют ли юридические рамки — совсем другой вопрос.