Я заметил одну примечательную вещь, когда думаю о роли Zilch на @Dusk — это похоже на своего рода «перевод» между двумя разными языками: языком значений, защищённых по модели UTXO с анонимными данными, и языком состояний контрактов по account-based модели, который нужен большинству логики смарт-контрактов для работы.
Phoenix работает примерно похоже на приватную UTXO-модель: значение существует в виде независимых записей (заметок), каждая запись сама доказывает свою корректность без необходимости знать глобальное состояние. Но большая часть контрактной логики, даже в рамках Rusk VM, обычно требует более непрерывной модели состояния — когда переменная может быть прочитана, изменена и записана в отслеживаемой последовательности. Это архитектурный разрыв между двумя разными моделями данных, и дело не только в приватности.
Если это так, то роль Zilch заключается не только в том, чтобы «скрывать информацию от посторонних», но и в том, чтобы служить мостом: переводить значение в виде разрозненной записи в входные данные, которые может потреблять модель состояний контракта — задача согласования данных, а не только безопасности. Затем PLONK доказывает, что процесс перевода выполнен по правилам, не раскрывая содержимое исходной записи.
Самоопровержение: это рассуждение основано на общем понимании различий между UTXO и account-based модели и не обязательно точно отражает реальные технические детали реализации Dusk — для подтверждения нужна более глубокая документация.
Я жду, что $DUSK опубликует более подробные технические материалы о том, как Zilch выполняет преобразование между этими двумя моделями данных, чтобы подтвердить, что это действительно задача совместимости UTXO–account, как я это представляю.
#dusk $BTC $ETH
Phoenix работает примерно похоже на приватную UTXO-модель: значение существует в виде независимых записей (заметок), каждая запись сама доказывает свою корректность без необходимости знать глобальное состояние. Но большая часть контрактной логики, даже в рамках Rusk VM, обычно требует более непрерывной модели состояния — когда переменная может быть прочитана, изменена и записана в отслеживаемой последовательности. Это архитектурный разрыв между двумя разными моделями данных, и дело не только в приватности.
Если это так, то роль Zilch заключается не только в том, чтобы «скрывать информацию от посторонних», но и в том, чтобы служить мостом: переводить значение в виде разрозненной записи в входные данные, которые может потреблять модель состояний контракта — задача согласования данных, а не только безопасности. Затем PLONK доказывает, что процесс перевода выполнен по правилам, не раскрывая содержимое исходной записи.
Самоопровержение: это рассуждение основано на общем понимании различий между UTXO и account-based модели и не обязательно точно отражает реальные технические детали реализации Dusk — для подтверждения нужна более глубокая документация.
Я жду, что $DUSK опубликует более подробные технические материалы о том, как Zilch выполняет преобразование между этими двумя моделями данных, чтобы подтвердить, что это действительно задача совместимости UTXO–account, как я это представляю.
#dusk $BTC $ETH
