1 запись с тегом "FHE"

Публичные блокчейны обеспечивают прозрачность и целостность ценой конфиденциальности — каждая транзакция и состояние контракта доступны всем участникам. Такая открытость создает проблемы, такие как атаки MEV (Miner Extractable Value), копитрейдинг и утечка конфиденциальной бизнес-логики. Программируемая конфиденциальность призвана решить эти проблемы, позволяя выполнять вычисления над частными данными без раскрытия самих данных. Это становится возможным благодаря двум новым криптографическим парадигмам: виртуальным машинам с полностью гомоморфным шифрованием (FHE-VM) и сопроцессорам с нулевым разглашением (ZK-сопроцессорам). Эти подходы обеспечивают вычисления вне сети или зашифрованные вычисления с верификацией в сети, сохраняя конфиденциальность и поддерживая бездоверительную корректность. В этом отчете мы подробно рассмотрим архитектуры FHE-VM и ZK-сопроцессоров, сравним их компромиссы и изучим варианты использования в финансах, идентификации, здравоохранении, рынках данных и децентрализованном машинном обучении.

Виртуальная машина с полностью гомоморфным шифрованием (FHE-VM)​

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

Архитектура и дизайн FHE-VM​

Типичная FHE-VM расширяет стандартную среду выполнения смарт-контрактов (например, Ethereum Virtual Machine) нативной поддержкой зашифрованных типов данных и операций. Например, FHEVM от Zama вводит зашифрованные целые числа (euint8, euint32 и т. д.), зашифрованные булевы значения (ebool) и даже зашифрованные массивы как первоклассные типы. Языки смарт-контрактов, такие как Solidity, дополняются библиотеками или новыми опкодами, чтобы разработчики могли выполнять арифметические (add, mul и т. д.), логические операции и сравнения непосредственно с шифротекстами. Под капотом эти операции вызывают FHE-примитивы (например, используя библиотеку TFHE) для манипулирования зашифрованными битами и получения зашифрованных результатов.

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

1. Шифрование на стороне клиента: Пользователи шифруют свои входные данные локально, используя публичный FHE-ключ, перед отправкой транзакций. Ключ шифрования является публичным (для шифрования и оценки), тогда как ключ дешифрования остается секретным. В некоторых дизайнах каждый пользователь управляет своим собственным ключом; в других используется единый глобальный FHE-ключ (обсуждается ниже).
2. Гомоморфные вычисления в сети: Майнеры/валидаторы выполняют контракт с зашифрованными опкодами. Они выполняют те же детерминированные гомоморфные операции над шифротекстами, поэтому консенсус может быть достигнут относительно нового зашифрованного состояния. Важно отметить, что валидаторы никогда не видят открытый текст — они видят только «тарабарщину» шифротекста, но все равно могут обрабатывать его согласованно.
3. Дешифрование (необязательно): Если результат необходимо раскрыть или использовать вне сети, авторизованная сторона с приватным ключом может дешифровать выходной шифротекст. В противном случае результаты остаются зашифрованными и могут использоваться в качестве входных данных для дальнейших транзакций (позволяя последовательные вычисления над постоянным зашифрованным состоянием).

Основным аспектом дизайна является управление ключами. Один подход — это ключи для каждого пользователя, где каждый пользователь хранит свой секретный ключ и только он может дешифровать результаты, относящиеся к нему. Это максимизирует конфиденциальность (никто другой никогда не сможет дешифровать ваши данные), но гомоморфные операции не могут смешивать данные, зашифрованные разными ключами, без сложных многоключевых протоколов. Другой подход, используемый FHEVM от Zama, — это глобальный FHE-ключ: единый публичный ключ шифрует все данные контракта, а распределенный набор валидаторов хранит доли ключа порогового дешифрования. Публичные ключи шифрования и оценки публикуются в сети, поэтому любой может зашифровать данные для сети; приватный ключ разделен между валидаторами, которые могут коллективно дешифровать при необходимости по пороговой схеме. Чтобы предотвратить компрометацию конфиденциальности из-за сговора валидаторов, Zama использует пороговый FHE-протокол (основанный на их исследовании Noah’s Ark) с «шумовым затоплением» для обеспечения безопасности частичных дешифрований. Только если достаточное количество валидаторов сотрудничает, открытый текст может быть восстановлен, например, для обработки запроса на чтение. Однако в обычной работе ни один узел никогда не видит открытый текст — данные всегда остаются зашифрованными в сети.

Контроль доступа является еще одним важным компонентом. Реализации FHE-VM включают детальные элементы управления для определения того, кто (если таковые имеются) может инициировать дешифрование или получать доступ к определенным зашифрованным полям. Например, fhEVM от Cypher поддерживает списки контроля доступа (ACL) для шифротекстов, позволяя разработчикам указывать, какие адреса или контракты могут взаимодействовать с определенными данными или повторно шифровать их. Некоторые фреймворки поддерживают повторное шифрование: возможность передавать зашифрованное значение от ключа одного пользователя к ключу другого без раскрытия открытого текста. Это полезно для таких вещей, как рынки данных, где владелец данных может зашифровать набор данных своим ключом, а после покупки повторно зашифровать его ключом покупателя — все в сети, без публичного дешифрования.

Обеспечение корректности и конфиденциальности​

Можно спросить: если все данные зашифрованы, как мы обеспечиваем корректность логики контракта? Как цепочка может предотвратить недействительные операции, если она не может «видеть» значения? FHE само по себе не предоставляет доказательства корректности — валидаторы могут выполнять гомоморфные шаги, но они не могут по своей сути определить, был ли зашифрованный ввод пользователя действительным или следует ли выбрать условную ветвь и т. д., без дешифрования. Доказательства с нулевым разглашением (ZKPs) могут дополнять FHE для решения этой проблемы. В FHE-VM, как правило, пользователи должны предоставлять ZK-доказательство, подтверждающее определенные условия открытого текста, когда это необходимо. Дизайн Zama, например, использует ZK Proof of Plaintext Knowledge (ZKPoK) для сопровождения каждого зашифрованного ввода. Это доказывает, что пользователь знает открытый текст, соответствующий его шифротексту, и что он соответствует ожидаемым критериям, не раскрывая сам открытый текст. Такие «сертифицированные шифротексты» предотвращают отправку злоумышленником некорректного шифрования или значения, выходящего за пределы диапазона. Аналогично, для операций, требующих принятия решения (например, убедиться, что баланс счета ≥ сумма вывода), пользователь может предоставить ZK-доказательство того, что это условие выполняется для открытых текстов до выполнения зашифрованной операции. Таким образом, цепочка не дешифрует и не видит значения, но получает уверенность в том, что зашифрованные транзакции соответствуют правилам.

Другой подход в FHE-роллапах — это выполнение верификации вне сети с помощью ZKP. Fhenix (L2-роллап, использующий FHE) выбирает оптимистическую модель, где отдельный сетевой компонент, называемый Threshold Service Network, может дешифровать или верифицировать зашифрованные результаты, и любая некорректная вычисления может быть оспорена с помощью доказательства мошенничества. В целом, комбинация FHE + ZK или доказательств мошенничества гарантирует, что зашифрованное выполнение остается бездоверительным. Валидаторы либо коллективно дешифруют только при наличии разрешения, либо верифицируют доказательства того, что каждый зашифрованный переход состояния был действительным, не требуя просмотра открытого текста.

Соображения производительности: Операции FHE вычислительно тяжелы — на многие порядки медленнее, чем обычная арифметика. Например, простое 64-битное сложение в Ethereum стоит ~3 газа, тогда как сложение зашифрованного 64-битного целого числа (euint64) в FHEVM от Zama стоит примерно 188 000 газа. Даже 8-битное сложение может стоить ~94k газа. Этот