У меня возникает сильное ощущение непрерывности при использовании DUSK для газа с обеих сторон архитектуры Dusk Network.
Текущий Dusk L1 и testnet DuskEVM по-прежнему являются отдельными средами выполнения. DuskEVM отправляет транзакции в секвенсер, публикует батчи и фиксации состояния в DuskDS и полагается на мост, чтобы перемещать DUSK и сообщения между ними.
Один актив не означает одно и то же состояние.
Эта разница легко теряется в кошельке. Баланс может покинуть L1, появиться внутри DuskEVM, оплатить Solidity-контракт, а позже вернуться. Для пользователя это выглядит как DUSK на протяжении всего процесса. Под капотом каждый переход зависит от другой стадии и статуса.
Это важно не только для перемещения токенов. Dusk хочет, чтобы EVM-приложения подключались к активам L1 и к сценариям, ориентированным на приватность. Если приложение рассматривает отправку в мост как завершённое расчётное урегулирование на L1, оно может действовать со стоимостью до того, как кросс-уровневый процесс достигнет состояния, которое предполагает пользователь.
Такая же неоднозначность может влиять и на сообщения. Вызов контракта с одной стороны может зависеть от состояния, которое другая сторона ещё не распознала.
Я не ищу одинаковые тайминги в обеих средах. Я ищу явное состояние.
Кошелёк должен сообщать, находятся ли средства на L1, приняты ли они мостом, представлены ли они в DuskEVM или доступны для возврата. Приложения должны использовать протокольный статус вместо догадок по прошедшему времени. Неудачные и задержанные переводы требуют одного пути восстановления, который не создаёт вторую транзакцию по ошибке.
Лучшее доказательство — это повторяющиеся депозиты и выводы под нагрузкой, с публичными распределениями задержек и без неоднозначных балансов после прерываний.
Dusk может сделать один и тот же токен полезным по всему своему стеку. Самая сложная задача — добиться того, чтобы каждый пользователь понимал, какая система сейчас контролирует этот токен, и что должно произойти, прежде чем контроль снова перейдёт дальше.
@Dusk_Foundation $DUSK #dusk
$ACE $BTW
Текущий Dusk L1 и testnet DuskEVM по-прежнему являются отдельными средами выполнения. DuskEVM отправляет транзакции в секвенсер, публикует батчи и фиксации состояния в DuskDS и полагается на мост, чтобы перемещать DUSK и сообщения между ними.
Один актив не означает одно и то же состояние.
Эта разница легко теряется в кошельке. Баланс может покинуть L1, появиться внутри DuskEVM, оплатить Solidity-контракт, а позже вернуться. Для пользователя это выглядит как DUSK на протяжении всего процесса. Под капотом каждый переход зависит от другой стадии и статуса.
Это важно не только для перемещения токенов. Dusk хочет, чтобы EVM-приложения подключались к активам L1 и к сценариям, ориентированным на приватность. Если приложение рассматривает отправку в мост как завершённое расчётное урегулирование на L1, оно может действовать со стоимостью до того, как кросс-уровневый процесс достигнет состояния, которое предполагает пользователь.
Такая же неоднозначность может влиять и на сообщения. Вызов контракта с одной стороны может зависеть от состояния, которое другая сторона ещё не распознала.
Я не ищу одинаковые тайминги в обеих средах. Я ищу явное состояние.
Кошелёк должен сообщать, находятся ли средства на L1, приняты ли они мостом, представлены ли они в DuskEVM или доступны для возврата. Приложения должны использовать протокольный статус вместо догадок по прошедшему времени. Неудачные и задержанные переводы требуют одного пути восстановления, который не создаёт вторую транзакцию по ошибке.
Лучшее доказательство — это повторяющиеся депозиты и выводы под нагрузкой, с публичными распределениями задержек и без неоднозначных балансов после прерываний.
Dusk может сделать один и тот же токен полезным по всему своему стеку. Самая сложная задача — добиться того, чтобы каждый пользователь понимал, какая система сейчас контролирует этот токен, и что должно произойти, прежде чем контроль снова перейдёт дальше.
@Dusk_Foundation $DUSK #dusk
$ACE $BTW