#dusk $DUSK Я сегодня разбирал документ по торговой модели Phoenix для @Dusk и застрял на одном базовом, но легко пропускаемом понятии для приватных цепочек: на уровне протокола $DUSK вообще нет такого объекта, как «счёт».

В прозрачных сетях вроде Ethereum каждый адрес — это счёт, а баланс и история транзакций видны всему миру. Но Phoenix идёт по маршруту UTXO — на уровне протокола не хранятся счета, а хранится набор объектов, называемых «note». Каждый note содержит сумму и условие расходования, а транзакция — это процесс потребления старых note и создания новых. Хэш новых note добавляется в дерево Merkle, а листья дерева хранят отпечатки всех note во всей сети.

Защита от двойной траты здесь устроена очень интересно. Каждая транзакция содержит набор детерминированных значений, называемых «nullifier»; каждый nullifier соответствует одному уже потраченному note и помечает его как недействительный. Но способ генерации nullifier проходит криптографическую обработку, поэтому внешнему наблюдателю, увидевшему появление какого-то nullifier, понятно лишь, что «какой-то note был потрачен», однако невозможно сопоставить этот nullifier с конкретным note. Сеть подтверждает погашение, но не знает, кто именно был погашен.

Если провести аналогию, это не похоже на банковскую сверку, где достаточно открыть нужную страницу и увидеть все операции конкретного человека. Это скорее как разорвать каждый чек на кусочки и отправить их в шредер, а затем криптографическим способом сообщить системе: «этот чек погашен». Система подтверждает, что погашение действительно, но человек, копающийся в шредере, не сможет собрать исходный чек и не узнает, кому он принадлежал изначально.

Но и эта схема не бесплатна. По мере роста числа note дерево Merkle увеличивается, и полным узлам приходится поддерживать полную структуру дерева; генерация nullifier опирается на базовые криптографические предположения, и если с выбором параметров возникнет проблема, защита приватности окажется почти фикцией. В официальной документации раскрыты детали протокола, но в производственной среде нужно будет постоянно сопоставлять частоту коллизий nullifier и скорость разрастания дерева уже после запуска основной сети.

Глядя на #dusk со стороны приватного слоя, я бы не ограничивался ярлыком «используется UTXO». По-настоящему нужно отслеживать кривую роста числа note, размер множества nullifier и нагрузку на хранилище узлов валидации. $DUSK встраивает приватность в саму основу протокола, но стоимость обслуживания базового реестра в конечном итоге отразится на производительности всей сети.

#dusk @Dusk