Несколько дней назад, когда я листал X, мне попался пост про тестнет DuskEVM, и одна деталь привлекла мое внимание. 10 августа тестнет DuskEVM заработал, Solidity и Hardhat работали отлично, но Hedger — основной движок конфиденциальных контрактов — работает отдельно в тестнете Ethereum Sepolia с ноября 2025 года. Официальная команда до сих пор не объявляла, когда две части будут объединены.
Когда люди видят эту 9-месячную паузу, первая реакция — беспокойство. Цепочка, ориентированная на приватность, где слой конфиденциальности и слой EVM тестируются раздельно, может показаться необычной.
Но после ознакомления с технической документацией я начал думать, что такое двойное трековое тестирование могло быть недооцененным выбором в архитектуре Dusk. Стек Dusk слоистый: #Dusk отвечает за расчеты и доступность данных, DuskEVM — это слой EVM, а Hedger — слой приватности с использованием гомоморфного шифрования и доказательств с нулевым разглашением.
Если бы все три слоя тестировались вместе, криптографический баг и баг контракта могли бы стать трудноразличимыми. Раздельное тестирование позволяет команде сначала запустить слой EVM, дать разработчикам возможность развернуть приложения, затем отдельно проверить Hedger на Sepolia и, наконец, снова объединить его в $DUSK . Так процесс отладки становится гораздо более понятным.
Я не уверен, что такое решение действительно верное. Также возможно, что во время финального объединения могут возникнуть конфликты протоколов, и тогда часть предыдущей работы придется переделывать. Модульность звучит хорошо, но инженерия всегда связана с затратами на координацию.
Но с другой стороны, институциональные клиенты больше боятся того, что что-то сломается, чем того, что все будет идти медленно. Поэтапный запуск может быть более надежным, чем попытка сделать все сразу, а потом, столкнувшись с проблемами, откатывать изменения.
Запуск EVM первым и объединение Hedger после надлежащей валидации может просто быть способом убедиться, что фундамент прочный.
Что вы, ребята, думаете об этой стратегии двойного трекового тестирования? Хочу услышать мнение каждого.@Dusk
Когда люди видят эту 9-месячную паузу, первая реакция — беспокойство. Цепочка, ориентированная на приватность, где слой конфиденциальности и слой EVM тестируются раздельно, может показаться необычной.
Но после ознакомления с технической документацией я начал думать, что такое двойное трековое тестирование могло быть недооцененным выбором в архитектуре Dusk. Стек Dusk слоистый: #Dusk отвечает за расчеты и доступность данных, DuskEVM — это слой EVM, а Hedger — слой приватности с использованием гомоморфного шифрования и доказательств с нулевым разглашением.
Если бы все три слоя тестировались вместе, криптографический баг и баг контракта могли бы стать трудноразличимыми. Раздельное тестирование позволяет команде сначала запустить слой EVM, дать разработчикам возможность развернуть приложения, затем отдельно проверить Hedger на Sepolia и, наконец, снова объединить его в $DUSK . Так процесс отладки становится гораздо более понятным.
Я не уверен, что такое решение действительно верное. Также возможно, что во время финального объединения могут возникнуть конфликты протоколов, и тогда часть предыдущей работы придется переделывать. Модульность звучит хорошо, но инженерия всегда связана с затратами на координацию.
Но с другой стороны, институциональные клиенты больше боятся того, что что-то сломается, чем того, что все будет идти медленно. Поэтапный запуск может быть более надежным, чем попытка сделать все сразу, а потом, столкнувшись с проблемами, откатывать изменения.
Запуск EVM первым и объединение Hedger после надлежащей валидации может просто быть способом убедиться, что фундамент прочный.
Что вы, ребята, думаете об этой стратегии двойного трекового тестирования? Хочу услышать мнение каждого.@Dusk
