Я слишком долго копался прошлой ночью в документации по архитектуре Dusk. Не буду врать: мозг постоянно цеплялся за одну вещь.
У них есть Zedger (UTXO-подобный, privacy-first для ценных бумаг) и DuskEVM (OP Stack EVM для разработчиков Solidity). На бумаге всё выглядит аккуратно — логика расчётов остаётся отдельно от логики приложений.
Но у Zedger есть одна конкретная, довольно крутая функция: получатель должен явно одобрить перевод, прежде чем он будет фактически завершён. Это особенно важно для регулируемых активов. Ваш security-токен не может просто «сам собой» оказаться перетянутым в какой-нибудь случайный кошелёк.
Теперь представьте: вы заворачиваете этот актив и переносите его на сторону EVM. В EVM нет этого состояния «ожидает одобрения» нативно — там просто стандартные переходы состояния.
Так кто тогда обеспечивает это правило, когда актив оказывается «по ту сторону»?
Публичная документация не очень-то подробно описывает механику бриджа. Возможно, они переносят этот контекст соответствия, но, честно говоря, это выглядит так, будто вы просто пересобираете логику Zedger внутри Solidity. Тогда зачем держать всё раздельным?
Вероятно, поэтому DuskVM (слой приватности на WASM) выделяют в отдельную сущность — чтобы действительно регулируемое оставалось изолированным от «дикого запада» EVM.
Три рантайма. Два бриджа. Звучит амбициозно, но я сижу и думаю, действительно ли эти стыки герметичны. Похоже, могут возникать странные несоответствия состояния, когда актив прыгает между слоями.
Я не пытаюсь разгонять FUD — подход мне даже нравится. Просто реально интересно: есть ли у кого-то понимание, как они планируют держать синхронизацию состояния между слоями «в тонусе» на практике.
@Dusk #dusk #DUSK $DUSK
У них есть Zedger (UTXO-подобный, privacy-first для ценных бумаг) и DuskEVM (OP Stack EVM для разработчиков Solidity). На бумаге всё выглядит аккуратно — логика расчётов остаётся отдельно от логики приложений.
Но у Zedger есть одна конкретная, довольно крутая функция: получатель должен явно одобрить перевод, прежде чем он будет фактически завершён. Это особенно важно для регулируемых активов. Ваш security-токен не может просто «сам собой» оказаться перетянутым в какой-нибудь случайный кошелёк.
Теперь представьте: вы заворачиваете этот актив и переносите его на сторону EVM. В EVM нет этого состояния «ожидает одобрения» нативно — там просто стандартные переходы состояния.
Так кто тогда обеспечивает это правило, когда актив оказывается «по ту сторону»?
Публичная документация не очень-то подробно описывает механику бриджа. Возможно, они переносят этот контекст соответствия, но, честно говоря, это выглядит так, будто вы просто пересобираете логику Zedger внутри Solidity. Тогда зачем держать всё раздельным?
Вероятно, поэтому DuskVM (слой приватности на WASM) выделяют в отдельную сущность — чтобы действительно регулируемое оставалось изолированным от «дикого запада» EVM.
Три рантайма. Два бриджа. Звучит амбициозно, но я сижу и думаю, действительно ли эти стыки герметичны. Похоже, могут возникать странные несоответствия состояния, когда актив прыгает между слоями.
Я не пытаюсь разгонять FUD — подход мне даже нравится. Просто реально интересно: есть ли у кого-то понимание, как они планируют держать синхронизацию состояния между слоями «в тонусе» на практике.
@Dusk #dusk #DUSK $DUSK
