Знаете сказку о каменном супе? Двое путников приходят в голодную деревню, опускают в котёл камень и обещают пир. Один житель добавляет морковь, другой приносит картошку, а к вечеру все едят суп и благодарят камень. Никто не задаётся вопросом, нужен ли он вообще. Эта история работает только потому, что камень ничего не делает.
Я задался этим вопросом, когда прочитал белую книгу Kite о MiCA. Сначала награды полностью выплачиваются в $KITE , а затем постепенно переходят на стейблкоины. Здесь стейблкоины — это морковь. Выплаты в них доказывают, что агенты могут пользоваться сетью. Но они не доказывают, что кому-то необходимо хранить $KITE . И рынок уже склоняется в эту сторону. По данным Keyrock, было совершено 176 миллионов агентских платежей, и 98,6% из них прошли в USDC. Если трафик Kite хоть сколько-нибудь похож на этот, суп становится всё наваристее, а камень остаётся необязательным.
Будем справедливы: Kite всё же находит камню применение. Вы стейкаете $KITE , чтобы запустить валидатор, владеть модулем или делегировать ему токены. Это залог, а не плата за проход: скорее покупка котла, чем оплата миски супа. Но размер залога растёт в зависимости от того, сколько безопасности и модулей нужно сети, а не от числа прошедших платежей. Эти две кривые вовсе не обязаны двигаться синхронно.
Поэтому я перестал обращать внимание на то, сколько агентов появляется. Число транзакций, количество агентов, логотипы партнёров — ничто из этого не говорит, пришлось ли кому-нибудь покупать токен. Я бы доверял показателю комиссий в стейблкоинах на каждый застейканный $KITE и тому, должен ли владелец модуля блокировать больше KITE по мере роста его использования. Если оба показателя растут вместе, камень входит в рецепт. Если комиссии растут, а объём стейкинга остаётся прежним, это просто симпатичный камень в хорошем супе.
Я буду следить за двумя вещами: как быстро награды переходят с KITE на стейблкоины и ради каких модулей люди действительно блокируют токены. За чем следует токен — за супом или за стейкингом? #KiteBBW
Большинство инструментов конфиденциальности в криптовалютах скрывают то, что уже произошло. Защищённый перевод скрывает, кто кому заплатил, но намерения, стоящие за сделкой, часто остаются открытыми.
Стоп-лосс, условие срабатывания хранилища или ставка на аукционе могут раскрыть мои планы ещё до того, как я начну действовать. В прозрачном блокчейне такая уязвимость заложена в самой структуре, а не обязательно возникает из-за утечки.
Именно поэтому меня заинтересовали Covenants от Nillion. Я связываю инструкцию с условием и размещаю её в блокчейне в зашифрованном виде. Другие могут видеть, что Covenant существует, но не могут прочитать его содержимое, пока оно ожидает исполнения. Когда условие выполнено, пороговое число независимых узлов позволяет исполнить инструкцию — и мне не нужно полагаться на хранителя, чтобы защитить свою стратегию.
Больше всего мне нравится, что Covenant защищает само намерение: план до того, как он превратится в действие. Но конфиденциальность не следует путать с полной защитой. Она может снизить риск утечки стратегии, однако риски исполнения, манипулирование рынком, надёжность ценовых условий и допущения о сети узлов по-прежнему имеют значение. Если Covenant нельзя отменить после публикации, плохо сформулированное условие может стать серьёзной проблемой.
Dusk — первый релиз Covenants — уже работает в основной сети Ethereum, а не в тестовой версии. Изначально функциональность намеренно ограничена, благодаря чему запуск ощущается вполне осязаемым, однако более масштабной концепции ещё предстоит доказать свою состоятельность на практике.
Dusk — лишь первая из семи эпох дорожной карты Nillion; до конца года ожидаются новые релизы. Мне интересно увидеть, как последующие эпохи расширят возможности разработчиков, сохранив при этом надёжность исполнения и ясность предположений о доверии.
Главное испытание — не просто возможность сохранить намерения в тайне, а способность конфиденциального исполнения сделать рынки справедливее, не создавая новых рисков, которые пользователям трудно оценить.
Я снова и снова возвращаюсь к wallet-first подходу Dusk Trade к токенизированным финансовым активам. Подключение кошелька делает модель владения понятной и прямой. Ваш кошелёк подключён, актив появляется там, и естественное предположение — что вы им управляете. Но в случае регулируемых активов доступ к кошельку и фактический контроль над активом не всегда должны совпадать. Я пока не знаю, является ли подключённый кошелёк реальной точкой контроля для обеспечения безопасности (security), или же это просто уровень доступа инвестора, тогда как хранение (custody) и некоторые контролирующие функции на уровне активов находятся в другом месте.
Механики, за которыми стоит следить, — это где именно размещается security, кто может авторизовать перевод и что происходит, если инвестор теряет доступ к кошельку. Обычная транзакция показывает мне только то, как актив перемещается, когда всё работает так, как ожидается. Пути восстановления, заморозки и ограничения переводов говорят гораздо больше о том, кто на самом деле этим управляет. Это различие важно, потому что кошелёк может определить интерфейс инвестора, не определяя при этом полный набор полномочий, связанных с активом.
Я оценивал бы модель custody в Dusk по тому, что держатель кошелька действительно может контролировать, и какие другие стороны всё ещё могут отменять или переопределять.
Вопрос в том, является ли кошелёк реальной точкой контроля инвестора или лишь интерфейсом, через который осуществляется регулируемое владение. Я наблюдаю за путями перевода, восстановления и заморозки, чтобы понять, что именно подключённый кошелёк может реально контролировать. #dusk $DUSK @Dusk 🔥