Сумерки разворачивают EVM-совместимый слой
наряду с родной цепочкой, и заявленная логика
проста: снизить порог входа для разработчиков, чтобы существующие инструменты Solidity
подключались вместо того, чтобы каждый создатель учился новой экосистеме
с нуля. На первый взгляд, это очевидный шаг — знакомство с EVM
это крупнейший пул разработчиков в крипто,
и отказ встретить его на полпути — это то, как перспективные L1 остаются
навсегда узкими.
Но меня удерживает более узкий вопрос:
наследует ли EVM-совместимый слой реальные гарантии приватности Dusk,
или же он наследует прозрачность EVM по умолчанию и просто существует рядом
с слоем приватности Dusk, не затрагивая его?
Это не одно и то же, и здесь это различие
важнее, чем для большинства L1
добавление совместимости с EVM, потому что приватность и комплаенс-ориентированное раскрытие — это
единственная причина существования Dusk.
Если контракт, развернутый на EVM-слое,
ведёт себя как любой другой EVM-контракт — общедоступное состояние, общедоступные
calldata и стандартная модель прозрачности — тогда "Dusk поддерживает EVM" и "приватная модель Dusk распространяется на EVM" — это два разных утверждения,
и только маркетинг обычно заставляет подать их одновременно.
Честная версия этой дилеммы в том, что совместимость с EVM и нативные защищённые вычисления
в некотором смысле структурно противостоят друг другу.
Модель выполнения EVM не создавалась с учётом выборочного раскрытия;
основное ценностное предложение Dusk было построено именно вокруг этого.
Свести эти два мира воедино — дать привычные
инструменты, но при этом получать конфиденциальные
транзакции и смарт-контракты, учитывающие комплаенс — это действительно сложная задача интеграции, а не галочка.
Возможно, Dusk решил это элегантно.
Также возможно, что фраза "EVM compatible" тихо означает "EVM-совместимо для прозрачной части цепочки",
а реальные контракты, сохраняющие приватность, по-прежнему требуют родной стэк XSC
и кривую обучения, которую совместимость с EVM якобы должна была устранить.
@Dusk #dusk $DUSK
наряду с родной цепочкой, и заявленная логика
проста: снизить порог входа для разработчиков, чтобы существующие инструменты Solidity
подключались вместо того, чтобы каждый создатель учился новой экосистеме
с нуля. На первый взгляд, это очевидный шаг — знакомство с EVM
это крупнейший пул разработчиков в крипто,
и отказ встретить его на полпути — это то, как перспективные L1 остаются
навсегда узкими.
Но меня удерживает более узкий вопрос:
наследует ли EVM-совместимый слой реальные гарантии приватности Dusk,
или же он наследует прозрачность EVM по умолчанию и просто существует рядом
с слоем приватности Dusk, не затрагивая его?
Это не одно и то же, и здесь это различие
важнее, чем для большинства L1
добавление совместимости с EVM, потому что приватность и комплаенс-ориентированное раскрытие — это
единственная причина существования Dusk.
Если контракт, развернутый на EVM-слое,
ведёт себя как любой другой EVM-контракт — общедоступное состояние, общедоступные
calldata и стандартная модель прозрачности — тогда "Dusk поддерживает EVM" и "приватная модель Dusk распространяется на EVM" — это два разных утверждения,
и только маркетинг обычно заставляет подать их одновременно.
Честная версия этой дилеммы в том, что совместимость с EVM и нативные защищённые вычисления
в некотором смысле структурно противостоят друг другу.
Модель выполнения EVM не создавалась с учётом выборочного раскрытия;
основное ценностное предложение Dusk было построено именно вокруг этого.
Свести эти два мира воедино — дать привычные
инструменты, но при этом получать конфиденциальные
транзакции и смарт-контракты, учитывающие комплаенс — это действительно сложная задача интеграции, а не галочка.
Возможно, Dusk решил это элегантно.
Также возможно, что фраза "EVM compatible" тихо означает "EVM-совместимо для прозрачной части цепочки",
а реальные контракты, сохраняющие приватность, по-прежнему требуют родной стэк XSC
и кривую обучения, которую совместимость с EVM якобы должна была устранить.
@Dusk #dusk $DUSK