деталь про Феникс легко упустить:
потраченные записи остаются в дереве Меркла.
сначала я относился к этому дереву как к приватному набору UTXO. когда запись тратилась, я предполагал, что она исчезнет.
но в whitepaper сказано иначе.
когда запись Phoenix тратится, её владелец выводит из секретного ключа записи нултификатор. сеть записывает этот нултификатор, чтобы данную запись нельзя было потратить снова.
но при этом она не узнаёт, к какой именно записи относится этот нултификатор.
поэтому запись остаётся. дерево продолжает расти.
это создаёт различие, о котором я раньше не думал:
записано — не то же самое, что тратимо.
последний корень Меркла позволяет сети проверить, что входящая запись принадлежит дереву. одной принадлежности недостаточно, чтобы значение всё ещё было актуальным.
этот ответ находится в списке нултификаторов.
и Phoenix сохраняет публичную связь между обоими скрытыми аспектами.
в Moonlight карты связаны с публичным балансом.
Phoenix работает иначе. сеть проверяет ZK-доказательство того, что входные записи корректно занулефицированы и что они содержат достаточно стоимости для создания новых записей, депозита и максимального газа, при этом не раскрывая суммы.
поэтому запись Phoenix может оставаться зарегистрированной даже после того, как её экономическая полезность исчезла.
запись переживает.
право на трату — нет.
затем есть ещё одно разделение.
ключ просмотра можно выдать доверенной стороне, чтобы она просканировала сеть и идентифицировала транзакции, адресованные пользователю. но всё равно она не сможет потратить эти записи, потому что секретный ключ записи требует от пользователя весь его секретный ключ.
так что «может видеть моё приватное состояние» и «может контролировать моё приватное состояние» — это разные уровни доступа.
появляются две границы:
записано / тратимо
видимо / контролируемо
краевой случай, к которому я всё время возвращаюсь, — это приложение, реконструирующее то, что у пользователя есть прямо сейчас.
наличия записи недостаточно.
даже если уметь её распознать — тоже недостаточно.
нужны история, состояние занулефикации и нужный объём секретного материала.
поэтому мне интересно:
в приватной бухгалтерской книге «текущее состояние» — это вообще один объект или пересечение намеренно неполных записей, которое при чтении в одиночку выходит неполным?
@Dusk #dusk $DUSK $VELVET $APR
потраченные записи остаются в дереве Меркла.
сначала я относился к этому дереву как к приватному набору UTXO. когда запись тратилась, я предполагал, что она исчезнет.
но в whitepaper сказано иначе.
когда запись Phoenix тратится, её владелец выводит из секретного ключа записи нултификатор. сеть записывает этот нултификатор, чтобы данную запись нельзя было потратить снова.
но при этом она не узнаёт, к какой именно записи относится этот нултификатор.
поэтому запись остаётся. дерево продолжает расти.
это создаёт различие, о котором я раньше не думал:
записано — не то же самое, что тратимо.
последний корень Меркла позволяет сети проверить, что входящая запись принадлежит дереву. одной принадлежности недостаточно, чтобы значение всё ещё было актуальным.
этот ответ находится в списке нултификаторов.
и Phoenix сохраняет публичную связь между обоими скрытыми аспектами.
в Moonlight карты связаны с публичным балансом.
Phoenix работает иначе. сеть проверяет ZK-доказательство того, что входные записи корректно занулефицированы и что они содержат достаточно стоимости для создания новых записей, депозита и максимального газа, при этом не раскрывая суммы.
поэтому запись Phoenix может оставаться зарегистрированной даже после того, как её экономическая полезность исчезла.
запись переживает.
право на трату — нет.
затем есть ещё одно разделение.
ключ просмотра можно выдать доверенной стороне, чтобы она просканировала сеть и идентифицировала транзакции, адресованные пользователю. но всё равно она не сможет потратить эти записи, потому что секретный ключ записи требует от пользователя весь его секретный ключ.
так что «может видеть моё приватное состояние» и «может контролировать моё приватное состояние» — это разные уровни доступа.
появляются две границы:
записано / тратимо
видимо / контролируемо
краевой случай, к которому я всё время возвращаюсь, — это приложение, реконструирующее то, что у пользователя есть прямо сейчас.
наличия записи недостаточно.
даже если уметь её распознать — тоже недостаточно.
нужны история, состояние занулефикации и нужный объём секретного материала.
поэтому мне интересно:
в приватной бухгалтерской книге «текущее состояние» — это вообще один объект или пересечение намеренно неполных записей, которое при чтении в одиночку выходит неполным?
@Dusk #dusk $DUSK $VELVET $APR
