)

Основные идеи:

1. FHE обещает стать "Святым Граалем криптографии", однако существует множество проблем, связанных с производительностью, опытом разработчиков и безопасностью, которые ограничивают его применение в настоящее время.

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

3.FHE быстро развивается; разработка новых компиляторов, библиотек, аппаратного обеспечения и т.д. Не говоря уже о том, что FHE извлекает огромную пользу из R&D компаний Web2 (Intel, Google, DARPA и т.д.).

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

5.Основополагающим ограничением onchain FHE является вопрос: "Кто владеет ключом дешифрования?". Пороговое расшифрование и MPC предлагают решения, однако они, как правило, связаны компромиссом между производительностью & и безопасностью.

Введение:

Прозрачная природа блокчейн - это меч с двумя концами; хотя в ее открытости и наблюдаемости есть своя прелесть, она является фундаментальным препятствием для внедрения на предприятиях.

Конфиденциальность в сети является одной из самых сложных проблем в криптовалюте уже почти десять лет. Хотя существует множество команд, создающих системы на основе ZK для достижения конфиденциальности на цепочке; они не могут поддерживать общее зашифрованное состояние. Почему? Короткий ответ: потому что эти программы являются функцией ряда ЗКП, и поэтому никто не может применить произвольную логику к текущему состоянию. Что это значит? В принципе, мы не можем создавать конфиденциальные приложения с общим состоянием (подумайте о частном Uniswap), используя только ZKP.

Однако недавние открытия показали, что сочетание ZKP с полностью гомоморфным шифрованием (FHE) может обеспечить полностью обобщаемый конфиденциальный DeFi. Как? FHE - это развивающаяся область криптографии, которая позволяет производить произвольные вычисления над зашифрованными данными (звучит безумно, правда?!) Как показано на графике выше, ZKP могут подтвердить целостность пользовательских данных и вычислений, а FHE может обрабатывать сами вычисления.

Хотя FHE обещает стать "Святым Граалем криптографии", мы попытаемся дать объективный анализ этой области, ее различных проблем и возможных решений. Мы рассмотрим следующие темы, связанные с ончейн FHE:

• Схемы, библиотеки и компиляторы FHE
• Безопасное пороговое расшифрование
• ZKPs для пользовательских входов + вычислительная сторона
• Программируемый, масштабируемый уровень DA
• Оборудование FHE

Схемы, библиотеки и компиляторы FHE

Вызов: зарождающиеся схемы FHE, библиотеки и компиляторы

Основное узкое место onchain FHE кроется в отстающих инструментах/инфраструктуре для разработчиков. В отличие от ZKPs или MPC, FHE существует только с 2009 года, и поэтому у него было гораздо меньше времени для созревания.

Основными ограничениями в FHE DevEx являются :

• Простой в использовании внешний язык, позволяющий разработчикам создавать код без особых знаний о внутренней криптографии
• Полнофункциональный компилятор FHE, который может выполнять всю грязную работу. (Выбор параметров, оптимизация SIMD для BGV/BFV и параллельная оптимизация)
• Существующие схемы FHE (особенно TFHE) примерно в 1000 раз медленнее по сравнению с простыми вычислениями.

Чтобы по-настоящему понять все тонкости интеграции FHE, давайте пройдемся по пути разработчика:

Первый шаг к интеграции FHE в Ваше приложение - это выбор схемы FHE для использования. Следующая схема объясняет основные схемы:

Как показано в таблице выше, такие булевые схемы, как FHEW & TFHE, имеют самый быстрый бутстрап и позволяют избежать довольно сложной процедуры выбора параметров, и их можно использовать в произвольных/генеральных вычислениях, но они относительно медленные; в то время как BGV/BFV могут подойти для общих DeFi, поскольку они более эффективны при высокоточных арифметических вычислениях, но разработчики должны заранее знать глубину схемы, чтобы настроить все параметры схемы. На другом конце спектра CKKS поддерживает гомоморфное умножение, при котором допускаются ошибки точности, что делает его оптимальным для неточных случаев использования, таких как ML.

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

Если перейти к библиотекам, то функции и возможности популярных библиотек FHE можно увидеть в таблице ниже:

Но библиотеки также имеют различные отношения со схемами и компиляторами, как показано ниже:

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

На этом этапе разработчики могут спросить:

Насколько большим должно быть мое пространство открытого текста? Какая величина шифротекстов допустима? Где я могу распараллелить вычисления? И многое другое...

Кроме того, хотя FHE может поддерживать произвольные вычисления, разработчикам необходимо изменить свое мышление при написании программ FHE. Например, нельзя написать ветку (if-else), зависящую от переменной в программе, потому что программы не могут напрямую сравнивать переменные, как обычные данные. Вместо этого разработчикам необходимо изменить свой код, перейдя от ветвей к какому-то вычислению, которое может включать в себя все условия ветвей. Аналогично, это не позволяет разработчикам писать циклы в своем коде.

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

Решение:

1. Web3 Специфические компиляторы FHE

Хотя уже существуют компиляторы FHE, созданные такими компаниями, как Google и Microsoft, они являются таковыми:

• Не разработанный с учетом производительности, он добавляет 1000-кратные накладные расходы по сравнению с непосредственным написанием схем
• Оптимизирован для CKKS (aka ML) и не так полезен для BFV/BGV, необходимых для DeFi
• Не создан для Web3. Не поддерживает совместимость со схемами ZKP, цепочки программ и т.д.

Так было до появления компилятора Sunscreen FHE. Это родной компилятор Web3, который предлагает одну из самых лучших производительность при выполнении арифметических операций (подумайте о DeFi) без аппаратных ускорителей. Как говорилось выше, выбор параметров - это, пожалуй, самая сложная часть реализации схемы FHE; Sunscreen не только автоматизировал выбор параметров, но и кодирование данных, выбор ключа, реализовал релинеаризацию и переключение модулей, настроил схемы и реализовал операции в стиле SIMD.

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

1. Новая библиотека FHE

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

В качестве примера возьмем смарт-контракты FHE. Хотя может быть трудно выбрать из различных библиотек FHE, это становится проще, когда мы говорим о onchain FHE, потому что в Web3 существует всего несколько доминирующих языков программирования.

Например, fhEVM от Zama интегрирует библиотеку с открытым исходным кодом TFHE-rs от Zama в типичный EVM, раскрывая гомоморфные операции как прекомпилированные контракты. Эффективная возможность для разработчиков использовать зашифрованные данные в своих контрактах, без каких-либо изменений в инструментах компиляции.

Для других специфических сценариев может потребоваться иная инфраструктура. Например, библиотека TFHE, написанная на C++, не так хорошо поддерживается, как версия для Rust. Хотя TFHE-rs может поддерживать экспорт для C/C++, если разработчики C++ хотят лучшей совместимости и производительности, они должны написать свою собственную версию библиотеки TFHE.

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

Безопасное пороговое расшифрование

Проблема: Небезопасное/централизованное пороговое расшифрование

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

Одним из наиболее сложных аспектов onchain FHE (порогового FHE) является создание безопасного и преформативного протокола порогового расшифрования. Существует два основных узких места: (1) Вычисления на основе FHE создают значительные накладные расходы, поэтому требуют высокопроизводительных узлов, что неизбежно уменьшает потенциальный размер набора валидаторов (2) По мере увеличения количества узлов, участвующих в протоколе расшифровки, увеличивается задержка.

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

Что, если пороговые узлы вступят в сговор? Они смогут обойти протокол и, по сути, расшифровать все, что угодно, начиная от пользовательского ввода и заканчивая любыми данными на цепочке. Кроме того, важно отметить, что протокол расшифровки может происходить незаметно для современных систем (ака "тихая атака").

Решение: Улучшенное пороговое расшифрование или динамический MPC

Есть несколько способов устранить недостатки пороговой расшифровки. (1) Включите порог n/2, что затруднит сговор (2) Запустите протокол порогового расшифрования внутри HSM (3) Используйте сеть порогового расшифрования на базе TEE, контролируемую децентрализованной цепочкой для аутентификации, позволяющей динамически управлять ключами.

Вместо того, чтобы использовать пороговую расшифровку, можно использовать MPC. Примером протокола MPC, который можно использовать в onchain FHE, является новый 2PC-MPC от Odsy, первый не вызывающий нареканий и массово децентрализованный алгоритм MPC.

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

Подводя итог, можно сказать, что onchain FHE нуждается в эффективной реализации MPC, которая: (1) Работает даже при наличии злоумышленников (2) Обеспечивает минимальную задержку (3) Позволяет разрешать/гибко вводить узлы.

Доказательство с нулевым знанием (ZKP) для пользовательского ввода и вычислительной стороны

Задача: Верифицируемость пользовательских данных + вычисления:

В web2, когда мы просим выполнить вычислительную задачу, мы полностью доверяем данной компании, что она выполнит ее именно так, как обещала за кулисами. В web3 модель полностью перевернута; вместо того, чтобы полагаться на репутацию компании и просто верить, что она будет действовать честно, мы теперь работаем в среде без доверия, то есть пользователи не должны никому доверять.

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

Решение: ZKPs для пользовательских входов + вычислительная сторона:

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

Есть три основных способа, с помощью которых FHE и ЗКП сочетаются друг с другом:

1. Пользователь должен предоставить доказательство того, что его входной шифротекст хорошо сформирован. Это означает, что шифротекст соответствует требованиям схемы шифрования и не является просто произвольными строками данных.
2. Пользователю необходимо предоставить доказательство того, что вводимый им открытый текст удовлетворяет условиям данного приложения. Например, amount_balance > amount_transfer
3. Узел-валидатор (он же вычислительная сторона) должен доказать, что он правильно выполнил вычисления FHE. Это называется "верифицируемым FHE" и может рассматриваться как аналог ZKP, необходимых для сворачивания.

Для дальнейшего изучения возможностей применения ZKP:

1. ЗКП шифротекста

FHE построен на криптографии, основанной на решетках, что означает, что для построения криптографического примитива используются решетки, которые являются PQ (пост-квантовыми) безопасными. В отличие от них, популярные ЗКП, такие как SNARKS, STARKS и Bulletproofs, не используют криптографию на основе решетки.

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

1. ZKP входного открытого текста

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

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

Sunscreen также заложила основу в свой компилятор ZKP, который предлагает поддержку Bulletproofs, поскольку он легче всего соединяется с SDLP. В будущем планируется "связать" компилятор FHE и ZKP.

Компания Mind Network стала пионером в интеграции ZKPs для обеспечения нулевого доверия к входным и выходным данным, а также в использовании FHE для безопасных вычислений.

1. ZKP правильных вычислений

Выполнение FHE на существующем оборудовании крайне неэффективно и дорого. Как мы уже видели ранее, динамика трилеммы масштабируемости проявляется в том, что сети с более высокими требованиями к ресурсам узлов не могут масштабироваться до достаточного уровня децентрализации. Возможным решением может стать процесс под названием "Verifiable FHE", процесс, в котором вычисляющая сторона (валидатор) подает ZKP для подтверждения честного выполнения транзакций.

Ранний прототип верифицируемого FHE можно увидеть в проекте под названием SherLOCKED. По сути, вычисления FHE перекладываются на Bonsai компании Risc ZERO, которая обрабатывает вычисления над зашифрованными данными вне цепи, возвращает результат с ZKP и обновляет состояние на цепи.

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

Наконец, важно затронуть вопрос о том, где разработчик может создать приложение FHE в первую очередь. Разработчики могут создавать свои приложения либо на базе L1 с питанием от FHE, либо на базе FHE rollup, либо на базе любой EVM-цепочки и с использованием сопроцессора FHE. Каждая конструкция имеет свой собственный набор компромиссов, однако мы больше склоняемся к хорошо продуманным FHE-рулонам (впервые разработанным компанией Fhenix) или FHE-сопроцессорам, поскольку они наследуют безопасность Ethereum среди прочих преимуществ.

До недавнего времени достижение доказательств мошенничества с зашифрованными данными FHE было сложной задачей, но недавно команда Fhenix.io продемонстрировала, как достичь доказательств мошенничества с помощью стека Arbitrum Nitro в сочетании с компиляцией логики FHE в WebAssembly.

Доступность данных (DA) Уровень FHE

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

В то время как в Web2 система хранения данных стала товарной, в Web3 дело обстоит иначе. Учитывая, что FHE позволяет раздувать данные до 10 000x+, нам нужно придумать, где хранить большие шифротексты FHE. Если бы каждый оператор узла в данном слое DA должен был загружать и хранить данные каждой цепочки FHE, только институциональные операторы смогли бы справиться со спросом, что создало бы риск централизации.

Что касается пропускной способности, Celestia достигает максимума в 6,7 мб/с, если мы хотим запустить FHEML в любой форме, нам потребуется легко n Гб+/с. Согласно последним данным, предоставленным компанией 1k(x), существующие уровни DA не могут поддерживать FHE из-за конструктивных решений, которые ограничивают пропускную способность (намеренно).

Решение: Горизонтальное масштабирование + настраиваемость

Нам нужен уровень DA, поддерживающий горизонтальную масштабируемость. Существующие архитектуры DA распространяют все данные на каждый узел сети, что является серьезным ограничением для масштабируемости. И наоборот, при горизонтальном масштабировании, когда в системе появляется больше узлов DA, каждый узел хранит 1/nth часть данных, что повышает производительность и стоимость, так как освобождается больше места для блоков.

Кроме того, учитывая значительный объем данных, связанных с FHE, имеет смысл предложить разработчикам более высокий уровень настраиваемости пороговых значений кодирования стирания. т.е. Насколько система DA Вам подходит для гарантии? Будь то взвешивание, основанное на долях, или взвешивание, основанное на децентрализации.

Архитектура EigenDA служит основой того, как может выглядеть уровень DA для FHE. Свойства горизонтального масштабирования, структурное снижение затрат, развязка DA и консенсуса и т.д. - все это дает возможность достичь уровня масштабируемости, который в один прекрасный день сможет поддержать FHE.

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

Оборудование для полностью гомоморфного шифрования (FHE)

Задача: Низкопроизводительное аппаратное обеспечение FHE

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

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

Суть сложности вычислений и аппаратного дизайна для FHE всегда связана с количеством умножений, необходимых для данного приложения, называемым "глубиной гомоморфной операции". В случае с конкретным приложением глубина известна, поэтому параметры системы и соответствующие вычисления фиксированы. Поэтому проектирование аппаратного обеспечения для этого специфического случая будет проще и обычно может быть оптимизировано для лучшей производительности, чем проектирование ускорителей общего назначения. В общем случае, когда от FHE требуется поддержка произвольного числа умножений, бутстрапинг необходим для удаления части шума, накопленного в ходе гомоморфных операций. Bootstrapping стоит дорого и требует значительных аппаратных ресурсов, включая память на кристалле, пропускную способность памяти и вычисления, а это значит, что дизайн аппаратного обеспечения будет сильно отличаться от дизайна конкретного приложения. Поэтому, несмотря на то, что работа, проделанная основными игроками в этой области, включая Intel, Duality, SRI, DARPA и многих других, несомненно, расширяет границы своих разработок на базе GPU и ASIC, они не могут быть 1:1 применимы для поддержки сценариев использования блокчейна.

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

Важно отметить, что ускорить onchain FHE гораздо сложнее, чем специфические приложения (например, FHEML), поскольку для этого требуется способность обрабатывать более общие вычисления, а не более узкий набор. В качестве примера можно привести fhEVM devnet, который в данный момент ограничен однозначным показателем TPS.

Учитывая, что нам нужен ускоритель FHE, адаптированный для блокчейна, еще один вопрос: насколько можно перенести работу с аппаратного обеспечения ZKP на аппаратное обеспечение FHE?

Между ZKP и FHE есть некоторые общие модули, такие как теоретико-числовое преобразование (NTT) и лежащие в его основе полиномиальные операции. Однако битовая ширина NTT, используемая в этих двух случаях, отличается. В ZKP аппаратное обеспечение должно поддерживать широкий диапазон ширины битов для NTT, например, 64 и 256 бит, в то время как в FHE операнды для NTT короче, поскольку представлены в системе чисел с остатком. Во-вторых, степень NTT в ZKP в целом выше, чем в случае FHE. По этим двум причинам не так просто разработать модуль NTT, который обеспечит удовлетворительную производительность как для ZKP, так и для FHE. Кроме NTT, в FHE есть и другие узкие места в вычислениях, такие как автоморфизм, которых нет в ZKP. Наивный способ переноса аппаратных средств ZKP в среду FHE заключается в том, чтобы выгрузить вычислительную задачу NTT на аппаратные средства ZKP и использовать CPU или другие аппаратные средства для выполнения остальных вычислений в FHE.

В довершение всех трудностей, вычисления на зашифрованных данных с помощью FHE раньше были в 100 000 раз медленнее, чем на данных с открытым текстом. Однако благодаря новейшим схемам шифрования и последним разработкам в области аппаратных средств FHE, текущая производительность значительно возросла и стала примерно в 100 раз медленнее, чем у данных в открытом тексте.

Решения:

1. Улучшение аппаратного обеспечения FHE

Существует множество команд, активно создающих ускорители FHE, однако они не работают над ускорителями FHE, предназначенными для обобщенных вычислений на основе блокчейна (т.е. TFHE). Примером аппаратного ускорителя для блокчейна является FPT, ускоритель FPGA с фиксированной точкой. FPT - это первый аппаратный ускоритель, который в значительной степени использует шум, присущий вычислениям FHE, реализуя загрузку TFHE полностью с помощью приближенной арифметики с фиксированной точкой. Еще один проект, который может быть полезен для FHE, - BASALISC, семейство аппаратных ускорителей, которые призваны существенно ускорить вычисления FHE в облаке.

Как было отмечено ранее, одним из основных узких мест при разработке аппаратного обеспечения FHE является массивное взаимодействие с памятью. Чтобы обойти это препятствие, потенциальным решением является максимальное сокращение взаимодействия с памятью. Обработка в памяти (PIM) или вычисления вблизи памяти, вероятно, будут полезны в этом сценарии. PIM - это многообещающее решение проблемы "стены памяти" для будущих компьютерных систем, которое позволяет памяти выполнять как вычислительные, так и запоминающие функции, что обещает радикальное обновление отношений между вычислениями и памятью. За последнее десятилетие был достигнут огромный прогресс в разработке энергонезависимой памяти для этих целей, такой как резистивная RAM, магнитная RAM со спин-трансферным моментом и память с фазовыми изменениями. Использование этой специальной памяти позволило значительно улучшить вычисления в машинном обучении и шифровании с открытым ключом на основе решеток.

1. Оптимизированное программное и аппаратное обеспечение

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

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

1. Сетевые акселераторы FHE: Сдвиг от расширения масштаба к расширению масштаба

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

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

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

Заключение

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

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

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

Особая благодарность：

Большое спасибо Мейсону Сонгу (Mind Network), Гаю Ицхаки (Fhenix), Лео Фану (Cysic), Курту Пану, Сяну Кси (PADO), Нитаншу Локханде (BananaHQ) за рецензии. Мы с нетерпением ждем возможности прочитать о впечатляющей работе и усилиях, которые эти люди прилагают в данной области!

Отказ от ответственности：

1. Эта статья перепечатана с сайта[HashKey Capital]. Все авторские права принадлежат автору[Джеффри Ху и Арнаву Пагидьяле]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Предупреждение об ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.