В эти дни я снова смотрю на @Dusk , и больше всего меня беспокоит не сами слова «конфиденциальность», а то, как система обрабатывает в транзакции то, что легче всего упустить: состояние.
Moonlight и Phoenix дают мне очень наглядный вход. Первый размещает баланс, отправителя, получателя и сумму в открытом аккаунте; второй превращает средства в зашифрованную note, при этом транзакция напрямую не раскрывает сумму, отправителя и конкретную note, а вместо этого использует ZKP, чтобы доказать, достаточно ли средств, нет ли двойной траты, и чтобы при аудите можно было раскрыть данные через viewing key. Эти две модели выглядят совершенно по‑разному, но в итоге им приходится отвечать на один и тот же вопрос: после завершения этой транзакции, во что именно должно преобразоваться состояние в блокчейне? По-настоящему я остановился и задумался о Transfer Contract — он принимает payload разных типов, передаёт их в соответствующую логику валидации и в конце включает результат в тот же набор глобального состояния. Именно этот шаг в конечном счёте определяет, что конфиденциальные транзакции не превратятся в отдельную, изолированную бухгалтерскую книгу.
Если идти дальше по состоянию, то DuskDS отвечает за консенсус, финальность, доступность данных и расчёты; DuskVM — за выполнение контрактов, скомпилированных в WASM, прямо «вплотную» к выполнению в Dusk L1; а DuskEVM предоставляет альтернативный путь выполнения в стиле EVM. Hedger работает поверх DuskEVM и с помощью гомоморфного шифрования и ZKP реализует конфиденциальные транзакции. Собранное вместе это означает: дело не в том, что транзакции «прячутся», а в том, что транзакции с разной степенью видимости всё равно могут попадать в одну и ту же систему обновления состояния и расчётов.
$DUSK отвечает за gas и staking, сводя стоимость исполнения и сетевую безопасность к одному экономическому уровню. Для меня следующий реально важный шаг — после встраивания этой конструкции в реальные финансовые процессы: сможет ли она обеспечивать, что скрывать нужно — скрывается, что проверять нужно — проверяется, а конечное состояние будет достаточно определённым и достаточно пригодным к использованию.
#dusk $DUSK @Dusk
Moonlight и Phoenix дают мне очень наглядный вход. Первый размещает баланс, отправителя, получателя и сумму в открытом аккаунте; второй превращает средства в зашифрованную note, при этом транзакция напрямую не раскрывает сумму, отправителя и конкретную note, а вместо этого использует ZKP, чтобы доказать, достаточно ли средств, нет ли двойной траты, и чтобы при аудите можно было раскрыть данные через viewing key. Эти две модели выглядят совершенно по‑разному, но в итоге им приходится отвечать на один и тот же вопрос: после завершения этой транзакции, во что именно должно преобразоваться состояние в блокчейне? По-настоящему я остановился и задумался о Transfer Contract — он принимает payload разных типов, передаёт их в соответствующую логику валидации и в конце включает результат в тот же набор глобального состояния. Именно этот шаг в конечном счёте определяет, что конфиденциальные транзакции не превратятся в отдельную, изолированную бухгалтерскую книгу.
Если идти дальше по состоянию, то DuskDS отвечает за консенсус, финальность, доступность данных и расчёты; DuskVM — за выполнение контрактов, скомпилированных в WASM, прямо «вплотную» к выполнению в Dusk L1; а DuskEVM предоставляет альтернативный путь выполнения в стиле EVM. Hedger работает поверх DuskEVM и с помощью гомоморфного шифрования и ZKP реализует конфиденциальные транзакции. Собранное вместе это означает: дело не в том, что транзакции «прячутся», а в том, что транзакции с разной степенью видимости всё равно могут попадать в одну и ту же систему обновления состояния и расчётов.
$DUSK отвечает за gas и staking, сводя стоимость исполнения и сетевую безопасность к одному экономическому уровню. Для меня следующий реально важный шаг — после встраивания этой конструкции в реальные финансовые процессы: сможет ли она обеспечивать, что скрывать нужно — скрывается, что проверять нужно — проверяется, а конечное состояние будет достаточно определённым и достаточно пригодным к использованию.
#dusk $DUSK @Dusk