#dusk $DUSK @Dusk
Эсан спросил меня кое-что на ужине, что заставило меня переосмыслить одну деталь «Dusk»
Почему разработчик вообще должен считать, что если прошло достаточно времени, значит экономическое состояние уже готово к использованию?
Звучит просто, но это становится важным, когда выполнение и расчёты разделены. DuskDS предоставляет основу для расчётов, окончательности и доступности данных, тогда как DuskVM запускает контракты Rust/WASM напрямую в L1, а DuskEVM обеспечивает EVM-исполнение, которое урегулируется через DuskDS.
Интересная часть в том, что мост Dusk не рассматривает время как примитив безопасности.
Вывод DuskEVM проходит через отдельные стадии: инициирование, подтверждение и финализацию. Будет ли следующее действие готово, зависит от опубликованного состояния сети, зрелости доказательства и проверок в dispute-game. Документация прямо говорит разработчикам не вычислять готовность, полагаясь только на прошедшее время.
Эта деталь имеет более широкие последствия, чем сам мост.
В финансовой инфраструктуре разработчики часто превращают асинхронные процессы в простую прикладную логику ожидание X минут, затем предполагают, что состояние можно безопасно потреблять. Но если готовность протокола зависит от состояния и доказательств, а не от фиксированных часов, такой «короткий путь» может создать скрытый риск интеграции.
Приложение может быть совершенно корректным относительно той транзакции, которую оно отправило, но при этом ошибаться во времени, когда её экономические последствия стали пригодными к использованию.
Именно это различие я нахожу ценным в Dusk. Окончательность — это не просто временная метка, прикреплённая к транзакции. Для систем, работающих в разных средах, это становится состоянием, определённым Протоколом, которое приложения обязаны читать и учитывать.
По мере того как Dusk расширяет свои уровни исполнения, я думаю, это станет важным принципом для разработчиков
Должны ли состояния готовности, определённые Протоколом, стать интерфейсом первого класса для финансовых приложений, вместо того чтобы оставлять интеграторам возможность выводить окончательность по времени и статусу транзакции? ⚙️
@Binance Square Official $SOL
Эсан спросил меня кое-что на ужине, что заставило меня переосмыслить одну деталь «Dusk»
Почему разработчик вообще должен считать, что если прошло достаточно времени, значит экономическое состояние уже готово к использованию?
Звучит просто, но это становится важным, когда выполнение и расчёты разделены. DuskDS предоставляет основу для расчётов, окончательности и доступности данных, тогда как DuskVM запускает контракты Rust/WASM напрямую в L1, а DuskEVM обеспечивает EVM-исполнение, которое урегулируется через DuskDS.
Интересная часть в том, что мост Dusk не рассматривает время как примитив безопасности.
Вывод DuskEVM проходит через отдельные стадии: инициирование, подтверждение и финализацию. Будет ли следующее действие готово, зависит от опубликованного состояния сети, зрелости доказательства и проверок в dispute-game. Документация прямо говорит разработчикам не вычислять готовность, полагаясь только на прошедшее время.
Эта деталь имеет более широкие последствия, чем сам мост.
В финансовой инфраструктуре разработчики часто превращают асинхронные процессы в простую прикладную логику ожидание X минут, затем предполагают, что состояние можно безопасно потреблять. Но если готовность протокола зависит от состояния и доказательств, а не от фиксированных часов, такой «короткий путь» может создать скрытый риск интеграции.
Приложение может быть совершенно корректным относительно той транзакции, которую оно отправило, но при этом ошибаться во времени, когда её экономические последствия стали пригодными к использованию.
Именно это различие я нахожу ценным в Dusk. Окончательность — это не просто временная метка, прикреплённая к транзакции. Для систем, работающих в разных средах, это становится состоянием, определённым Протоколом, которое приложения обязаны читать и учитывать.
По мере того как Dusk расширяет свои уровни исполнения, я думаю, это станет важным принципом для разработчиков
Должны ли состояния готовности, определённые Протоколом, стать интерфейсом первого класса для финансовых приложений, вместо того чтобы оставлять интеграторам возможность выводить окончательность по времени и статусу транзакции? ⚙️
@Binance Square Official $SOL