Автор: Zuo Ye
Основна лінія розвитку криптовалюти надзвичайно зрозуміла: біткойн створив публічні ланцюжки, TEDA створив безстрокові контракти. Існує безліч міфів про збагачення , або децентралізовані мрії, які завжди запам'ятовуються людям.
Траєкторія розвитку технології шифрування не зрозуміла. Різноманітні консенсусні алгоритми та різноманітні вишукані конструкції не підходять для систем стейкингу та мультипідпису, і остання є справжньою опорою для підтримки роботи системи шифрування, наприклад, після децентралізованої заставу WBTC відкликано, більшість BTC L2 не може існувати, а рідна ставка Babylon — це дослідження в цьому напрямку, дослідження вартістю 70 мільйонів доларів США.
У цій статті я намагаюся окреслити історію розвитку технології шифрування, яка відрізняється від різноманітних технологічних змін у галузі шифрування, таких як зв’язок між FHE, ZK і MPC. З грубого процесу застосування MPC використовується для початку, FHE Його можна використовувати в проміжному процесі розрахунку, а з точки зору часу застосування ZK був першим, який був реалізований. Після цього концепція MPC була оцінена як технічне рішення і його розробка прискорилася тільки в 2020 році. Вже заговорений Богом, але лише трохи загорівся в 2024 році.
MPC/FHE/ZKP
На відміну від ZK і MPC, FHE навіть відрізняється від усіх поточних алгоритмів шифрування. За винятком FHE, будь-яка технологія симетричного або асиметричного шифрування намагається створити «криптографічну систему, яку непросто або неможливо зламати», щоб досягти абсолютної безпеки, але. Мета FHE полягає в тому, щоб змусити зашифрований шифртекст працювати, тобто шифрування та дешифрування важливі, але після шифрування вміст до дешифрування не повинен витрачатися даремно.
Теорія завершена, Web2 реалізовано перед Web3
FHE є базовою технологією, і теоретичні дослідження були завершені в академічних колах, такі гіганти Web2, як Microsoft, Intel, IBM і Duality за підтримки DARPA, які підготували інструменти для адаптації та розробки програмного забезпечення.
Хороша новина полягає в тому, що гіганти Web2 не знають, що робити з FHE. Ще не пізно запустити Web3. Інша погана новина полягає в тому, що адаптація Web3 становить близько 0. Основні Bitcoin та Ethereum. вони нативно сумісні з алгоритмом FHE. Хоча Ethereum є світовим комп’ютером, жорсткий розрахунок FHE, ймовірно, закінчиться наприкінці світу.
Ми в основному зосереджуємось на вивченні Web3, просто пам’ятайте, що гіганти Web2 з великим ентузіазмом ставляться до FHE і вже зробили багато підготовчої роботи.
Це тому, що Віталік з 2020 по 2024 роки зосереджений на ЗК.
Тут я хотів би коротко пояснити свою популярність ZK після того, як Ethereum запровадив маршрут розширення Rollup, функція стиснення стану ZK може значно зменшити розмір даних, що передаються з L2 на L1, що, звичайно, має велике економічне значення Такі проблеми, як фрагментація L2 і сортувальник, і навіть деякі проблеми збору L2/зведених даних, є новими проблемами в розробці, і їх можна вирішити лише шляхом постійного розвитку.
Коротко кажучи, Ethereum має розширити свою потужність і створити маршрут розробки рівня 2 ZK/OP і Rollup, які конкурують за досконалість, формуючи галузевий консенсус щодо короткострокових OP і довгострокових ZK, формуючи чотирьох гігантів ARB/. OP/zkSync/SatrkNet.
Економіка є важливою причиною або навіть єдиною причиною прийняття ZK у криптосвіті, особливо в системі Ethereum, тому ми не будемо детально описувати наступні технічні характеристики FHE який FHE може підвищити ефективність роботи Web3, або Щоб зменшити експлуатаційні витрати Web3, завжди потрібно враховувати зниження витрат і підвищення ефективності.
Коротка історія та досягнення розвитку ФХЕ
Перший полягає в тому, щоб розрізнити гомоморфне шифрування і повністю гомоморфне шифрування. Власне кажучи, гомоморфне шифрування означає, що «додавання або множення відкритого тексту». розрахунок», тобто:
Наразі c і E(c), d і E(d) можна розглядати як еквівалентні значення, але зауважте, що тут є дві труднощі:
Рівність відкритого тексту та зашифрованого тексту фактично означає, що після додавання деякого шуму до відкритого тексту, зашифрований текст буде отримано шляхом виконання над ним операцій, якщо значення відхилення, спричинене зашифрованим текстом, буде невдалим алгоритми управління шумом є ;
Накладні витрати на додавання та множення є величезними, а обчислення зашифрованого тексту може бути від 10 000 до більш ніж 1 мільйона разів більшим, ніж обчислення відкритого тексту. Тільки коли можна досягти необмеженої кількості обчислень зашифрованого тексту додавання та множення, це можна назвати повністю гомоморфним шифруванням. Звичайно, всі типи гомоморфного шифрування також мають свою унікальну цінність у відповідних областях, їх можна розділити наступним чином:
Частково гомоморфне шифрування: із зашифрованими даними можна виконувати лише обмежений набір операцій, наприклад додавання чи множення. Дещо гомоморфне шифрування: дозволяє обмежену кількість операцій додавання та множення.
Повністю гомоморфне шифрування: дозволяє необмежену кількість операцій додавання та множення, таким чином уможливлюючи довільні обчислення зашифрованих даних.
Розвиток повністю гомоморфного шифрування (FHE) можна простежити до 2009 року. Крейг Гентрі вперше запропонував повністю гомоморфний алгоритм на основі ідеальної решітки. Ідеальна решітка — це математична структура, яка дозволяє користувачам визначати набір точок у багатовимірному просторі. простір, де ці точки задовольняють певну лінійну залежність.
У рішенні Gentry ідеальна решітка використовується для представлення ключа та зашифрованих даних, щоб зашифровані дані залишалися конфіденційними, а використання початкового завантаження для зменшення шуму можна розуміти як «сильно потягніть шнурки», «переверніться». " У фактичній роботі зашифрований текст, зашифрований FHE, знову шифрується для зменшення шуму та збереження конфіденційності, таким чином підтримуючи складні обчислювальні операції.
(Бутстрапінг є дуже важливим технічним прогресом для практичного застосування FHE, але математичні знання більше не розширюються)
Цей алгоритм є важливою віхою в інженерній справі. Однак його вартість є величезною, а для розрахунку одного кроку практично немає можливості.
Після вирішення задачі від 0 до 1 залишається масштабна практичність, яку також можна розуміти як виконання відповідного дизайну алгоритму на основі різних математичних припущень, крім ідеальних випадків, також використовується LWE (Learning with Error). для припущень безпеки ) та його варіанти наразі є найпоширенішим рішенням.
У 2012 році Цвіка Бракерскі, Крейг Гентрі та Вінод Вайкунтатан запропонували схему BGV, яка є однією зі схем FHE другого покоління. Її найважливішим внеском є технологія аналого-цифрового перетворення, яка ефективно контролює проблеми, викликані гомоморфними операціями. Шум зашифрованого тексту збільшується, таким чином будуючи вирівняний FHE, тобто такий FHE може досягати гомоморфних обчислювальних завдань на заданій глибині обчислення.
Подібні рішення включають BFV і CKKS. Зокрема, рішення CKKS може підтримувати операції з плаваючою комою, але це ще більше збільшить споживання обчислювальних ресурсів, і все ще потрібні кращі рішення.
Нарешті, є схеми TFHE і FHEW, особливо схема TFHE, якій Zama віддає перевагу. Простіше кажучи, проблема шуму FHE може бути зменшена шляхом початкового завантаження, застосованого вперше Gentry, і TFHE. може це зробити.
Ми щойно представили кожне рішення. Насправді різниця між ними полягає не в перевагах і недоліках, а в різних сценаріях .Проблема може бути застосована лише у великому масштабі. Це означає, що спочатку «алгоритми та програмне забезпечення» повинні розвиватися одночасно з апаратним забезпеченням початку, принаймні в області шифрування.
Web 2 OpenFHE проти Web3 Zama
Як згадувалося раніше, всі гіганти Web2 досліджують і досягли певних практичних результатів. Тут ми підсумовуємо їх і представляємо сценарії застосування Web3.
Щоб спростити речі, IBM внесла бібліотеку Helib, яка в основному підтримує BGV, а бібліотека Microsoft SEAL підтримує в основному рішення CKKS і BFV. Варто згадати, що Song Yongsoo, один із авторів CKKS, брав участь у проектуванні та розробці SEAL. , і OpenFHE є найбільшою. Майстер, розроблений Duality за підтримки DARPA, наразі підтримує основні алгоритми, такі як BGV, BFV, CKKS, TFHE та FHEW. За оцінками, це найповніша бібліотека FHE на ринку.
Крім того, OpenFHE також досліджував співпрацю з бібліотекою прискорення процесора Intel і викликом інтерфейсу CUDA від NVIDIA для підтримки прискорення графічного процесора. Однак остання підтримка CUDA для FHE була в 2018 році, і якщо є будь-яка помилка, . будь ласка, виправте мене.
OpenFHE підтримує C++ і Python, Rust API знаходиться в стадії розробки, і націлений на забезпечення простої та всебічної модульності та крос-платформних можливостей. Якщо ви розробник Web2, це найпростіше готове рішення.
Якщо ви розробник Web3, це буде складніше.
Через слабку обчислювальну потужність більшість публічних ланцюжків не можуть підтримувати виконання алгоритму FHE. По-друге, в екосистемі біткойн і Ethereum наразі відсутній «економічний попит» на FHE L1 Потреба в ефективній передачі даних надихнула реалізацію алгоритму ZK на користь FHE. Це забивання цвяхів і примусове узгодження, що лише збільшить вартість впровадження.
Як працює FHE+EVM
У наступній статті будуть детально описані поточні труднощі та можливі сценарії впровадження. Ця стаття надає певної впевненості розробникам Web3.
У 2024 році Zama отримала найбільше концептуальне фінансування у сфері шифрування, причому 73 мільйони доларів США на чолі з Multicoin наразі має бібліотеку алгоритмів на основі TFHE, а потім fhEVM, яка підтримує розробку EVM-сумісних ланцюжків із функціями FHE. на ньому.
По-друге, існує проблема ефективності, яка може бути вирішена лише через співпрацю програмного забезпечення та апаратного забезпечення. Одна з них полягає в тому, що EVM не може безпосередньо виконувати контракт FHE. Це не суперечить власному ланцюжку Zama. який може безпосередньо додати функцію FHE. Наприклад, Shiba Inu також хоче створити рівень 3 на основі рішення Zama Можливість розгортання контрактів FHE вимагає підтримки Ethereum Opcode (операційного коду). Хороші новини Fair Math і OpenFHE спільно організували конкурс FHERMA, щоб заохотити розробників переписати код операцій Ethereum, який можна вважати активним вивченням можливості інтеграції.
Інший — апаратне прискорення. Можна сказати, що навіть якщо високопродуктивні загальнодоступні ланцюги, такі як Solana, підтримують розгортання контракту FHE, їхні вузли будуть перетягнені до смерті. ), який є ASIC, також досліджують можливість апаратного прискорення. Наприклад, поточний TPS у Zama становить близько 5, Inco вважає, що за допомогою апаратного прискорення FPGA можна прискорити TPS. приблизно до 100-1000.
Але немає необхідності надто турбуватися про проблему апаратного прискорення ZK, яка теоретично може бути модифікована для адаптації до рішення FHE і вирішує проблеми сумісності з EVM.
Dark pool і jade мертві, у FHE X Crypto світле майбутнє
Коли Multicoin очолював інвестиції в Zama, було сказано, що ZKP — це минуле, а майбутнє належить FHE. Після того, як Zama Network і Fhenix створили екологічний невидимий альянс, кожна з яких. власний фокус і шлях, в основному той самий, тобто спрямований на інтеграцію FHE та EVM екології.
Краще зробити це раніше, ніж пізніше.
2024 рік може бути великим роком для FHE, але Elusiv, який почав працювати в 2022 році, припинив роботу Elusiv спочатку був протоколом «темного пулу» на Solana, а тепер базу коду та документацію видалено.
Зрештою, FHE, як частину технічних компонентів, все ще потрібно використовувати разом з такими технологіями, як MPC/ZKP, і нам потрібно дослідити, як FHE може змінити поточну парадигму блокчейну.
Перш за все, ми повинні визнати, що невірно просто думати, що FHE підвищить конфіденційність і, отже, матиме економічну цінність. Судячи з минулої практики, користувачі Web3 або мережі не дуже піклуються про конфіденційність і використовуватимуть лише релевантні. інструменти, коли конфіденційність може забезпечити економічну цінність, наприклад , хакери використовуватимуть Tornado Cash, щоб приховати вкрадені кошти, тоді як звичайні користувачі використовуватимуть лише Uniswap, оскільки використання Tornado Cash призведе до додаткових витрат часу або економічних витрат.
Вартість шифрування FHE сама по собі є додатковим тортуром і без того слабкої ефективності роботи в ланцюжку. Лише тоді, коли це збільшення вартості принесе більш значні переваги, захист конфіденційності можна просувати у великих масштабах, наприклад, у напрямку RWA? Випуск і торгівля облігаціями Наприклад, у червні 2023 року Bank of China International випустив «Цифрові структуровані ноти Blockchain» клієнтам Азіатсько-Тихоокеанського регіону через UBS, і в прес-релізі UBS зазначено, що це було здійснено через Ethereum, але. Чарівним чином Адресу договору та адресу розповсюдження транзакції неможливо знайти. Якщо хтось може їх знайти, додайте відповідну інформацію.
Цей приклад може чітко проілюструвати важливість FHE для інституційних клієнтів, які мають потребу використовувати загальнодоступні ланцюжки, такі як блокчейн, але не підходять або хочуть розкривати всю інформацію, FHE може відображати зашифрований текст і безпосередньо характеристики операцій, таких як покупка та. продам підійде більше ЗКП.
Для індивідуальних роздрібних інвесторів я можу перерахувати кілька напрямків, що лежать в основі, як-от боротьба з MEV, безпечніші мережі, запобігання стеженню третьої сторони тощо -попит на час, і використання FHE зараз справді сповільнить роботу мережі. Краще відверто сказати, що головний момент FHE ще не настав.
Зрештою, конфіденційність — це тривіальна потреба. Оскільки це державна служба, нам потрібно знайти сценарії, коли обчислювальні властивості даних, зашифрованих за допомогою FHE, можуть заощадити витрати або підвищити ефективність транзакцій. створення ринку Спонтанний підйом. Наприклад, існує багато рішень проти MEV. Наприклад, централізовані вузли насправді не можуть вирішити проблему.
Інша проблема — це питання ефективності обчислень. На перший погляд, це технічна проблема, яка вимагає апаратного прискорення або оптимізації алгоритму, але, по суті, на ринку немає великого попиту, і сторона проекту не має мотивації його вдосконалювати. Зрештою, розгортаємо обчислювальну систему. Візьмемо як приклад ZK. Різні маршрути ZK наполегливо працюють над розробкою мов програмування до сумісності прискорено розвиток ЗК.
Сценарії застосування та реалізація — це прорив для FHE, щоб стати інфраструктурою блокчейну. Якщо FHE не зможе зробити цей крок, FHE ніколи не зможе набрати обертів у галузі шифрування, а основні учасники проекту зможуть лише грати осторонь і працювати. на свій розсуд.
Судячи з практики Зами та його друзів, консенсус полягає в тому, щоб побудувати новий ланцюжок за межами Ethereum і повторно використовувати на ньому технічні компоненти та стандарти, такі як ERC-20, щоб сформувати схему шифрування для FHE L1/L2 для зв’язку з Ethereum Перевага цього рішення полягає в тому, що його можна спочатку спробувати та створити базові компоненти FHE. Недоліком є те, що якщо сам Ethereum не підтримує алгоритм FHE, то рішення поза ланцюгом завжди буде в незручній ситуації.
Сама Zama також усвідомлює цю проблему, окрім згаданих вище бібліотек класів, пов’язаних із FHE, вона також запустила організацію FHE.org і спонсорувала відповідні конференції, сподіваючись перетворити більше академічних результатів у інженерні програми.
Напрямок розвитку мережі Inco — це «універсальний рівень конфіденційності», який, по суті, є моделлю постачальника послуг обчислювальної техніки. Він будує мережу FHE EVM L1 на основі Zama інтегрувати інше Механізм гри в EVM-сумісному ланцюжку розгортається на Inco. Коли під час роботи гри потрібне обчислення FHE, обчислювальна потужність Inco викликається через Hyperlane, а потім лише результати передаються назад до оригінального ланцюжка.
Щоб реалізувати сценарій, передбачений Inco, необхідно, щоб EVM-сумісний ланцюжок був готовий довіряти репутації Inco, а власна обчислювальна потужність Inco повинна бути достатньо сильною операції досить складні.
Крім того, деякі zkVM можуть виконувати роль аутсорсинга FHE. Наприклад, RISC Zero вже має таку можливість.
Крім того, деякі проекти сподіваються трохи наблизитися до Ethereum, принаймні в напрямку того, щоб стати частиною Ethereum. Inco може використовувати рішення Zama для впровадження L1, а Fhenix може використовувати рішення Zama для впровадження EVM L2, яке все ще знаходиться на стадії розробки. , здається, є багато напрямків, у яких він хоче піти. Я не знаю, який продукт врешті-решт буде реалізовано. Можливо, це буде L2, який зосереджуватиметься на можливостях FHE.
Крім того, є згаданий вище конкурс FHERMA. Читачі, які є досвідченими в розробці Ethereum, можуть спробувати його впровадження FHE і водночас отримати бонуси.
Крім того, є ще два чудові проекти, Sunscreen і Mind Sunscreen, в основному керовані Ravital, щоб створити компілятор, який підходить для FHE і експериментувати протягом тривалого часу, і це все ще далеко від практичності Це займе час.
Нарешті, ідеї Mind Network зосереджені в основному на поєднанні FHE та різних існуючих сценаріїв, таких як переставлення, але перевірка того, як це реалізувати, потребує часу.
Нарешті, нагадаємо початок цього розділу, Elusiv тепер перейменовано в Arcium, також отримав нове фінансування та перетворено на «паралельне FHE» рішення. Це має покращити FHE з точки зору ефективності.
Висновок
Ця стаття, здається, говорить про теорію та практику FHE, але прихована лінія полягає в тому, щоб прояснити історію розвитку самої технології шифрування. Це не зовсім еквівалентно технології, яка використовується в криптовалюті, і FHE мають багато подібностей Щоб зберегти дизайн конфіденційності, зберігаючи загальнодоступний характер блокчейну, рішення конфіденційності ZKP спрямоване на зниження економічної вартості взаємодії між L2 <> L1, тоді як FHE все ще шукає своє власний найкращий сценарій.
Види планів
Попереду довгий шлях, і FHE все ще досліджує. Його можна розділити на три типи за ступенем зв'язку з Ethereum:
Тип 1: Незалежне королівство, що спілкується з ефіром. Представлена мережею Zama/Fhenix/Inco, вона головним чином забезпечує базові компоненти для розробки та заохочує самостійне створення FHE L1/L2, що підходить для певних сегментів;
Тип 2: підключіть його та інтегруйте в Ethernet. Представлена Fair Math/Mind Network, хоча вона зберігає певний ступінь незалежності, загальна ідея полягає в досягненні глибшої інтеграції з Ethereum.
Тип 3: Зустрітися один з одним і перетворити ефір. Якщо Ethereum не може підтримувати функцію FHE, її потрібно вивчити на рівні контракту, щоб розповсюдити функцію FHE на різні ланцюжки, сумісні з EVM. Наразі немає рішення, яке б повністю відповідало цьому стандарту.
На відміну від ZK, який на пізніх стадіях розробки бачив лише випуск ланцюга одним клацанням миші та апаратне прискорення, FHE стоїть на плечах гігантів ZK. Тепер, можливо, найпростіше надіслати ланцюг FHE, але як спілкуватися між собою та Ethereum є найскладнішим.
Оглядайте себе тричі на день і шукайте майбутні координати FHE у світі блокчейнів:
Які сценарії мають бути зашифровані та не можуть використовувати відкритий текст?
Які сценарії вимагають шифрування FHE, але не можуть використовувати інші методи шифрування?
За яких сценаріїв користувачі почуватимуться добре від використання шифрування FHE та будуть готові платити більше?
Продовження буде, я й надалі буду звертати увагу на FHE!
