провел этим утром время, разбираясь, как именно транзакция duskevm проходит через систему, и честно? 😂 я думал, что раз она появилась в блоке, на этом всё — но оказалось, что это не совсем так.
так вот, duskevm — это совместимый с evm слой на dusk. то есть вы пишете solidity, используете обычные evm-кошельки и стандартные инструменты вроде foundry или hardhat и платите gas в dusk. но транзакция не живет и не умирает сама по себе только на duskevm. она проходит через жизненный цикл в стиле rollup. сначала ее отправляют на sequencer duskevm, затем относительно быстро включают в l2-блок. после этого batcher публикует данные транзакции в duskds — это слой фактического урегулирования (settlement) и доступности данных для dusk. именно state commitments и fault proofs связывают получившееся состояние обратно с duskds, так что транзакция реально урегулирована, а не просто где-то «лежит» в l2-блоке, ожидая.
к чему я снова и снова возвращаюсь — это фраза в документации, где inclusion и settlement отмечены как действительно разные стадии, и что приложения, которые передают ценность между duskevm и dusk l1, должны проверять статус протокола или кошелька, а не просто предполагать, что всё финализировано, потому что прошло какое-то время. это не формальность. я не нашел места, где было бы прямо сказано, насколько обычно велик этот разрыв на практике: быстрое включение явно не значит мгновенный settlement, но я не знаю реальное «окно ожидания», которое должен выдерживать пользователь.
но сама дизайнерская задумка для меня понятна. вместо того чтобы строить полностью отдельную evm-цепочку, которая «висит» сама по себе, duskevm остается привязанным к duskds для settlement и доступности данных. поэтому вы получаете полноценные инструменты для solidity, не теряя базовые гарантии по финальности слоев.
честно — не знаю, достаточно ли этот разрыв inclusion → settlement мал, чтобы его можно было игнорировать в повседневной разработке, или же бóидерам нужно активно учитывать это??
🤔
#dusk @Dusk $DUSK
так вот, duskevm — это совместимый с evm слой на dusk. то есть вы пишете solidity, используете обычные evm-кошельки и стандартные инструменты вроде foundry или hardhat и платите gas в dusk. но транзакция не живет и не умирает сама по себе только на duskevm. она проходит через жизненный цикл в стиле rollup. сначала ее отправляют на sequencer duskevm, затем относительно быстро включают в l2-блок. после этого batcher публикует данные транзакции в duskds — это слой фактического урегулирования (settlement) и доступности данных для dusk. именно state commitments и fault proofs связывают получившееся состояние обратно с duskds, так что транзакция реально урегулирована, а не просто где-то «лежит» в l2-блоке, ожидая.
к чему я снова и снова возвращаюсь — это фраза в документации, где inclusion и settlement отмечены как действительно разные стадии, и что приложения, которые передают ценность между duskevm и dusk l1, должны проверять статус протокола или кошелька, а не просто предполагать, что всё финализировано, потому что прошло какое-то время. это не формальность. я не нашел места, где было бы прямо сказано, насколько обычно велик этот разрыв на практике: быстрое включение явно не значит мгновенный settlement, но я не знаю реальное «окно ожидания», которое должен выдерживать пользователь.
но сама дизайнерская задумка для меня понятна. вместо того чтобы строить полностью отдельную evm-цепочку, которая «висит» сама по себе, duskevm остается привязанным к duskds для settlement и доступности данных. поэтому вы получаете полноценные инструменты для solidity, не теряя базовые гарантии по финальности слоев.
честно — не знаю, достаточно ли этот разрыв inclusion → settlement мал, чтобы его можно было игнорировать в повседневной разработке, или же бóидерам нужно активно учитывать это??
🤔
#dusk @Dusk $DUSK