)

Основні ідеї:

1. FHE обіцяє стати «Священним Граалем криптографії», однак існує багато проблем із продуктивністю, досвідом розробників і безпекою, які обмежують його впровадження.

2. Як показано на малюнку вище, FHE потрібно буде використовувати поряд із ZKP та MPC, щоб побудувати справді конфіденційну та безпечну спільну державну систему.

3. FHE швидко розвивається; Розробка нових компіляторів, бібліотек, обладнання тощо. Не кажучи вже про те, що FHE отримує величезну користь від досліджень і розробок компаній Web2 (Intel, Google, DARPA тощо).

4. У міру розвитку FHE та навколишньої екосистеми ми очікуємо, що «FHE, що піддається перевірці», стане стандартом. Програми FHE можуть передати обчислення та перевірку співпроцесорам FHE.

5. Основним обмеженням FHE в ланцюзі є «хто володіє ключем дешифрування?» Порогове дешифрування та MPC пропонують рішення, однак вони, як правило, пов’язані між продуктивністю та безпекою.

Вступ:

Прозора природа блокчейнів — це палка з двома краями; незважаючи на те, що його відкритість і спостережливість є красою, це є фундаментальною перешкодою для впровадження підприємства.

Конфіденційність Onchain була однією з найскладніших проблем у криптовалюті протягом майже десяти років. Хоча є багато команд, які створюють системи на основі ZK для досягнення конфіденційності в мережі; вони не можуть підтримувати спільний зашифрований стан. чому Коротка відповідь полягає в тому, що ці програми є функцією серії ZKP, і тому ніхто не може застосувати довільну логіку до поточного стану. Що це значить? Загалом ми не можемо створювати конфіденційні програми загального стану (наприклад, приватні Uniswap), використовуючи лише ZKP.

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

Незважаючи на те, що FHE обіцяє бути «Священним Граалем криптографії», ми намагаємося надати об’єктивний аналіз галузі та її різноманітних проблем і можливих рішень. Ми розглядаємо наступні теми ончейн FHE:

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

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

Завдання: зароджувані схеми FHE, бібліотеки та компілятори

Фундаментальне вузьке місце onchain FHE полягає в його відстаючих інструментах розробника/інфраструктурі. На відміну від ZKP або 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. Спеціальні компілятори FHE Web3

Хоча вже існують компілятори FHE, створені такими компаніями, як Google і Microsoft, вони:

• Не розроблено з огляду на продуктивність, додаючи 1000x накладні витрати проти напряму запису схем
• Оптимізовано для CKKS (він же ML) і не настільки вигідно для BFV/BGV, необхідних для DeFi
• Не створено для Web3. Не підтримує сумісність зі схемами ЗКП, зчеплення програм тощо.

Це до компілятора Sunscreen FHE. Це власний компілятор Web3, який пропонує найкращу продуктивність для арифметичних операцій (наприклад, DeFi) без апаратних прискорювачів. Як обговорювалося вище, вибір параметра є, мабуть, найскладнішою частиною реалізації схеми FHE; Сонцезахисний крем має не лише автоматичний вибір параметрів, але й кодування даних, вибір клавіш, реалізує релінеаризацію та перемикання модулів, налаштовує схеми та реалізує операції в стилі SIMD.

Просуваючись у майбутнє, ми очікуємо подальшої оптимізації не лише компілятора Sunscreen, а й інших команд, які розробляють власні реалізації, які підтримують інші мови високого рівня.

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

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

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

Наприклад, fhEVM від Zama інтегрує бібліотеку Zama з відкритим кодом TFHE-rs у типову EVM, розкриваючи гомоморфні операції як попередньо скомпільовані контракти. Ефективно дозволяючи розробникам використовувати зашифровані дані у своїх контрактах без будь-яких змін до інструментів компіляції.

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

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

Безпечне порогове дешифрування

Завдання: незахищене/централізоване порогове дешифрування

Кожна конфіденційна система спільного стану базується на ключі шифрування/дешифрування. Жодній стороні не можна довіряти, тому ключ дешифрування розподіляється між учасниками мережі.

Одним із найскладніших аспектів onchain FHE (Threshold FHE) є створення захищеного та попереднього порогового протоколу дешифрування. Є два основних вузьких місця: (1) обчислення на основі FHE створює значні накладні витрати, отже, вимагаючи високопродуктивних вузлів, що за своєю суттю зменшує потенційний розмір набору валідатора (2) Зі збільшенням кількості вузлів, які беруть участь у протоколі дешифрування, збільшується затримка.

Принаймні на даний момент протоколи FHE покладаються на чесну більшість валідаторів, однак, як зазначено вище, Threshold FHE передбачає менший набір валідаторів і, отже, більшу ймовірність змови та зловмисної поведінки.

Що робити, якщо порогові вузли змовляються? Вони зможуть обійти протокол і фактично розшифрувати все, від введених користувачем даних до будь-яких даних onchain. Крім того, важливо зазначити, що протокол дешифрування може відбуватися непомітно в поточних системах (так званий «тиха атака»).

Рішення: покращене порогове дешифрування або динамічний MPC

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

Замість використання порогового дешифрування можна використовувати MPC. Прикладом протоколу MPC, який можна використовувати в ончейновій FHE, є новий 2PC-MPC від Odsy, перший незмовний і масово децентралізований алгоритм MPC.

Іншим підходом може бути використання лише відкритого ключа користувача для шифрування даних. Потім валідатори обробляють гомоморфні операції, а самі користувачі можуть розшифрувати результат, якщо це необхідно. Хоча це можливо лише для нішевих випадків використання, ми могли б взагалі уникнути порогового припущення.

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

Підтвердження нульового знання (ZKP) для введення користувача та обчислювальної сторони

Завдання: Перевірка введених користувачем даних + обчислення:

У web2, коли ми просимо виконати обчислювальне завдання, ми повністю віримо, що дана компанія виконає це завдання саме так, як вони обіцяли за лаштунками. У web3 модель повністю перевернута; замість того, щоб покладатися на репутацію компанії та просто вірити, що вона діятиме чесно, ми зараз працюємо в середовищі, де немає довіри, тобто користувачі не повинні нікому довіряти.

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

Рішення: ZKPs for User Inputs + Computing Party:

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

Є три ключові способи поєднання FHE та ZKP:

1. Користувач повинен надати доказ того, що його введений зашифрований текст правильно сформований. Це означає, що зашифрований текст відповідає вимогам схеми шифрування, а не є просто довільними рядками даних.
2. Користувач повинен надати доказ того, що його введений відкритий текст задовольняє умови певної програми. Пр. сума_залишок > сума_переказу
3. Вузол валідатора (він же обчислювальна сторона) повинен підтвердити, що він правильно виконав обчислення FHE. Це називається «FHE, що піддається перевірці», і його можна розглядати як аналог ZKP, необхідних для зведення.

Щоб глибше вивчити застосування ZKP:

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

FHE побудовано на криптографії на основі решітки, тобто конструкція криптографічного примітиву включає решітки, які є PQ (постквантовими) безпечними. Навпаки, популярні ZKP, такі як SNARKS, STARKS і Bulletproofs, не покладаються на криптографію на основі решітки.

Щоб довести, що шифртекст FHE користувача правильно сформований, нам потрібно показати, що він задовольняє деяке матриць-векторне рівняння з записами з кілець і що числові значення цих елементів невеликі. По суті, нам потрібна економічно ефективна система підтвердження верифікації в ланцюжку, призначена для обробки зв’язків на основі решітки, що є відкритою областю для дослідження.

1. ЗКП введення відкритого тексту

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

Однак складною частиною є те, що нам потрібно «з’єднати» дві системи перевірки. З’єднайте, як нам потрібно переконатися, що користувач використовує той самий вхід для обох систем перевірки; інакше зловмисник може обдурити протокол. Знову ж таки, це неймовірно складний криптографічний подвиг і відкрита область ранніх досліджень.

Sunscreen також заклав основу зі своїм компілятором ZKP, який пропонує підтримку Bulletproofs, оскільки він найлегше підключається до SDLP. Подальші розробки ведуться для «зв’язування» компілятора FHE та ZKP.

Mind Network була піонером інтеграції ZKP для забезпечення вхідних і вихідних даних із нульовою довірою разом із використанням FHE для безпечних обчислень.

1. ЗКП Коректного Обчислення

Запуск FHE на існуючому обладнанні вкрай неефективний і дорогий. Як ми бачили динаміку трилеми масштабованості раніше, мережі з вищими вимогами до ресурсів вузлів не можуть масштабуватися до достатнього рівня децентралізації. Можливим рішенням може бути процес під назвою «FHE, який можна перевірити», тобто процес, у якому обчислювальна сторона (валідатор) подає ZKP, щоб підтвердити чесне виконання транзакцій.

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

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

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

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

Рівень доступності даних (DA) FHE

Проблема: відсутність можливостей налаштування та пропускної здатності

У той час як сховище було комерціалізовано в web2, це не стосується Web3. Враховуючи, що FHE підтримує велике збільшення даних у 10 000+, нам потрібно визначити, де зберігати великі шифртексти FHE. Якби кожен оператор вузла на даному рівні DA завантажував і зберігав дані кожного ланцюга FHE, лише інституційні оператори змогли б задовольнити попит, ризикуючи централізацією.

Щодо пропускної здатності Celestia досягає 6,7 Мбіт/с, якщо ми хочемо запустити будь-яку форму FHEML, нам знадобиться n ГБ+/с. Відповідно до останніх даних, наданих 1k(x), існуючі рівні DA не можуть підтримувати FHE через конструктивні рішення, які обмежують пропускну здатність (навмисно).

Рішення: горизонтальне масштабування + можливість налаштування

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

Окремо, враховуючи значний обсяг даних, пов’язаний із FHE, було б доцільно запропонувати розробникам вищий рівень настроюваності щодо порогових значень кодування стирання. тобто Яка частина системи DA вам підходить для гарантії? Чи зважування на основі часток, чи на основі децентралізації.

Архітектура EigenDA служить основою того, як може виглядати рівень DA для FHE. Це властивості горизонтального масштабування, структурного скорочення витрат, відокремлення DA та консенсусу тощо. Усе це поступається місцем рівню масштабованості, який одного разу може підтримувати FHE.

Нарешті, високорівневою ідеєю може бути створення оптимізованих слотів для зберігання зашифрованих текстів FHE, оскільки зашифровані тексти дотримуються певної схеми кодування, тому наявність оптимізованих слотів для зберігання може допомогти з ефективним використанням сховища та швидшим пошуком.

Апаратне забезпечення повністю гомоморфного шифрування (FHE).

Завдання: низькопродуктивне обладнання FHE

Під час просування додатків повного гомоморфного шифрування (FHE) у ланцюжку основною проблемою є значна затримка через обчислювальні витрати, що робить використання FHE непрактичним на будь-якому стандартному обладнанні для обробки. Це обмеження пов’язане з великою кількістю взаємодії з пам’яттю через величезну кількість даних, які процесор повинен обробити. Окрім взаємодії з пам’яттю, складні поліноміальні обчислення та трудомісткі операції з обслуговування зашифрованого тексту також спричиняють багато накладних витрат.

Щоб глибше зрозуміти стан прискорювачів FHE, нам потрібно розкрити простір проектування: прискорювачі FHE для конкретної програми проти узагальнених прискорювачів FHE.

Суть складності обчислень і дизайну апаратного забезпечення для FHE завжди пов’язана з кількістю множень, необхідних для даної програми, що називається «глибиною гомоморфної операції». У конкретному прикладному випадку глибина відома, тому системні параметри та відповідне обчислення є фіксованими. Таким чином, дизайн апаратного забезпечення для цього конкретного прикладного випадку буде легшим і зазвичай може бути оптимізовано для кращої продуктивності, ніж узагальнений дизайн прискорювача. У загальному випадку, коли FHE вимагається підтримувати довільну кількість множень, початкове завантаження необхідне для видалення частини шуму, накопиченого в гомоморфних операціях. Завантаження є дорогим і вимагає значних апаратних ресурсів, включаючи вбудовану пам’ять, пропускну здатність пам’яті та обчислення, що означає, що дизайн апаратного забезпечення буде сильно відрізнятися від дизайну для конкретної програми. Таким чином, незважаючи на те, що робота, виконана великими гравцями в цьому просторі, зокрема такими як 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 і використовувати ЦП або інше обладнання для обробки решти обчислень у FHE.

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

рішення:

1. Покращення апаратного забезпечення FHE

Є багато команд, які активно розробляють прискорювачі FHE, однак вони не працюють над прискорювачами FHE, які є специфічними для узагальнюваних блокчейн-обчислень (тобто TFHE). Прикладом спеціального апаратного прискорювача блокчейну є FPT, прискорювач FPGA з фіксованою точкою. FPT є першим апаратним прискорювачем, який значною мірою використовує внутрішній шум, присутній у обчисленнях FHE, реалізуючи завантаження TFHE повністю з приблизною арифметикою з фіксованою комою. Іншим проектом, який може бути корисним для FHE, є BASALISC, сімейство апаратних прискорювачів архітектури, яке спрямоване на суттєве прискорення обчислень FHE у хмарі.

Як зазначалося раніше, одним із основних вузьких місць у розробці апаратного забезпечення FHE є масивна взаємодія з пам’яттю. Щоб обійти цей бар’єр, потенційним рішенням є максимально зменшити взаємодію з пам’яттю. Обчислення обробки в пам’яті (PIM) або наближення до пам’яті, ймовірно, корисно в цьому сценарії. PIM є багатообіцяючим рішенням для вирішення проблем «стіни пам’яті» для майбутніх комп’ютерних систем, яке дозволяє пам’яті виконувати функції обчислень і пам’яті, обіцяючи радикальне оновлення зв’язку між обчисленнями та пам’яттю. За останнє десятиліття було досягнуто величезного прогресу в розробці енергонезалежної пам’яті для цієї мети, наприклад резистивної ОЗУ, магнітної ОЗП із перенесенням крутного моменту та пам’яті зі зміною фази. Використовуючи цю спеціальну пам’ять, була проведена робота, яка показала значне покращення обчислень у машинному навчанні та шифруванні з відкритим ключем на основі решітки.

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

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

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

1. Мережеві прискорювачі FHE: перехід від масштабування до масштабування

Існуючі зусилля з апаратного прискорення FHE здебільшого зосереджені на «масштабуванні», що означає зосередження на вдосконаленні одного вертикального прискорювача. З іншого боку, місця масштабування зосереджені на з’єднанні кількох прискорювачів FHE шляхом горизонтального об’єднання в мережу, що може значно підвищити продуктивність, подібно до паралельної генерації доказів із ZKP.

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

Інфляція даних створює серйозну проблему для горизонтального підключення кількох прискорювачів FHE через мережу. Таким чином, спільне проектування обладнання та мережі FHE буде перспективним напрямком майбутніх досліджень. Прикладом може бути адаптивна мережева маршрутизація для прискорювачів FHE: впровадження механізму маршрутизації, який динамічно коригує шляхи даних між прискорювачами FHE на основі обчислювального навантаження в реальному часі та мережевого трафіку. Це забезпечить оптимальну швидкість передачі даних і ефективне використання ресурсів.

Висновок

FHE фундаментально переосмислить спосіб захисту даних на різних платформах, відкриваючи шлях до нової ери безпрецедентної конфіденційності. Для побудови такої системи знадобляться значні прогреси не тільки в ПТЕ, але й у ЗКП та ГДК.

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

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

Особлива подяка:

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

Відмова від відповідальності:

1. Цю статтю передруковано з [HashKey Capital]. Усі авторські права належать оригінальному автору [Jeffrey Hu、Arnav Pagidyala]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.