Главная / Масштабируемость Zcash: ключевые идеи из доклада Шона Боу (ZconVI)

Масштабируемость Zcash: ключевые идеи из доклада Шона Боу (ZconVI)

Все новости про Zcash в социальной сети «X» (бывший Twitter) | Интересные видео про Zcash на YouTube

Данная статья сгенерирована в формате структурированного исследования на основе выступления Шона на ZconVI. Ссылка на оригинальное англоязычное видео.

Существует облегчённая для понимания версия данной статьи.

Вступление. На конференции ZconVI криптограф Шон Боу (Sean Bowe) представил новое видение того, как сделать Zcash масштабируемым, не жертвуя приватностью. Он обозначил две главные проблемы текущего протокола и предложил решения, основанные на криптографических доказательствах.

Основные проблемы масштабируемости Zcash

Поиск полученных платежей (сканирование). В текущем Zcash, чтобы узнать о поступившей защищённой “ноте” (аналог монеты), ваш кошелёк должен просматривать все новые транзакции и пытаться расшифровать каждый зашифрованный выход. Иными словами, кошелёк проходит по каждому шифротексту в блокчейне и пробует открыть его своим ключом, чтобы понять, адресован ли выход вам. Это неэффективно: по мере роста числа пользователей и транзакций такой «полный перебор» требует всё больше ресурсов и времени. Такой механизм обнаружения новых средств плохо масштабируется – каждый новый пользователь увеличивает общую нагрузку на сеть, потому что все кошельки должны перебрать все выходы.
Хранение nullifier (идентификаторов траты). Zcash использует специальный идентификатор, называемый nullifier (нуллифаер, аннулирующий идентификатор), чтобы пометить каждую потраченную ноту и не дать её потратить дважды. Nullifier генерируется при создании ноты и выглядит как случайная строка байт. Когда вы тратите защищённую ноту, вы раскрываете её nullifier, и узлы сети проверяют, не видели ли они такой раньше. Если nullifier уже был в прошлом, значит, ноту пытались потратить повторно, и транзакция отвергается. Проблема в том, что узлы обязаны хранить список всех когда-либо встречавшихся nullifier-ов. С каждым блоком этот список растёт бесконечно, и проверка новой транзакции требует свериться со всем историческим перечнем. Это превращается в большую нагрузку на память и время: по мере роста использования Zcash каждый узел должен держать всё больший архив, что ограничивает масштабируемость.

Шон Боу указал, что именно эти два узких места – сканирование входящих нот и хранение nullifier – мешают Zcash масштабироваться до очень большого числа пользователей. В своём докладе он сосредоточился на второй проблеме (nullifier), хотя кратко упомянул и первую.

Как работает текущий механизм Zcash (приватные транзакции, синхронизация, доказательства)

Чтобы понять предлагаемые решения, важно разобраться, как сейчас функционируют защищённые транзакции Zcash:

Создание и получение “ноты”. Вы генерируете в кошельке новый адрес (с открытым и секретным ключом) и передаёте кому-то свой shielded-адрес. Когда вам отправляют платёж на этот адрес, формируется защищённая транзакция. В ней есть выход с шифрованными данными для получателя и криптографическим коммитментом (commitment) новой ноты. Коммитмент – это криптографическая «фиксация» содержания ноты, своего рода хеш, который скрывает её данные, но позволит позже доказать, что нота была зафиксирована в блокчейне. Внутри зашифрованного поля содержится информация, нужная вам для расшифровки и траты ноты (включая секретный ключ ноты, сумму и мемо).
Сканирование блокчейна кошельком. После получения транзакции, ваша программа-кошелёк должна определить, есть ли среди новых выходов транзакций “ноты” для вас. Для этого она перебирает каждый зашифрованный выход и пытается его расшифровать своим ключом. Если расшифровка удачна – значит, обнаружена ваша нота. Так кошелёк «узнаёт» о поступлении средств. Затем кошелёк сохраняет свидетельство включения этой ноты в блокчейн – т.е. необходимые данные (путь по дереву Меркла), доказывающие, что коммитмент вашей ноты есть в определённом блоке (в определённом корне дерева). Такое свидетельство называют witness (свидетельство, или анкёр – якорь). Оно понадобится позже при трате.
Синхронизация (обновление свидетельства). Блокчейн постоянно растёт – после того, как вы получили ноту, в сеть добавляются новые блоки с новыми нотами. Если пользоваться старым свидетельством (якорм) при трате, это может разоблачить время получения ноты: например, покажет, что вы не владели более свежими нотами. Поэтому кошелёк обновляет свидетельство включения: по мере появления новых блоков он может пересчитать путь в дереве, чтобы использовать самый свежий “якорь” (корень дерева Меркла). Проще говоря, кошелёк непрерывно подстраивает доказательство, что «моя нота есть в блокчейне вплоть до текущего состояния». Это называют синхронизацией ноты (syncing the note). Синхронизация важна и для приватности, и для удобства: узлы сети не обязаны хранить всю историю дерева, достаточно последнего корня, а пользователь не раскрывает лишней информации о том, когда он получил деньги.
Трата защищённой ноты. Когда вы хотите отправить полученную ранее ноту кому-то другому, происходит следующее: ваш кошелёк формирует транзакцию, где в части Spend указывает доказательство того, что вы имеете право потратить эту ноту. Это достигается с помощью криптографического доказательства с нулевым разглашением (Zero-Knowledge proof, конкретно zk-SNARK). Проще говоря, это математическое доказательство, которое не раскрывая деталей убеждает узлы сети в трёх вещах: (1) такая нота действительно существует в блокчейне (включена в дерево коммитментов), (2) вы владеете ключом, позволяющим её потратить (то есть, вы законный получатель), и (3) она ещё не была потрачена ранее. Первые два пункта обеспечивает как раз доказательство включения (с вашим обновлённым witness) и знание секретного ключа, а третий пункт достигается с помощью nullifier. Ваш кошелёк раскрывает nullifier ноты в транзакции. Nullifier – это, по сути, уникальный идентификатор, односторонне вычисленный из вашей ноты (выглядит как случайное число, не выдавая саму ноту). Узлы сети при проверке транзакции смотрят, не появлялся ли этот nullifier раньше. Если нет – значит, нота тратится впервые и всё в порядке; узлы добавляют этот nullifier в свой реестр. Если же такой nullifier уже есть в реестре, транзакцию отвергают как попытку двойной траты. Таким образом, nullifier выполняет роль «метки погашения» для ноты – один раз появился и больше не должен повторяться.

Итог текущего механизма: Zcash достигает приватности, скрывая получателя, отправителя и сумму (все эти данные зашифрованы), но при этом используя zk-SNARK доказательство и nullifier, чтобы сеть могла удостовериться в корректности транзакции (существует валидная нота, пользователь её не тратил прежде, баланс соблюдён и т.д.). Однако, как мы разобрали, это приводит к двум узким местам: кошельку сложно узнавать о новых нотах (он вынужден сканировать все транзакции), а узлам сложно бесконечно хранить и проверять список всех nullifier. В текущем виде, если представить миллионы пользователей и транзакций, нагрузка стала бы непосильной. Шон Боу предлагает решения для обоих проблем, особенно сфокусировавшись на nullifier.

Решения, предложенные Шоном Боу, и их преимущества

1. Уведомление о новых нотах вне блокчейна. Первый шаг к масштабируемости – сделать так, чтобы получатель не должен был перебирать весь блокчейн для поиска своей ноты. Шон отмечает, что всю “секретную” информацию лучше передавать получателю вне сети, напрямую. Это называют отказом от in-band (в цепочке) передачи секретов. Практически это может выглядеть так: отправитель и получатель устанавливают какой-то защищённый канал связи (например, через мессенджер, E2E-шифрованное сообщение, специализированный сервер и т.п.). Когда отправитель посылает платёж, он параллельно отправляет получателю необходимые данные ноты (ключ для расшифровки, вспомогательную информацию) напрямую. Такой подход в Zcash обсуждается как разные схемы “адресов нового типа” или “liberated payments” (освобождённые платежи). Главное, что кошельку получателя больше не придётся пытаться расшифровать каждую транзакцию – он сразу получит от отправителя подсказку, какая нота его, и сможет подтвердить её появление на цепочке другим способом. Преимущество: резкое снижение нагрузки при получении средств – новые пользователи и транзакции почти не увеличивают работу кошельков, поскольку нет необходимости в “поиске иголки в стоге сена” на блокчейне (отпадает необходимость пробовать расшифровать каждый выход). Это существенно улучшит время синхронизации легких кошельков и снизит требуемый трафик. (Шон упомянул эту проблему лишь кратко, отметив, что уже понятно, как её решать, и существует несколько подходов. Основной же упор он сделал на второе, более сложное препятствие.)

2. Устранение глобального списка nullifier (масштабирование проверки на двойную трату). Это центральная идея доклада Шона Боу. Он предложил перенести задачу проверки “не потраченности” ноты с узлов сети на самих пользователей, используя криптодоказательства. Вместо того чтобы каждый узел хранил все nullifier-ы, каждый кошелёк сам будет доказывать, что его нота ещё не была потрачена – и это доказательство будет включаться в транзакцию. Как этого достичь:

Генерация nullifier заранее. В текущем протоколе nullifier вычисляется из содержания ноты (например, из её коммитмента и скрытого параметра) и непредсказуем заранее. Шон предлагает изменить протокол так, чтобы nullifier можно было назначить заранее, ещё до создания самой ноты. Например, при инициализации кошелёк может сгенерировать сразу пачку случайных nullifier-идентификаторов, которые «зарезервирует» для будущих своих платежей. Эти идентификаторы не привязаны к конкретной ноте до поры, поэтому их можно сделать публичными без утраты приватности. Условно говоря, кошелёк заранее придумал несколько «номеров купюр», которые он когда-нибудь будет тратить.
Отмена требования глобальной уникальности. Ранее nullifier были строго уникальны по всему блокчейну, иначе был возможен так называемый “атака волшебное золото” (Faerie Gold) – когда злоумышленник посылает жертве две разные ноты, но с одинаковым nullifier, из-за чего потратить можно только одну (вторая станет непригодной, хотя получатель думал, что у него две). Новые подходы позволяют избежать этого без требования глобальной уникальности. Шон отмечает, что если применять улучшенные схемы получения нот (например, liberated addresses, где отправитель может отозвать средства, или когда получатель сам определяет параметры ноты), то такая атака либо не даёт выгоды атакующему, либо вообще предотвращается. Поэтому можно разрешить возможность совпадения nullifier по всему историческому диапазону, не полагаясь на них как на абсолютно уникальные отпечатки. Эта уступка убирает необходимость учитывать всю историю при генерации новых nullifier.
Oblivious-сервис для отслеживания nullifier. Итак, кошелёк имеет набор заготовленных nullifier. Теперь возникает задача: как доказать, что ни один из этих nullifier ещё не появлялся на блокчейне (т.е. нота не тратилась)? Чтобы не заставлять каждого пользователя самостоятельно скачивать и проверять всю историю блоков, Шон предлагает привлечь специальный сервис синхронизации. Этот сервис будет выполнять роль помощника: вы передаёте ему свой nullifier (или несколько) и просите отслеживать их в блокчейне. Важная деталь: сервис не требует доверия и ничего личного о вас не узнаёт. Его часто называют oblivious syncing service – условно, «слепой сервис синхронизации». Почему “слепой”? Потому что он не знает, какую конкретно ноту или пользователя обслуживает, он просто получает некоторый идентификатор (nullifier) и обновляет для него криптографическое доказательство отсутствия в блокчейне. В этом процессе вы не раскрываете никаких секретных ключей или сумм. Можно общаться с таким сервисом через анонимный канал (например, через сеть типа Tor или Mixnet), чтобы скрыть даже IP-адрес. Более того, сам nullifier – это случайная строка, он не привязан к данным ноты, и увидеть его заранее не даёт информации злоумышленнику. Даже если сервис потом увидит этот nullifier в блокчейне (когда вы потратите ноту), он не сможет сказать, когда вы начали его отслеживать или какую именно ноту он представлял.
Непрерывное доказательство отсутствия. Сервис синхронизации будет вести для каждого вашего nullifier специальное доказательство непоявления (non-inclusion proof) во всех блоках до текущего момента. Это похоже на свидетельство, только наоборот: оно доказывает, что «в блоках X до Y ни разу не встречается идентификатор N». Каждый раз, когда выходит новый блок, сервис обновляет доказательство: проверяет, не появился ли там ваш nullifier, и обновляет криптографический аккумулятор. Таким образом, кошелёк “пьёт из пожарного шланга” не сам – за него это делает сторонний сервис, отфильтровывая только нужную информацию. Фактически, такой сервис похож на уже существующий LightwalletD сервер (легковесный демон кошелька) – сейчас он помогает мобильным кошелькам синхронизировать коммитменты нот, а в будущем мог бы помогать ещё и с nullifier.
Формирование транзакции с доказательством. Когда вы решите потратить ноту, ваш кошелёк берёт у сервиса актуальное доказательство, что соответствующий ей nullifier не появлялся в блокчейне после создания ноты (важное уточнение: достаточно проверять после блока, где нота была зафиксирована, ведь до её появления nullifier мог быть кем-то использован только в гипотетической атаке, которую мы решили не учитывать). Кошелёк объединяет: (а) обычное zk-доказательство корректности (как раньше) и (б) доказательство «nullifier не встречался». Дополнительно в транзакции, как обычно, включается сам nullifier. Теперь узлам сети при проверке транзакции нужно сделать следующее: проверить криптографические доказательства и убедиться, что в этом же блоке нет другого такого же nullifier, чтобы исключить двойную трату в одном блоке. Им больше не нужно держать весь список старых nullifier – защита от повторной траты в прошлом обеспечивается вашим доказательство. Проще говоря, ответственность за удостоверение уникальности nullifier переносится с долгосрочного хранения на проверку присланного доказательства.

Преимущества подхода с nullifier-доказательствами:

Масштабируемость узлов. Валидаторы (узлы) больше не хранят бесконечный реестр всех nullifier. Это устраняет один из самых тяжёлых элементов состояния блокчейна. Узлы хранят лишь последние несколько блоков nullifier для проверки внутри блока и небольшой “зазор” (например, 10 последних блоков, чтобы ловить коллизии, если транзакция чуть задержалась). Таким образом, требуемое хранимое состояние становится практически постоянным по размеру, даже если система будет работать много лет. Это огромный плюс для масштабирования – узлы смогут обрабатывать гораздо больше транзакций, не упираясь в память или диск.
Распределение нагрузки на пользователей. Теперь каждая защищённая транзакция несёт в себе доказательство от пользователя. Создание этого доказательства – задача не тривиальная, но её выполняет сторонний сервис, а не сами узлы или кошелёк на слабом устройстве. По сути, нагрузка по поддержанию актуальности доказательств распределяется между всеми пользователями: каждый заботится о своих нотах. Нет центрального узкого места, где сходятся все проверки – сеть только верифицирует готовые доказательства (а современные zk-SNARK проверяются очень быстро). Это позволяет системе расти в пользователях без увеличения непропорциональной нагрузки на каждый узел.
Приватность сохраняется. Критично, что новый метод не раскрывает лишней информации. Nullifier и сейчас публикуются при трате; в новом подходе мы лишь допускаем их более раннее раскрытие сервису, но сделали их независимыми от конкретных данных ноты. Сервис синхронизации не узнаёт, когда и где ваша нота появилась, он просто знает, что такой идентификатор пока не встречался. Если даже через месяц он увидит этот nullifier на цепи, он не сможет определить, была ли ваша нота создана месяц назад или вчера – потому что вы скрыли нижнюю границу проверки (базовый блок, от которого строилось доказательство). Более того, можно пользоваться несколькими сервисами одновременно, чтобы ни у одного не было полной картины (или менять их). В крайнем случае, вы можете сами запустить такой сервис для себя или доверять публичным – они не способны скомпрометировать ваши данные, могут только отказать в обслуживании (что решается переключением на резервный).
Малое влияние на скорость транзакций. Хотя добавляется новое доказательство, Шон отмечает, что это не сделает транзакции заметно “тяжелее” для пользователя. Современные zk-доказательства эффективны, а большую часть вычислений можно выполнить заранее. Например, доказательство непоявления nullifier можно обновлять постепенно (сервис это делает), и конечный кусочек композиции доказательств для включения в транзакцию очень компактный. Верификация же этих доказательств для узлов практически мгновенная (сотни микросекунд), то есть пропускная способность сети сильно не пострадает.
Новые возможности. Интересно, что такой дизайн открывает дорогу к новым фишкам. Например, nullifier можно менять при форках сети. Сейчас, если случится разделение сети (форк), одна и та же нота при трате выдаст одинаковый nullifier на обеих цепях, что может связать вашу активность. В новой схеме можно заложить правило: после определённого блока (точки форка) вычисление nullifier меняется, и доказательство непоявления учитывает это. В результате на разных цепях один и тот же “коин” будет иметь разные nullifier, и их невозможно сопоставить; при этом вы не раскрываете старый nullifier – доказательство “переключается” на лету. Также Шон отмечает, что ноты и nullifier начинают походить друг на друга по природе – оба являются, по сути, коммитментами (один — на существование ноты, другой — на факт траты). Возможно, их удастся объединить в единый механизм, упростив протокол. Все эти возможности становятся доступны благодаря гибкости новой системы доказательств.

Потенциальные проблемы и вызовы реализации

Концепции звучат многообещающе, но их внедрение связано с вызовами. Рассмотрим возможные сложности:

Надёжность сервиса синхронизации. Предполагается существование одного или нескольких oblivious-серверов, которые будут заниматься обновлением доказательств для пользователей. Нужно обеспечить, чтобы эти сервисы были доступны и корректны. Хотя им не нужно доверять приватные данные, их отказ может задержать возможность траты (если сервис недоступен, пользователь не получит обновлённое доказательство для транзакции). Решения: иметь много независимых сервисов (как сегодня много узлов LightwalletD обслуживают кошельки) и возможность быстро переключаться между ними. Также, если сервис вдруг начнёт отправлять неверные доказательства, кошелёк это обнаружит (транзакцию не примут), и пользователь сменит источник. В крайнем случае, можно запустить полный узел, который сам поддерживает все необходимые свидететельства (правда, тогда опять придётся скачивать всю цепочку, что не оптимально для легкого клиента). Этот момент – скорее вопрос инфраструктуры: необходимо развивать экосистему таких “вспомогательных” серверов.
Устаревание доказательства до включения в блок. После создания транзакции с доказательством непоявления nullifier, могут добавиться новые блоки, пока ваша транзакция не попадёт в цепочку. Теоретически, доказательство станет неполным, ведь появилось несколько блоков, не учтённых в нём. Шон предлагает практичное решение: дать узлам небольшой «запас по времени», например, считать доказательство действительным, если с момента его формирования прошло не более N блоков. Узлы при проверке транзакции сами удостоверятся, что за последние N блоков такой nullifier не появлялся (эти несколько последних блоков они могут хранить и проверять напрямую). N может быть небольшим (скажем, 10 блоков), вероятность, что транзакция будет ждать дольше, мала. Даже если это произойдёт, майнеры могут обновить доказательство сами: используя технику рекурсивных SNARK, они способны удлинить цепочку доказательства до текущего блока. Это усложняет реализацию, но гарантирует, что транзакции не “протухают” из-за скорости блока.
Изменение протокола nullifier. Чтобы nullifier можно было генерировать заранее, придётся изменить формат их вычисления. Сейчас они зависят от данных ноты (в Orchard-эпохе nullifier включает в себя часть “ρ” от ноты и коммитмент). Убрать зависимость от непредсказуемых компонентов – нетривиальная задача, ведь надо сохранить безопасность. Мы снимаем требование уникальности и вместо этого полагаемся на доказательства уникальности, так что прежние меры предосторожности (как включение коммитмента в хеш nullifier для уникальности) можно отменить. Но надо убедиться, что не возникнет новых уязвимостей, например, связанных с генерацией nullifier. Шон уверен, что атака “волшебное золото” предотвращается иными средствами или становится бессмысленной, однако реализация должна это учесть. Возможно, понадобятся изменения в ZIP (протокол Zcash), обсуждения в сообществе и аудит криптографии.
Сложность реализации и переходный период. Внедрить эти изменения в существующую криптовалюту – большой проект. Необходимо разработать и протестировать новые схемы адресов с обменом сообщениями вне цепи (для передачи нот), реализовать криптографические аккумуляторы для nullifier и рекурсивные доказательства, изменить консенсус-протокол (правила проверки транзакций). Вероятно, это будет поэтапно через крупные обновления сети (network upgrades). Будет переходный период, когда старые ноты ещё тратятся по старым правилам, а новые – по новым. Нужно аккуратно продумать обратную совместимость, чтобы пользователи не потеряли средства и могли мигрировать на новую систему постепенно.
Доступность данных и доказуемость. Если узлы больше не хранят полный список nullifier, вся уверенность в отсутствии двойной траты основана на SNARK-доказательствах. SNARK – чрезвычайно надёжный инструмент при правильной параметризации, но разработчикам придётся позаботиться о надёжности самого аккумулятора. Например, можно использовать криптографический набор (accumulator), который позволяет эффективно проверять непринадлежность элемента множеству. Один из вариантов – использовать двоичное дерево Меркла или его разновидность. Шон в конце упомянул, что написал черновик (HackMD) с математическим эскизом сравнения разных способов (спарс-дерево vs. набор). Важно выбрать такой подход, чтобы доказательства были компактны и быстро проверялись, а вероятность ошибок или недоступности данных была минимальна.
Многопользовательские сценарии. В новой схеме возможны углы, которые надо учесть. Например, что если два пользователя случайно выбрали один nullifier заранее? В старом протоколе такое исключалось криптографически, а тут теоретически возможно (хоть вероятность и мизерная, как столкновение хешей). Решение простое: в худшем случае, один из них попробует потратить и получит отказ (nullifier уже в блоке тем другим пользователем). Это не нарушит безопасность, но пользователь должен понимать ситуацию (аналогично коллизии адресов, крайне редкой). Можно увеличить длину nullifier или вводить доп. источник уникальности (например, ID самого адреса в их вычислении), чтобы исключить даже гипотетические совпадения. Ещё пример: двойная трата в одном блоке. Узлы легко отсеют её, сравнив nullifier в пакете транзакций блока. Но надо убедиться, что майнер не сможет умышленно вставить две траты с одним nullifier в блок, обходя доказательство (вероятно, нет, т.к. доказательство у одной или обеих будет ложным).

В целом, реализация потребует серьёзной работы и исследований, но пока не видно непреодолимых преград. Многие проблемы можно решить инженерно, установив разумные допущения (как “окно” в несколько блоков для актуальности доказательства) или полагаясь на крайне низкую вероятность событий (случайные совпадения). Шон Боу подчеркнул, что эти идеи свежие и будут требовать экспериментирования, но потенциал огромен.

Почему эти решения надежны и перспективны

Сохранение приватности на первом месте. Предлагаемые изменения не ослабляют конфиденциальность пользователей, а в чём-то даже улучшают. Убирая необходимость сканировать весь блокчейн, мы устраняем потенциальный канал утечки, при котором, например, сервер LightwalletD мог видеть, какие блоки запрашивает кошелёк. Теперь получатель сразу узнает о платеже от отправителя и может проверить включение ноты без полного просмотра цепи. В части nullifier мы тщательно избежали ситуации, при которой раннее раскрытие nullifier могло бы выдать связь с конкретной нотой. За счёт генерации nullifier заранее и случайности их выбора противник не сможет отличить, выпустили вы nullifier “в свет” или нет, пока вы его не потратите. Даже сервис синхронизации, получив ваш nullifier, не узнает ничего личного. Таким образом, приватность остаётся столь же сильной, как и в текущем Zcash, а некоторые экзотические риски (например, привязка трат на разных форках) смягчаются новым подходом.

Опора на проверенные криптографические методы. В своих решениях Шон объединяет известные техники: доказательства с нулевым разглашением (SNARK), криптографические аккумуляторы для множеств и рекурсивные доказательства (когда одно доказательство расширяет другое). Все эти инструменты уже исследованы. Сам Шон Боу – один из авторов протоколa Halo (рекурсивные SNARK без доверенной установки), который уже используется в Zcash. То есть команда хорошо понимает технологию рекурсии и может её применить для обновления доказательств на лету. Аккумуляторы непринадлежности (non-membership proofs) – тоже не новая концепция; существуют конструкции на основе RSA, Merkle-деревьев, políномов. Задача сводится к их эффективному внедрению. Шон упоминал, что набросал математическое обоснование, почему выбранный подход лучше, чем простое «расшардивание» nullifier по дереву. Например, прямая шардинг-схема предлагалась ранее, но она всё равно заставляла держать историю в каждой “шарде” и была очень сложной. Новый же метод элегантнее: доказательство вместо хранения. В криптографии смена парадигмы “хранить всё” на “доказывать по требованию” – известный путь к масштабированию (примеры: статeless клиенты, FlyClient и др.). Поэтому с точки зрения теории всё выглядит надежно, остаётся реализовать на практике.

Значительный выигрыш в масштабируемости. Если эти идеи воплотить, Zcash сможет поддерживать на порядке больше пользователей и транзакций. Снятие нагрузки сканирования позволит мобильным и лёгким кошелькам работать быстрее и стабильнее, даже если ежедневно будут тысячи новых транзакций. Устранение глобального списка nullifier означает, что добавление новых пользователей почти не увеличивает требования к узлам. Валидация транзакций останется быстрой, а объём хранимых данных – контролируемым. Это прокладывает путь к тому, чтобы Zcash мог стать массово используемой системой платежей с приватностью, без угрозы “захлебнуться” от собственного успеха. Шон прямо говорит, что целью исследований является возможность “масштабировать до большого числа пользователей и платежей без компромисса приватности”.

Учёт специфики приватных валют. Предложенные решения родились из уникальных требований Zcash: совместить приватность и масштабность. Вопрос масштабирования решают многие блокчейны, но у них нет условия хранить данные в тайне. Например, биткоин или эфир могут шардировать или использовать лёгкие клиенты без приватности. Zcash же нуждается в особых методах. Шон отмечает, что их команда идёт по неизведанному пути, который другие проекты могли не рассматривать, потому что у других нет таких жёстких ограничений по приватности. Это значит, что Zcash разрабатывает уникальные инновации, и хотя это сложнее, но если получится – решения будут очень перспективными именно для приватных криптовалют. Успешное внедрение может послужить моделью для других приватных протоколов (например, Monero, Penumbra и др.), то есть Zcash вновь станет первопроходцем, как это было с внедрением zk-SNARK.

Практичность и реальный прогресс. Наконец, важный аргумент – реализуемость. Шон Боу сообщил, что эти идеи у него сформировались недавно, но части их уже обсуждались в сообществе и находятся в русле развития Zcash. Например, отказ от сканирования (out-of-band получение ключей) – активно разрабатывается (ZIP-ств предложений по улучшению light-клиентов). Рекурсивные доказательства уже интегрированы (Halo 2 в обновлении Orchard). То есть строительные блоки постепенно складываются. Новый проект, безусловно, потребует времени, но он не выглядит невозможным. Боу подчеркнул, что добавление доказательства непоявления почти не влияет на скорость создания транзакции на устройстве – для пользователя всё останется примерно так же по времени и ресурсам. Это значит, что изменения смогут работать на мобильных телефонах и не потребуют сверхмощных устройств. Надёжность системы не снижается: если криптография верна, сеть продолжит отсеивать мошеннические транзакции с той же строгостью, что и раньше (даже большей, ведь проверка станет формальной через доказательство). Всё это делает предложенные решения реальными кандидатами для будущего обновления Zcash.

Вывод. Доклад Шона Боу на ZconVI предложил свежий взгляд на масштабируемость Zcash. Ключевое инсайт – использовать больше криптографии вместо хранения и пересылки больших объёмов данных. Пользователи будут получать необходимые данные напрямую и сами предоставлять доказательства корректности, а узлы просто проверять их. Эти идеи требуют серьёзной проработки, но при успешной реализации Zcash сможет расти многократно, сохраняя уникальные свойства приватности. Такой путь выглядит надёжным и перспективным, потому что опирается на математически строгие гарантии вместо доверия или наращивания ресурсов. Zcash когда-то стал первым практичным применением zk-SNARK; возможно, вскоре он станет и первым по-настоящему масштабируемым приватным блокчейном, если идеи Боу воплотятся в жизнь.

Метки: ZconVI, криптография Zcash

Все новости про Zcash в социальной сети «X» (бывший Twitter) | Интересные видео про Zcash на YouTube

Вы можете поддержать автора проекта pro.zcash:
(для отправки доната на данный адрес требуется кошелёк с функционалом экранированных транзакций)

Комментировать статью: Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Декодирование истории первой крипто-войны

Масштабируемость Zcash: объяснение доклада Шона Боу (ZconVI)