Деталь “сумерек”, из-за которой я посмотрел второй раз, — это не стек ZK. Это то, что делает кошелёк, когда не знает, успешно ли прошла защищённая транзакция.
В Dusk Wallet v0.1.0 в транзакциях Phoenix появилась отслеживаемость “pending-nullifier reservation”. В её changelog сказано, что эти резервации не освобождаются автоматически после истечения таймаута у вочера, при неизвестном статусе, удалённом статусе или при единственном пропущенном опросе mempool.
Зачем намеренно держать средства в привязке после неопределённости?
Потому что Phoenix расходует заметки. Если кошелёк сразу же повторно использует тот же набор расходуемых заметок, пока первая транзакция, возможно, ещё может оказаться в сети, он может сформировать конфликтующие защищённые расходы. Также Dusk добавила spend mutex, чтобы не допускать параллельной сборки Phoenix-сообщений против тех же заметок.
Факт: это логика безопасности на стороне кошелька, а не новое правило консенсуса. Моё толкование: Dusk выбирает консервативный UX вместо оптимистичной доступности баланса, когда состояние транзакции неоднозначно.
Этот компромисс важен. Системам приватности нужно больше, чем сильная криптография; обработка состояния кошелька должна оставаться безопасной, когда видимость сети неполная.
Для DUSK я слежу за тем, смогут ли будущие релизы кошелька сократить этот “неопределённый” период, не ослабляя защиту. Насколько агрессивно должен приватный кошелёк разблокировать средства, когда состояние сети неясно?
@Dusk $DUSK #dusk
В Dusk Wallet v0.1.0 в транзакциях Phoenix появилась отслеживаемость “pending-nullifier reservation”. В её changelog сказано, что эти резервации не освобождаются автоматически после истечения таймаута у вочера, при неизвестном статусе, удалённом статусе или при единственном пропущенном опросе mempool.
Зачем намеренно держать средства в привязке после неопределённости?
Потому что Phoenix расходует заметки. Если кошелёк сразу же повторно использует тот же набор расходуемых заметок, пока первая транзакция, возможно, ещё может оказаться в сети, он может сформировать конфликтующие защищённые расходы. Также Dusk добавила spend mutex, чтобы не допускать параллельной сборки Phoenix-сообщений против тех же заметок.
Факт: это логика безопасности на стороне кошелька, а не новое правило консенсуса. Моё толкование: Dusk выбирает консервативный UX вместо оптимистичной доступности баланса, когда состояние транзакции неоднозначно.
Этот компромисс важен. Системам приватности нужно больше, чем сильная криптография; обработка состояния кошелька должна оставаться безопасной, когда видимость сети неполная.
Для DUSK я слежу за тем, смогут ли будущие релизы кошелька сократить этот “неопределённый” период, не ослабляя защиту. Насколько агрессивно должен приватный кошелёк разблокировать средства, когда состояние сети неясно?
@Dusk $DUSK #dusk