Шифрование данных и информации: выбор протоколов для Web3
Публичный блокчейн по умолчанию раскрывает больше, чем хотелось бы приложению с приватными данными. Транзакция может не показывать имя пользователя, но её входы, выходы, время и связи между адресами остаются наблюдаемыми.
Шифрование данных и информации здесь не сводится к выбору алгоритма: нужно определить, что именно скрывать, кому разрешать вычисления и как проверять результат без раскрытия исходных данных.
В Web3 для этого используют разные криптографические примитивы. ZK-доказательства подтверждают корректность утверждения, не раскрывая секрет. FHE позволяет выполнять вычисления над шифротекстом. MPC распределяет вычисление или контроль над ключом между участниками. Пороговое шифрование усложняет единоличное раскрытие данных. Эти методы решают разные задачи; сравнивать их по одному показателю — например, скорости — бессмысленно.
От zk-SNARKs к FHE: разные модели приватности
Доказательство с нулевым разглашением отвечает на вопрос: можно ли проверить факт, не получая сами данные? Например, контракту может быть достаточно узнать, что пользователь удовлетворяет условию, не раскрывая его баланс или личные сведения. Проверяющая сторона получает доказательство и проверяет его по заданному протоколу.
Практические конструкции zk-SNARKs появились в 2013 году. Их сильная сторона — компактное доказательство и быстрая проверка. В материалах по теме приводится оценка генерации доказательства менее чем за 100 мс; конкретное время зависит от схемы, размера вычисления, оборудования и реализации. Это не означает, что любое приложение получит такую задержку без оптимизации. Генерация доказательства может быть существенно дороже его проверки, а ограничение вычисления в арифметическую схему само по себе требует инженерной работы.
У FHE другая цель. Полностью гомоморфное шифрование позволяет вычислять над зашифрованными данными, не расшифровывая их в ходе обработки. Идея стала практически реализуемой в 2009 году, но практичность не равна дешевизне. Для ряда операций FHE требует заметного вычислительного оверхеда и предъявляет требования к памяти и ускорителям. В имеющейся оценке задержка операции на ускорителях 2026 года составляет 10–30 секунд, а стоимость вычислений — в 5–10 раз выше ZK-подхода. Эти цифры нельзя переносить на любую схему и любой бенчмарк, но направление сравнения ясно: FHE покупает возможность вычисления над шифротекстом ценой ресурсов.
| Метод | Что защищает | Что получает проверяющая сторона | Основной оверхед |
|---|---|---|---|
| zk-SNARKs | Исходные данные, использованные для доказательства | Доказательство корректности утверждения | Генерация доказательства и ограничения схемы |
| FHE | Данные во время вычисления | Результат вычисления над шифротекстом | Высокая задержка и вычислительная стоимость |
| MPC | Входы отдельных участников | Совместно вычисленный результат | Сетевые раунды, координация и модель устойчивости |
| Threshold Encryption | Ключ и доступ к расшифрованию | Расшифрование после достижения порога участников | Доступность достаточного числа узлов и согласование процесса |
ZK не заменяет FHE: доказательство корректности не позволяет произвольно выполнять вычисление над скрытым состоянием. FHE, в свою очередь, не заменяет доказательство: вычисление над шифротекстом не всегда даёт нужную публичную проверяемость результата. В одной архитектуре эти инструменты могут дополнять друг друга.
Выбирайте не «самый приватный» протокол. Выбирайте минимальный криптографический примитив, который закрывает конкретную утечку.
Пороговое шифрование и MPC: доверие без единого хранителя
В обычной схеме тот, кто контролирует приватный ключ, контролирует и возможность расшифровать данные. Для децентрализованного приложения это неудобная точка отказа: компрометация одного узла или оператора может открыть доступ ко всему содержимому.
Threshold Encryption делит ключ на фрагменты между n участниками. Для расшифрования требуется совместная работа как минимум t участников — схема t-of-n. Один узел не располагает достаточным материалом, чтобы самостоятельно восстановить ключ. Такая архитектура снижает риск единоличного злоупотребления и может использоваться для сокрытия транзакций до момента, когда протокол разрешает их раскрыть. Это, в частности, уменьшает пространство для некоторых видов вредоносного MEV.
Но пороговая схема не делает систему неуязвимой. Она переносит вопросы безопасности на состав участников и протокол координации. Если доступно меньше t узлов, расшифрование может стать невозможным. Если t участников скомпрометированы или сговорились, порог не спасает. Нужно отдельно анализировать устойчивость к отказам, процедуры ротации долей, аутентификацию сообщений и то, как система обрабатывает частичное раскрытие.
MPC решает соседнюю, но не идентичную задачу. Несколько сторон совместно вычисляют функцию над закрытыми входами, не раскрывая эти входы друг другу. Это применимо, когда данные распределены между участниками, а доверенного центра обработки нет. Однако MPC не означает, что сеть может бесплатно выполнить произвольный контракт над секретным состоянием: стоимость зависит от схемы, числа участников, сетевой задержки и количества раундов взаимодействия.
На практике пороговое шифрование и MPC стоит выбирать по модели угроз, а не по ярлыку «децентрализовано». Кто именно может увидеть открытый текст? Что произойдёт при потере узла? Может ли участник задержать вычисление или сорвать раскрытие? Как фиксируются результаты и проверяется корректность вклада? Без ответов на эти вопросы распределение ключа остаётся только схемой на диаграмме.
Производительность: проверка — не вычисление
Сравнение методов защиты информации в блокчейне часто ломается на подмене метрик. У zk-SNARKs обычно отдельно измеряют создание доказательства и его верификацию. У FHE — стоимость операций над шифротекстом. У MPC — обмен сообщениями, вычислительную нагрузку и поведение протокола при сетевых сбоях. Сводить эти величины к одному числу «скорость» нельзя.
Для ZK важны размер схемы, число ограничений, система доказательств, параметры генерации и целевое оборудование. Быстрая верификация не гарантирует дешёвого доказателя на пользовательском устройстве. Для FHE критичны тип операции, глубина вычислительной цепочки, параметры шифрования и доступность специализированного ускорителя. Оценка в 10–30 секунд на операцию — не характеристика всего FHE, а ориентир из конкретного класса оценок; до проектного бенчмарка её нельзя использовать как обещание производительности.
В публичной сети к локальной задержке добавляются комиссии и ограничения исполнения. В исследовательских материалах встречается оценка стоимости подтверждения транзакции через zk-SNARKs ниже $0,01 в DeFi. Это не универсальный тариф: реальная стоимость зависит от сети, реализации и того, что именно включено в расчёт. Так же некорректно утверждать, что ZK всегда дешевле или быстрее на всех этапах. Верификация доказательства может быть лёгкой, тогда как его генерация остаётся тяжёлой.
Перед выбором архитектуры нужен бенчмарк именно целевого сценария. Минимально измеряют:
- задержку генерации и проверки доказательства отдельно;
- стоимость вычисления и хранения данных в целевой сети;
- пиковое потребление памяти и поведение на слабом клиентском оборудовании;
- время MPC-раундов при реальной сетевой задержке;
- стоимость и пропускную способность FHE для конкретного набора операций;
- деградацию при отказе узлов, повторе сообщений и росте нагрузки.
Это не формальный чек-лист для документа. Каждый пункт выявляет класс отказа. Например, хорошее среднее время не компенсирует длинный хвост задержек, если транзакция должна завершиться в ограниченном окне. Низкая стоимость верификации не решает проблему, если доказатель требует недоступного пользователю оборудования.
Гибридный стек: ZK, FHE, MPC и TEE
Конфиденциальность транзакций в блокчейне обычно требует не одного примитива, а последовательности операций. Один компонент скрывает входы, другой вычисляет над ними, третий подтверждает корректность результата. В проектной архитектуре могут сочетаться ZK, FHE, MPC и доверенная среда исполнения — TEE. Но «гибридный стек» не становится безопасным автоматически: каждый дополнительный компонент расширяет поверхность атаки и усложняет аудит.
Условный сценарий выглядит так: данные остаются зашифрованными для вычисления; MPC распределяет между участниками контроль над секретом или совместную обработку; ZK-доказательство подтверждает, что опубликованный результат соответствует правилам; TEE может ускорить отдельную часть вычисления, если проект принимает модель доверия к аппаратной изоляции. Это не готовая универсальная сборка. Если TEE раскрывает секрет в модели угроз, ZK-доказательство не отменяет этого риска. Если ошибка находится в логике контракта, корректный криптографический примитив не исправит её.
Проектировать нужно от требуемого свойства:
- Если достаточно подтвердить условие без раскрытия входных данных, начинайте с ZK.
- Если приложению нужно выполнять набор операций над скрытым состоянием, оценивайте FHE и его оверхед на реальной нагрузке.
- Если данные принадлежат нескольким сторонам и ни одна не должна получить полный вход, рассматривайте MPC.
- Если критично не допустить единоличного расшифрования или преждевременного раскрытия, оценивайте пороговое шифрование.
- Если в стеке есть TEE, явно фиксируйте аппаратные и операционные допущения, а не называйте его заменой криптографии.
Для zk-SNARKs отдельно проверяют происхождение параметров. В некоторых оригинальных схемах требуется генерация секретного параметра; утечка такого секрета может позволить создавать поддельные доказательства, связанные с verification key. Этот риск называют токсичными отходами. Но переносить его на все ZK-системы нельзя: существуют конструкции, не требующие доверенной настройки такого типа. Аудит должен разбирать конкретную систему доказательств, процедуру настройки и хранение артефактов, а не довольствоваться словом «ZK».
Сквозное шифрование в Web3 тоже не следует путать с приватностью публичной цепочки. Шифрование канала связи защищает данные при передаче между клиентом и сервисом. Оно не скрывает автоматически публичные поля транзакции, метаданные, адреса и временные корреляции. Архитектура должна отдельно описывать защиту канала, хранение ключей, обработку состояния в контракте и публикацию результата.
Экономика приватности — это прежде всего цена гарантий
Прогнозы рынка конфиденциальных вычислений оценивают его рост с $24 млрд в 2025 году до $350 млрд к 2032 году. Для инженера это не аргумент за внедрение конкретного протокола. Рыночная оценка не показывает, насколько безопасна схема, какова реальная стоимость вычисления или выдержит ли система отказ части участников. Эти вопросы решают спецификация и бенчмарк.
Практический бюджет приватности складывается из нескольких частей: вычислительной стоимости, комиссии сети, хранения вспомогательных данных, расходов на координацию узлов и операционной цены управления ключами. К этому добавляется цена ошибок. Неверная модель доступа, неаудированный контракт или слабая процедура восстановления ключей способны обнулить преимущества выбранного примитива.
Поэтому стандарты шифрования для децентрализованных сетей нельзя выбирать по новизне названия или по размеру рынка. Нужны открытая модель угроз, проверяемая реализация и измерения на целевой нагрузке. Если продукт одновременно публикует большие объёмы данных, строит сложную доказательную схему и полагается на несколько внешних операторов, это не обязательно «более приватная» система. Это система с большим числом допущений.
Криптографическая защита данных в Web3 — не один флаг в настройках и не обещание полного сокрытия. ZK подходит для доказательства фактов, FHE — для вычислений над шифротекстом, MPC и пороговые схемы — для распределения доверия. Их можно комбинировать, но только когда каждое звено закрывает конкретный риск и прошло отдельную проверку. Технический вердикт простой: сначала формализуйте, что именно должно остаться секретным; затем измерьте цену этого свойства. Всё остальное — маркетинговая обёртка вокруг оверхеда.
