Гомоморфное шифрование в блокчейне: оправданы ли затраты

FHE позволяет считать над зашифрованными данными, не раскрывая их содержимое, но за эту возможность приходится платить вычислениями, памятью и усложнением архитектуры. Поэтому вопрос не в том, работает ли технология. Вопрос в том, где её стоимость оправдана, а где та же задача решается проще.

Для блокчейна ответ зависит прежде всего от того, где выполняются вычисления. Если поместить тяжёлую FHE-логику непосредственно в Layer-1, она конкурирует за ограниченные ресурсы сети со всеми остальными транзакциями. Если вынести её во внешний копроцессор, можно разгрузить базовый слой, но появляется новая задача: убедиться, что вычисление выполнено корректно и что оператор не получил возможность подменить результат.

Эволюция FHE: от теоретических моделей Крейга Джентри до практического применения

Идея вычислений над зашифрованными данными появилась задолго до блокчейна. В 1978 году Рональд Ривест, Леонард Адлеман и Майкл Дертуозос описали концепцию, при которой данные остаются зашифрованными, пока над ними выполняются вычисления. Долгое время практические схемы поддерживали лишь ограниченный набор операций. Одни позволяли складывать шифротексты, другие умножать, но глубина вычислений оставалась ограниченной.

В 2009 году Крейг Джентри представил первую полноценную схему полностью гомоморфного шифрования. Ключевой механизм, bootstrapping, позволяет обновить шифротекст и уменьшить накопленный в нём шум, не раскрывая исходные данные. Без этого шума вычисления постепенно теряют точность или перестают корректно расшифровываться. Bootstrapping расширяет глубину вычислений, но само по себе может быть дорогой операцией.

Большинство современных FHE-схем опираются на задачи из криптографии на решётках, в том числе на Learning With Errors и родственные конструкции. Эта основа важна и для долгосрочной безопасности: такие схемы считаются перспективными в постквантовой криптографии. Однако нельзя сводить это к обещанию абсолютной защиты от любых будущих атак. Безопасность зависит от конкретных параметров схемы и реализации.

За годы развития FHE появились разные семейства схем и техники, позволяющие подбирать инструменты под тип нагрузки. Например, BFV подходит для вычислений с целыми числами, а CKKS позволяет работать с приближёнными вещественными значениями. SIMD-упаковка даёт возможность поместить несколько значений в один шифротекст и применить одну операцию сразу к целому набору. Это может повысить эффективность пакетных вычислений, но не отменяет стоимости криптографических операций и не делает все схемы одинаково быстрыми.

Практичность FHE определяется не одним трюком оптимизации, а тем, насколько схема, тип данных и архитектура исполнения подходят конкретной задаче.

Именно здесь разговор о технологии становится разговором об экономике. Операции над зашифрованными данными требуют существенно больше вычислительных ресурсов, чем работа с открытым текстом. Разница зависит от схемы, параметров, операции и оборудования. Поэтому универсальная цифра накладных расходов плохо описывает реальную систему: простое гомоморфное сложение и глубокая цепочка умножений имеют совершенно разную стоимость.

Вычислительный барьер: почему прямое исполнение на Layer-1 остается нерентабельным

Идея исполнять FHE-операции прямо в смарт-контракте выглядит привлекательной: контракт работает с зашифрованным состоянием, а правила блокчейна остаются привычными. На практике вычислительная нагрузка делает такое исполнение тяжёлым для базового слоя. Особенно дорогими могут быть умножения шифротекстов, операции с большими полиномами и bootstrapping. Гомоморфное сложение, напротив, обычно существенно проще. Поэтому утверждение, что каждый FHE-оператор требует тысяч полиномиальных умножений, неверно: цена зависит от конкретной операции и схемы.

В блокчейне эта разница превращается в вопрос пропускной способности и стоимости транзакций. Каждый узел, который должен исполнить контракт или проверить изменение состояния, ограничен доступными ресурсами. Если добавить тяжёлые FHE-вычисления в этот путь, они могут увеличить время обработки блока и конкурировать с обычными транзакциями за вычислительный бюджет.

Сравнивать здесь полезно не абстрактные проценты, а роли разных архитектур:

У Layer-1 есть и другая роль. Он может хранить криптографически значимые данные, фиксировать разрешения, принимать результаты и проверять доказательства, не выполняя всю тяжёлую арифметику внутри каждого блока. Это не означает, что любое вынесенное вычисление автоматически становится безопасным. Нужно отдельно определить, кто имеет доступ к шифротекстам, как подтверждается корректность результата и что происходит при отказе копроцессора.

Практический вывод здесь довольно приземлённый: не каждая приватная операция оправдывает FHE. Если задача сводится к доказательству того, что пользователь удовлетворяет условию, часто достаточно доказательства с нулевым разглашением. FHE становится интереснее там, где нужно именно выполнить полезное вычисление над скрытыми значениями, а не только проверить утверждение о них.

Архитектурный сдвиг: роль off-chain копроцессоров в масштабировании приватности

В копроцессорной архитектуре Layer-1 отвечает за учёт состояния и правила доступа, а специализированный узел выполняет тяжёлые операции над шифротекстами. Контракт может оперировать ссылкой на зашифрованное значение, которую часто называют handle, а не обрабатывать весь шифротекст как обычные данные в каждом шаге исполнения.

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

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

Отдельный вариант состоит в том, чтобы подтвердить вычисление доказательством с нулевым разглашением. Это может уменьшить необходимость доверять оператору, но построение доказательств для сложных FHE-трасс тоже требует ресурсов. Поэтому архитектурный выбор нельзя свести к формуле «вынесли вычисления и решили проблему масштабируемости». Вместе с масштабированием появляются новые затраты на проверку, передачу данных и координацию между слоями.

Проекты вроде Zama, Fhenix и Inco развивают подходы к конфиденциальным вычислениям, связанные с EVM-совместимостью и внешним исполнением. Но их архитектуры и гарантии не следует объединять под одной этикеткой. При оценке конкретной системы важно смотреть, где именно выполняется FHE, кто управляет узлами, как проверяется результат и что пользователь может сделать при задержке или отказе сервиса.

Копроцессор снимает тяжёлую работу с базового слоя, но не снимает с проекта обязанность объяснить, кому и почему можно доверять.

Для конфиденциальных вычислений в блокчейне это принципиальный сдвиг. Масштабируемость достигается не тем, что криптография внезапно стала бесплатной, а тем, что вычисления распределены между участниками с разными функциями. За такое разделение приходится платить архитектурной сложностью.

Аппаратное ускорение как драйвер: от CPU к специализированным ASIC-чипам

FHE хорошо подходит для параллельной обработки ряда операций. В частности, вычисления с полиномами могут использовать техники вроде Number Theoretic Transform, или NTT. Это создаёт возможности для GPU-ускорения: массовый параллелизм графических процессоров полезен для некоторых компонентов FHE-нагрузки. Но ускорение зависит от реализации, схемы, параметров и размера задачи. Оно не гарантирует одинакового выигрыша для любой программы.

Следующий шаг, специализированные ускорители и ASIC, может ещё сильнее улучшить производительность на выбранных операциях. Такие устройства можно проектировать с учётом конкретных задач, включая полиномиальные вычисления и bootstrapping. Но аппаратный ускоритель не заменяет протокол и не решает вопросы безопасности. Он ускоряет вычислительную часть, оставляя открытыми вопросы корректности, управления ключами, доступности и проверки результата.

Поэтому оценивать переход от CPU к GPU или ASIC стоит не по одной обещанной цифре TPS. Для приложения важны и другие показатели:

• какая операция ускоряется: сложение, умножение, преобразование полиномов или bootstrapping;
• как меняется задержка для одной задачи, а не только пропускная способность при большом пакете запросов;
• сколько памяти требует выбранная схема;
• как устроена очередь задач и что происходит при перегрузке копроцессора;
• можно ли проверить вычисление независимо от самого ускорителя.

Высокая пропускная способность на пакетной нагрузке не обязательно означает низкую задержку для пользователя, который ждёт результат одной транзакции. И наоборот, ускорение отдельной операции может быть полезным, даже если оно не приводит к скачку общего TPS. Для приватного аукциона, кредитного сопоставления или аналитического запроса важны разные характеристики.

Аппаратное ускорение, таким образом, меняет соотношение затрат, но не отменяет необходимость подбирать технологию под задачу. Оно особенно привлекательно там, где протокол выполняет много однотипных вычислений и может эффективно загружать специализированные ресурсы. Для редкой или простой операции инвестиции в такой стек могут оказаться неоправданными.

FHE против ZK-proofs: разграничение задач в конфиденциальных протоколах

FHE и доказательства с нулевым разглашением часто оказываются в одном разговоре о приватности, но выполняют разные функции. FHE позволяет вычислять над зашифрованными входными данными и получать результат в зашифрованном виде. ZK-proof позволяет доказать, что некоторое утверждение верно, не раскрывая всё свидетельство, на котором оно основано.

Например, пользователь может доказать, что удовлетворяет условию доступа, не раскрывая все сведения о себе. Для этого не обязательно шифровать данные и выполнять над ними целую последовательность вычислений через FHE. Но если нескольким сторонам нужно посчитать итоговую величину по закрытым данным, не раскрывая отдельные вклады, FHE может быть подходящим инструментом.

Это не делает одну технологию универсально лучше другой. ZK-proofs могут потребовать значительных ресурсов на построение доказательства, а характеристики зависят от конкретной системы. FHE, в свою очередь, переносит стоимость в сами вычисления и работу с шифротекстами. Сравнивать их нужно на конкретной операции: что именно скрывается, что требуется вычислить и что в итоге нужно проверить в блокчейне.

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

Где гомоморфное шифрование оправдывает затраты

Гомоморфное шифрование в блокчейне оправдывает затраты тогда, когда приложению действительно необходимо вычислять над скрытыми данными. Приватные аукционы, sealed-bid голосования и некоторые виды совместной аналитики подходят для такого рассмотрения: раскрытие ставок, голосов или исходных значений может изменить саму экономику процесса.

Другие сценарии требуют более осторожного разбора. Для confidential DeFi важно понять, какие элементы состояния должны быть скрыты и от кого. Для кредитного скоринга нужно определить, кто предоставляет данные, какие именно вычисления выполняются и кому доступен результат. Само слово «приватный» не отвечает на эти вопросы. Система может скрывать один набор сведений и одновременно раскрывать метаданные, временные связи или факт участия пользователя.

Есть и задачи, где FHE будет избыточным. Если приложению нужно показать, что пользователь обладает требуемым статусом, не раскрывая дополнительные данные, доказательство с нулевым разглашением или схема обязательств может оказаться проще. Если же приватность обеспечивается на уровне интерфейса, а контракт всё равно хранит чувствительные значения открыто, дорогая FHE-логика не исправит проблему архитектуры.

Перед выбором полезно ответить на несколько предметных вопросов:

• нужно ли вычислять над данными, пока они зашифрованы, или достаточно доказать утверждение о них;
• кто получает результат и может ли он быть раскрыт без ущерба для пользователей;
• как проверяется работа копроцессора и что происходит при его отказе;
• оправдывает ли выигрыш в приватности стоимость вычислений, хранения и проверки;
• соответствует ли производительность реальной нагрузке приложения, а не только лабораторному тесту.

Это и есть практический способ оценить, оправданы ли затраты. Не нужно ждать, пока аппаратные ускорители превратят FHE в бесплатную замену обычной арифметике. Их задача состоит в том, чтобы расширить область применимости технологии. Решение всё равно начинается с конкретной модели угроз и конкретного вычисления.

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