Я думал, что Citadel — это просто еще один слой идентичности.
Вы знаете, какой.
Подключи кошелек, пройди проверки соответствия, поставь галочку — и дальше.
Но чем больше я разбирался в том, как учетные данные реально проходят через систему, тем меньше это напоминало хранилище.
Скорее это походило на фильтр.
Вместо того чтобы просить пользователей передать все свои персональные данные, система может сосредоточиться на доказательстве конкретного утверждения, не превращая лежащую в основе информацию в то, что передается из рук в руки.
Этот сдвиг довольно тонкий, но, думаю, он важен.
Бремя переходит от раскрытия к подтверждению (attestation).
И есть еще одна часть, которая показалась мне интересной.
Удостоверение — не обязательно то, что вы храните вечно.
Его полезность зависит от того, действительно ли утверждение по-прежнему верно.
Поэтому проверка становится менее связанной со сбором данных об идентичности и больше — с многократным подтверждением того, что вы по-прежнему соответствуете требуемым условиям.
Это создает другой тип трения.
Пользователи не обязательно остаются, потому что система удобна.
Они могут оставаться, потому что запуск процесса верификации где-то еще имеет свою цену.
Возможно, главный вопрос вокруг систем вроде Citadel как раз в этом.
Спрос действительно идет от людей, которые хотят больше доверия и приватности?
Или же он вызван растущей стоимостью повторного доказательства одного и того же где-то еще?
Чем больше я смотрю на DuskEVM, тем больше думаю, что самое интересное заключается не в том, что теперь Dusk просто поддерживает EVM.
Дело в том, что разработчикам не нужно выбрасывать рабочий процесс, который они уже знают.
Если вы создаёте с Solidity, Foundry, Hardhat, viem, ethers или знакомыми EVM-кошельками, DuskEVM разработан так, чтобы перенести этот опыт в экосистему Dusk.
Но внимание привлекла именно архитектура.
DuskEVM выполняет совместимое с Ethereum выполнение, тогда как DuskDS обеспечивает лежащий в основе уровень консенсуса, проведения расчётов и доступности данных.
DUSK используется для выполнения, и он может перемещаться между Dusk L1 и DuskEVM через мост.
Также важно понимать путь транзакции.
Транзакция поступает на секвенсор DuskEVM, попадает в L2-блок, и батчер публикует данные транзакции в DuskDS. Затем state commitments и fault proofs связывают получившееся состояние обратно с DuskDS для проведения расчётов.
Этот нюанс действительно важен.
Включение транзакции — это не то же самое, что финальное проведение расчётов.
Мне также нравится, что Dusk не заставляет каждого разработчика работать в одной-единственной среде.
Разработчики EVM могут использовать DuskEVM и свои существующие инструменты, а разработчики, которые пишут контракты Rust/WASM напрямую для Dusk L1, могут продолжать использовать DuskVM.
Так что мой вывод довольно прост:
DuskEVM интересен не только тем, что приносит в Dusk совместимость с EVM.
Он интересен тем, что даёт разработчикам привычную среду исполнения, соединяя её с собственной архитектурой Dusk для расчётов и доступности данных.
Это ощущается как гораздо более масштабная история, чем просто фраза «у Dusk теперь есть EVM».