У сумерек есть две контрактные среды, но интересная часть не в том, что их две.
duskvm работает напрямую в L1, выполнение контракта и расчёты dusk происходят в одном месте. duskevm
на поверхности выглядит раздельно: Solidity, EVM-кошельки, у него свой RPC, но транзакция duskevm на самом деле проходит через четыре стадии, прежде чем по-настоящему будет завершена. Сначала она попадает в секвенсер, затем включается в блок L2, затем.
батчер публикует эти данные транзакции в duskds, и только после этого коммиты состояния и доказательства неисправности связывают получившееся состояние обратно с settlement в duskds.
легко упустить из виду, что включение и завершение — это.
явно два разных этапа, а не один. транзакция может быстро появиться в блоке L2, тогда как фактический шаг settlement ещё догоняет её.
это различие важнее, чем звучит.
в документации прямо предупреждают не делать вывод о окончательности по прошедшему времени и говорят, что приложения, переводящие ценности между duskevm и L1, должны проверять статус протокола или кошелька вместо этого. я не ожидал, что будет такой разрыв между.
setlement'ом, который нужно назвать так прямо, и это похоже на то самое место, где ошибки могли бы прятаться, если команда решит, что быстрая транзакция уже окончательная.
если бы вы строили на duskevm, вы бы проверяли статус settlement до или после показа пользователю успешного экрана??
#dusk @Dusk $DUSK
duskvm работает напрямую в L1, выполнение контракта и расчёты dusk происходят в одном месте. duskevm
на поверхности выглядит раздельно: Solidity, EVM-кошельки, у него свой RPC, но транзакция duskevm на самом деле проходит через четыре стадии, прежде чем по-настоящему будет завершена. Сначала она попадает в секвенсер, затем включается в блок L2, затем.
батчер публикует эти данные транзакции в duskds, и только после этого коммиты состояния и доказательства неисправности связывают получившееся состояние обратно с settlement в duskds.
легко упустить из виду, что включение и завершение — это.
явно два разных этапа, а не один. транзакция может быстро появиться в блоке L2, тогда как фактический шаг settlement ещё догоняет её.
это различие важнее, чем звучит.
в документации прямо предупреждают не делать вывод о окончательности по прошедшему времени и говорят, что приложения, переводящие ценности между duskevm и L1, должны проверять статус протокола или кошелька вместо этого. я не ожидал, что будет такой разрыв между.
setlement'ом, который нужно назвать так прямо, и это похоже на то самое место, где ошибки могли бы прятаться, если команда решит, что быстрая транзакция уже окончательная.
если бы вы строили на duskevm, вы бы проверяли статус settlement до или после показа пользователю успешного экрана??
#dusk @Dusk $DUSK