#dusk $DUSK
Технические детали этой виртуальной машины Dusk — тоже, чем глубже копаешь, тем больше голова идёт кругом.
Сначала меня очень удивляло: где хранятся в контракте состояния типа “позиции”, “права” и прочие атрибуты? Я переворошил всё полдня, прежде чем понял: он запихивает целиком состояние контракта в один непрерывный участок памяти, а после каждого изменения просто переписывает обратно всю эту область целиком. Это совсем не похоже на привычный EVM. У них меняется то, где надо; как будто исправляешь документ — трогаешь только одну строку. А тут даже если поменять одно число, приходится полностью перетаскивать и переписывать всю страницу памяти.
Мало того, на это ещё наслаивается двойная бухгалтерская система. Открытая книга — для регулятора, а приватная — в XSC. После каждой транзакции: один раз изменяются открытые состояния, и ещё раз приватные состояния пересоздаются. Оба копии памяти приходится записывать обратно. Плюс со стороны Hedger нужно ещё прогнать один раз генерацию доказательств с нулевым разглашением — и узлы параллельно пересчитывают заново. Выходит, что это не “1+1” по затратам, а перемножается.
Токенизированные ценные бумаги: позиции, белые списки, правила локирования — и так по логике состояния только нарастают, а не уменьшаются. Если задеплоить даже относительно сложный контракт XSC, то при изменении всего одного баланса всё равно требуется полностью перезаписывать всю страницу памяти.
Кто-нибудь наверняка скажет: “Да что такого, ведь всё живёт наверху, а внизу DuskDS хранит только доказательства”. Звучит разумно, но при внимательном разборе — не сходится! А архивные узлы не хранят снапшоты истории памяти? Если нет, то как потом аудиторам проверять историю состояний — что проверять? “Воздух”? Если снапшоты хранятся, то чем это отличается от полного узла? По сути, проблему накапливания состояний просто переносят с уровня исполнения на уровень архива.
Официальные объяснения крутятся вокруг да около, но ни одного прямого ответа “по делу” так и не дали.
Сейчас меня больше всего волнует, как реально обстоят дела с ончейн-контрактами ценных бумаг NPEX. Если в течение полугода объём состояния одиночного контракта будет в 10 раз больше, чем у обычного ERC20, либо архивные узлы начнут тайно хранить снапшоты памяти — тогда эта конструкция окажется чистым минным полем для RWA, и я просто не буду этим пользоваться.
О да! Ещё одна ловушка: краткие доказательства DuskDS могут подтвердить, что сама приватная бухгалтерская книга в целом корректна, но могут ли они доказать, что каждая запись истории снапшотов памяти была последовательной и ни разу не изменялась? Если доказать нельзя, то аудиторская трассировка токенизированных ценных бумаг прервётся прямо на середине — между уровнем приватности и уровнем архива.
@Dusk
Технические детали этой виртуальной машины Dusk — тоже, чем глубже копаешь, тем больше голова идёт кругом.
Сначала меня очень удивляло: где хранятся в контракте состояния типа “позиции”, “права” и прочие атрибуты? Я переворошил всё полдня, прежде чем понял: он запихивает целиком состояние контракта в один непрерывный участок памяти, а после каждого изменения просто переписывает обратно всю эту область целиком. Это совсем не похоже на привычный EVM. У них меняется то, где надо; как будто исправляешь документ — трогаешь только одну строку. А тут даже если поменять одно число, приходится полностью перетаскивать и переписывать всю страницу памяти.
Мало того, на это ещё наслаивается двойная бухгалтерская система. Открытая книга — для регулятора, а приватная — в XSC. После каждой транзакции: один раз изменяются открытые состояния, и ещё раз приватные состояния пересоздаются. Оба копии памяти приходится записывать обратно. Плюс со стороны Hedger нужно ещё прогнать один раз генерацию доказательств с нулевым разглашением — и узлы параллельно пересчитывают заново. Выходит, что это не “1+1” по затратам, а перемножается.
Токенизированные ценные бумаги: позиции, белые списки, правила локирования — и так по логике состояния только нарастают, а не уменьшаются. Если задеплоить даже относительно сложный контракт XSC, то при изменении всего одного баланса всё равно требуется полностью перезаписывать всю страницу памяти.
Кто-нибудь наверняка скажет: “Да что такого, ведь всё живёт наверху, а внизу DuskDS хранит только доказательства”. Звучит разумно, но при внимательном разборе — не сходится! А архивные узлы не хранят снапшоты истории памяти? Если нет, то как потом аудиторам проверять историю состояний — что проверять? “Воздух”? Если снапшоты хранятся, то чем это отличается от полного узла? По сути, проблему накапливания состояний просто переносят с уровня исполнения на уровень архива.
Официальные объяснения крутятся вокруг да около, но ни одного прямого ответа “по делу” так и не дали.
Сейчас меня больше всего волнует, как реально обстоят дела с ончейн-контрактами ценных бумаг NPEX. Если в течение полугода объём состояния одиночного контракта будет в 10 раз больше, чем у обычного ERC20, либо архивные узлы начнут тайно хранить снапшоты памяти — тогда эта конструкция окажется чистым минным полем для RWA, и я просто не буду этим пользоваться.
О да! Ещё одна ловушка: краткие доказательства DuskDS могут подтвердить, что сама приватная бухгалтерская книга в целом корректна, но могут ли они доказать, что каждая запись истории снапшотов памяти была последовательной и ни разу не изменялась? Если доказать нельзя, то аудиторская трассировка токенизированных ценных бумаг прервётся прямо на середине — между уровнем приватности и уровнем архива.
@Dusk