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

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

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

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

Существует продвинутая версия данной статьи.

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

Простое объяснение для школьника

Как есть сейчас: Представь, что в блокчейне Zcash каждая транзакция – это как секретное письмо. Отправитель кладёт на доску (блокчейн) конверт с зашифрованной запиской, чтобы получатель смог её там найти и прочитать. Каждый, кто запускает кошелёк, вынужден просматривать каждый конверт на доске и пытаться его открыть своим ключом, чтобы понять, для него ли сообщение. Это очень медленно и тяжело: если доска заполнена тысячами таких конвертов, кошельку приходится перебрать их все. Кроме того, когда кто-то тратит свою монету (shielded-ноту), он оставляет на доске её уникальный номер (на языке Zcash – Nullifier, нулифаер) – что-то вроде зачеркнутого серийного номера монеты, чтобы никто не мог потратить ту же самую монету повторно. С каждым новым платежом таких номеров накапливается всё больше, и валидаторы (узлы сети) должны хранить полный список всех когда-либо потраченных номеров, чтобы проверять новые транзакции на двойную трату. Представь тетрадь, в которую учитель записывает каждый использованный код – со временем она разрастается до тысяч страниц. Это текущий дизайн: надёжный, но со временем всё менее удобный и быстрый.

Что предложил Шон Боу: изменить правила так, чтобы секретные записки не хранились на доске, и учителям не пришлось держать огромную тетрадь с номерами. Вместо этого отправитель передаёт записку получателю напрямую (например, шёпотом или по приватному каналу связи), минуя доску. А чтобы убедить всех в сети, что его монета не потрачена раньше, владелец монеты заранее получает свидетельство от особого проверяющего, что уникальный номер его монеты ещё не встречался. Это свидетельство (криптографическое доказательство) он показывает всем вместе с транзакцией. Проще говоря, Шон предлагает: «Не складывать все секреты в блокчейн, а использовать хитрую математику (доказательства), чтобы сеть верила, что всё правильно, не храня каждый раз всю информацию». Такой подход убирает лишние данные из блокчейна, разгружает узлы и позволяет обрабатывать гораздо больше транзакций без потери приватности.

Какие данные перестанут записываться в блокчейне и почему

1. Зашифрованные детали платежа (ноты и мемо): В текущем Zcash каждая выходная нота (по сути, «скрытая монета») записывается на блокчейне в зашифрованном виде – это и есть тот «конверт» с секретом для получателя. Он включает нужную информацию для траты: ключ получателя, сумму и поле заметки (memo). Такой подход называется встроенное (in-band) распределение секрета. Шон Боу указывает, что этот механизм нужно убрать: кошельки должны узнавать о поступивших средствах вне блокчейна. Причина – масштабируемость: постоянно рассылая и храня на каждом узле шифрованные сообщения для получателей, мы заставляем каждый кошелёк читать все сообщения, что не масштабируется при большом числе пользователей. Если эти данные не записывать в блоке, размер каждой транзакции резко уменьшится. Например, одно зашифрованное выходное сообщение с мему полем занимает около 692 байт (Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub). Если исключить его из блока, оставив лишь минимальный “отпечаток” (коммитмент) ноты ~180 байт, то мы экономим сотни байт на каждый вывод. Таким образом, блокчейн перестанет хранить зашифрованные ноты и заметки, и получатели будут получать эти данные через другие каналы. Это разгрузит цепочку и уменьшит трафик синхронизации кошельков (Working on Scalability — Technology — Zcash Community Forum).

2. Полный список Nullifier’ов (идентификаторов потраченных нот): Сейчас узлы хранят все когда-либо появившиеся nullifier’ы, чтобы убедиться, что новый nullifier не дублирует старый (не происходит двойной траты). Со временем это растущий объём данных, который никогда не уменьшается, ведь история трат постоянно пополняется. Предложение заключается в том, что блокчейн больше не будет требовать от каждого узла хранить всю историю nullifier’ов. Вместо этого ответственность за проверку уникальности nullifier переносится на отправителя транзакции, точнее – на доказательство, которое он включает. Каждый кошелёк при трате будет доказывать, что его nullifier не встречался ранее, с помощью компактного криптодоказательства. Узлам сети тогда не нужно держать локальную базу всех nullifier’ов – им достаточно проверить само доказательство и убедиться, что в пределах текущего блока nullifier уникален (что легко сделать, просто сравнив со списком в этом блоке). В результате какие данные можно не хранить? Долговременный глобальный список всех потраченных идентификаторов. Достаточно записать в блок только новые nullifier’ы текущих транзакций (для будущих проверок) и, возможно, поддерживать небольшой агрегат (например, корень дерева или аккумулятор) для проверки доказательств. Похожий подход используют в проекте Bitcoin Utreexo: он заменяет громоздкую базу UTXO крошечным криптографическим аккумулятором, перенося бóльшую часть работы по хранению доказательств существования монет на владельцев этих монет (Utreexo | A dynamic accumulator for Bitcoin state — MIT Digital Currency Initiative). В Utreexo миллионы выходов можно представить всего килобайтом данных, а каждый владелец хранит небольшое доказательство и при трате предоставляет его, доказывая, что его монета действительно существует и не потрачена (Utreexo | A dynamic accumulator for Bitcoin state — MIT Digital Currency Initiative). Аналогично, в предложении Боу узлы уже не обязаны таскать с собой “тетрадь” всех nullifier’ов – вместо этого траты сопровождаются кратким сертификатом-«справкой», что данный идентификатор никогда прежде не появлялся.

Насколько увеличится пропускная способность сети

Удаление лишних данных из каждой транзакции сильно увеличивает вместимость блоков для полезных операций. Если сегодня полностью приватная транзакция (например, в пуле Orchard) может занимать около 9 килобайт (Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub), то по новым предложениям её размер может сократиться до единиц или сотен байт. Оценки разработчиков показывают, что при вынесении всех выходных данных «вне цепи» снижение размера транзакции может достигать 95–98% (Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub). Например, вместо ~9160 байт, транзакция могла бы занимать порядка 150–300 байт – то есть блок фиксированного размера сможет вместить в десятки раз больше транзакций, чем сейчас. В пересчёте на пропускную способность это означает потенциальный рост с нынешних условных ~200–300 транзакций за блок до нескольких тысяч и более.

Важно, что здесь нет жёсткого теоретического предела по числу транзакций с точки зрения криптографии. Если каждую транзакцию сжимать криптодоказательством, то блок может содержать очень много платежей – сколько позволит размер блока и мощность узлов. В крайнем случае, используя рекурсивные доказательства (подход Halo) можно даже объединять множество операций в одно доказательство (Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub) (Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub), при котором размер данных на блокчейне растёт незначительно с увеличением транзакций. При таком подходе проверка тысячи платежей может свестись к проверке одного краткого SNARK-доказательства, то есть валидация масштабируется сублинейно (Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub). Таким образом, пропускная способность сети может вырасти на порядки без ущерба для безопасности. Единственные ограничения будут связаны с физическими параметрами – пропускной способностью сети интернет между узлами и допустимым размером блока (который можно корректировать со временем). В текущих предложениях упор делается на резкое сокращение “веса” транзакций, что уже само по себе даст существенный рост TPS (транзакций в секунду) при тех же параметрах блока.

Влияние на скорость подтверждения транзакций

Более быстрый механизм верификации. С точки зрения узлов, новые схемы снижают объём работы при каждом новом блоке. Сейчас узлу приходится хранить большой список nullifier’ов и проверять для каждой входящей транзакции, не находится ли её nullifier в этом списке – иначе это двойная трата. При больших списках это требует либо много памяти, либо дополнительных операций поиска по диску. В предложенной модели узел вместо этого проверяет криптографическое доказательство, которое подтвердит, что данный nullifier отсутствует в предыдущей истории. Проверка zk-SNARK-доказательства происходит очень быстро (порядок нескольких миллисекунд) и не зависит от размера истории – даже если до этого было потрачено миллион нот, доказательство всё равно компактное и проверяется за постоянное время (Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub). Таким образом, нагрузка смещается с IO-операций и хранения данных на чисто вычислительную проверку коротких математических доказательств. Это может ускорить распространение блоков по сети: вместо передачи и обработки громоздких списков и шифротекстов, узлы обмениваются меньшим объёмом данных и тратят меньше времени на их проверку. В случае использования рекурсивных агрегатов (когда один доказатель покрывает множество транзакций), затраты на проверку блока вообще становятся практически постоянными независимо от числа транзакций (Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub) – узлу достаточно один раз проверить общее доказательство целого блока.

Меньше задержек в очереди транзакций. Увеличение пропускной способности означает, что транзакции будут реже задерживаться в мемпуле из-за переполнения блока. Иными словами, при высоком спросе сеть сможет вместить больше операций в единицу времени, и пользователям не придётся ждать несколько блоков до включения их транзакции. Это косвенно снижает среднее время подтверждения: если сегодня при перегрузке можно ожидать, к примеру, 2–3 блока, то в новой модели даже при большом количестве пользователей большинство транзакций попадут уже в ближайший блок. Время генерации блока (блок-тайм) при этом остаётся прежним (у Zcash ~75 секунд), но вероятность получить подтверждение именно в следующем блоке возрастает. Благодаря этому пользователь с большей вероятностью увидит подтверждение своей транзакции уже через ~1 минуту, а не через 5 или 10, как могло бы быть в пиковые периоды ранее.

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

Как пользователи на практике почувствуют изменения

Быстрая и лёгкая синхронизация кошельков. Пользователю больше не нужно ждать долгую загрузку, когда он устанавливает или открывает свой кошелёк. В классическом Zcash при запуске кошелёк должен просканировать всю цепочку блоков (или существенную её часть) в поисках принадлежащих вам платежей, попутно обновляя доказательства для каждой полученной ноты. В новой модели кошелёк избавляется от этой рутины: всю тяжёлую работу по отслеживанию новых нот и поддержанию актуальных свидетельств берёт на себя специальный сервис синхронизации (о нём ниже), либо сам факт, что зашифрованных данных в блокчейне больше нет. На практике это означает, что мобильные и десктопные кошельки будут работать заметно быстрее. Они меньше нагружают процессор и батарею, тратят меньше трафика (Working on Scalability — Technology — Zcash Community Forum), так как не скачивают мегабайты шифротекстов для проверки. Как отметил один из разработчиков, убрав необходимость постоянно сканировать блокчейн, можно делать библиотеки для Zcash, работающие почти как API PayPal – быстрое получение уведомлений о платеже без сложной фоновой обработки (Working on Scalability — Technology — Zcash Community Forum). Проще говоря, пользоваться приватными платежами станет так же удобно, как привычными банковскими приложениями, без ущерба для приватности.

Меньшие комиссии (fees). Поскольку каждая транзакция “худеет” в байтах, плата за неё тоже снижается. В Zcash (как и в Биткоине) комиссии обычно рассчитываются на основе размера транзакции в байтах. Если транзакция занимает гораздо меньше места, за неё можно заплатить гораздо меньшую комиссию, чтобы её включили в блок, — и при этом майнеры поместят больше операций в каждый блок. Кроме того, повышение пропускной способности снижает конкуренцию за место в блоке: даже при наплыве транзакций средняя комиссия не должна резко расти, потому что доступно больше свободного места. В идеальном случае, со всеми внедрёнными улучшениями, пользователи будут платить меньше за перевод, а получить подтверждение смогут быстрее. Структура комиссий как таковая (рыночный принцип оплаты за байты данных) останется той же, но за счёт оптимизаций пользователи практически всегда выигрывают: либо транзакция проходит сразу без повышенной комиссии, либо можно установить минимальную плату и всё равно попасть в блок.

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

Потенциальные риски и сложности реализации

Криптографическая новизна и надежность. Предложения Боу основаны на сложных криптографических примитивах: zk-SNARK доказательства непоявления (невключения) nullifier’а, новые аккумуляторы состояния, рекурсивные схемы Halo и т.д. Любая новая криптографическая схема несёт риск ошибок или уязвимостей. Требуется тщательный аудит и формальная проверка, чтобы убедиться, что злоумышленник не сможет сфальсифицировать доказательство и, например, потратить одну и ту же ноту дважды, обходя защиту. Кроме того, использование новых SNARK’ов увеличивает сложность транзакций: отправителю придётся генерировать более сложные доказательства, чем раньше, объединяя доказательство существования ноты и доказательство непотрачености. Хотя по заявлениям разработчиков создание такого объединённого доказательства довольно эффективно, это всё же более требовательно к вычислениям на стороне клиента, чем текущие схемы.

Отказ от встроенного распределения секретов. Передача данных о платеже вне блокчейна означает, что необходима надёжная инфраструктура доставки этих сообщений. Если, к примеру, отправитель попытается отправить вам шифрованную ноту через специальный сервер, а этот сервер будет недоступен, то возникает риск, что получатель не получит свои деньги вовремя (или вообще потеряет возможность их потратить, пока не получит секрет). Система должна предусмотреть механизмы повторной передачи или дублирования через несколько узлов, чтобы исключить точку отказа. Ещё один нюанс – необходимо убедиться, что такая доставка не компрометирует приватность. Боу предлагает использовать обливиозные сервисы синхронизации – специальные узлы, которые получают и пересылают зашифрованные данные, ничего о них не зная. Реализация такой сети (например, на основе mixnet или анонимных брокеров сообщений) – сама по себе нетривиальная задача. Она добавляет новый слой в экосистему: помимо блокчейна, появляется сеть ретрансляции секретных записок. Необходимо будет убедить пользователей в её надежности. В случае компрометации канала (например, атаки на микснет) злоумышленник теоретически мог бы попытаться отслеживать, кто кому отправляет зашифрованные ноты (метаданные коммуникаций). Поэтому защита метаданных и избыточность каналов – важные аспекты при развёртывании этого решения.

Сложность перехода и совместимости. Масштабные изменения потребуют новой версии протокола. Необходимо реализовать новые правила параллельно со старым режимом на время переходного периода. Например, возможно, какое-то время будут сосуществовать старые транзакции с встраиваемыми шифротекстами и новые – без них. Нужна поддержка в кошельках: отправителям придётся обновить логику, чтобы уметь отсылать ноты адресатам напрямую (возможно, обмениваться дополнительными ключами или URL сервера). Получателям, в идеале, нужно быть постоянно онлайн или полагаться на сторонний сервер, который будет буферизовать для них сообщения, когда они офлайн. Всё это увеличивает сложность пользовательских приложений. Разработчикам кошельков предстоит интегрировать новые библиотеки, настроить взаимодействие с сервисами синхронизации и отладить новые протоколы – задача, требующая времени и ресурсов.

Нагрузка на пользователей и новые роли. В схеме со stateless-валидаторами часть ответственности переходит к самим пользователям. Теперь кошелёк должен не только хранить ваши приватные ключи, но и поддерживать свидетельства непротраченности для ваших нот. В простейшем варианте это означает, что ваш кошелёк (или доверенный сервис) должен постоянно отслеживать новые блоки и обновлять криптографическое доказательство, подтверждающее, что ваш nullifier ещё не появлялся. Делать это полностью самостоятельно для обычного пользователя нереально – пришлось бы запускать процесс, который скачивает все блоки (эффект «пить из пожарного шланга», как выразился Боу). Поэтому вводится роль сервиса синхронизации (oblivious syncing service). Этот сервис берёт на себя тяжёлую работу: получает от кошелька задание (например, “вот мой nullifier, докажи, что до блока №1000000 его не было”), пролистывает блокчейн, обновляет ваше доказательство и отправляет его обратно. Сервису не нужно доверять – благодаря нулевому разглашению он не узнает ничего о ваших средствах и не сможет подтасовать доказательство (кошелёк проверит все криптографические подписи). Однако, появление такого элемента инфраструктуры – это новый потенциал для сбоев: если сервис недоступен, пользователь не сможет получить обновлённое свидетельство и, соответственно, потратить монету, пока не найдёт доступный сервис. В идеале, должно быть несколько независимых сервисов и возможность для технически подкованных пользователей запускать свои. Но реализация протокола взаимодействия кошелька и сервиса – дополнительная сложность. Нужно стандартизировать формат запросов и ответов, обеспечить безопасность (например, общение через зашифрованный канал, анонимный исходящий адрес пользователя и пр.). Также возрастает роль легковых клиентов (light wallet servers) – по сути, существующие “lightwalletd” уже выполняют часть этих функций для обычных доказательств включения нот, теперь им придётся расшириться и для доказательств отсутствия nullifier’ов. Всё это требует скоординированных усилий.

Вывод: Предложения Шона Боу представляют собой большой шаг вперёд для масштабируемости Zcash. Они устраняют фундаментальные узкие места текущего протокола – хранение и распространение лишних данных – с помощью элегантных криптографических решений. Убирая из блокчейна шифротексты и огромный список исторических nullifier’ов, Zcash сможет обслуживать на порядки больше пользователей, сохраняя свою главную фишку – финансовую приватность. При этом транзакции станут легче, быстрее и дешевле в обработке. Конечно, путь к реализации непрост: потребуется внедрить новые технологии и убедиться в их безопасности. Но если эти изменения будут успешно осуществлены, пользователи ощутят существенные улучшения: мгновенные и приватные платежи без долгого ожидания и с минимальными комиссиями, а сеть будет готова к росту нагрузки в будущем (Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub) (Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub). Такая эволюция протокола покажет, что даже полностью зашифрованный блокчейн может масштабироваться при грамотном использовании криптографии и инженерных решений, открывая дорогу к массовому применению защищённых цифровых денег.

Источники:

Sean Bowe. Zcash Scalability – Talk at Zcon6 (2025). Отрывок стенограммы о необходимости убрать встроенное распределение секретов и хранение всех nullifier.
Daira Hopwood et al. Shielded transaction aggregates – Zcash GitHub Issue #4946 (2023). Оценки размера транзакций и экономии от вынесения выходов вне цепи (Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub) (Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub); влияние на проверку блоков (Shielded transaction aggregates · Issue #4946 · zcash/zcash · GitHub).
Zcash Community Forum. “Working on Scalability” discussion (2023) – комментарии о проблеме сканирования цепи и идее передачи нот out-of-band (Working on Scalability — Technology — Zcash Community Forum) (Working on Scalability — Technology — Zcash Community Forum).
Thaddeus Dryja. Utreexo: A dynamic accumulator for Bitcoin state – MIT DCI (2019). Пояснение концепции сжатия UTXO-набора и сдвига хранения доказательств на владельцев (Utreexo | A dynamic accumulator for Bitcoin state — MIT Digital Currency Initiative).
Sean Bowe – Zcash Scalability, Zcon6 (стенограмма). Описание «oblivious syncing service» для обновления свидетельств без доверия.

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

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

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

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

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

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