Кожна велика дорога проходить MPC? Дослідження кінцевої точки інфраструктури конфіденційності

Автор: EQ Labs Джерело: рівновага Переклад: Шан Оу Ба, Golden Finance

Наша серія приватності, частина 1, розглядає значення “приватності”, відмінність приватності в мережі Блокчейн від приватності в web2, а також причини, чому важко досягти приватності в Блокчейн.

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

Звільніться від минулого обмеження та зустрічайте майбутнє

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

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

• Прихований стан: У більшості фінансових випадків вимагається (принаймні) збереження конфіденційності перед іншими користувачами, і без деякого прихованого стану багато ігор для багатьох людей втратять свою привабливість (наприклад, якби кожен гравець за покерним столом міг бачити карти інших гравців).
• Схована логіка：деякі сценарії вимагають сховати деяку логіку, при цьому дозволяючи іншим користувачам використовувати додаток, наприклад,механізм сумістності, у блокчейні стратегії торгівлі тощо.

Емпіричний аналіз (з web2 і web3) показує, що більшість користувачів не бажають платити додаткову плату або пропускати додаткові етапи для збільшення конфіденційності, і ми також погоджуємось, що сама приватність не є рекламним моментом. Однак, вона дійсно дозволяє новим та (сподіваємося) більш значущим використанням існувати на основі блокчейну - дозвольте нам уникнути фермівського парадоксу.

Технології підвищеної конфіденційності (PET) та сучасні рішення з шифрування * («Програмованість шифрування») * є основними будівельними блоками для досягнення цього бачення * (для отримання додаткової інформації про різні наявні рішення та їх збалансованість, див. Додаток *) .

Три припущення, що впливають на нашу точку зору

Три ключові припущення визначають наше бачення розвитку інфраструктури приватності блокчейну:

1. Технологія шифрування буде абстрагована від рук розробників додатків: Більшість розробників додатків не хочуть (або не знають, як з цим впоратися) з технологією шифрування, необхідною для забезпечення конфіденційності. Нерозумно очікувати, що вони впроваджуватимуть власну технологію шифрування та створюватимуть приватні ланцюжки додатків* (наприклад, Zcash або Namada) або приватні додатки поверх публічних мереж (наприклад, Tornado Cash). Це просто занадто складно і накладно, і в даний час обмежує простір дизайну для більшості розробників (неможливість створювати додатки, які вимагають певної конфіденційності). Тому ми вважаємо, що важливо абстрагуватися від складності управління частиною шифрування з рук розробників додатків. Тут використовуються два підходи: Програмованість інфраструктури конфіденційності (спільний приватний L1/L2) або «секрет як послуга», що дозволяє передавати конфіденційні обчислення на аутсорсинг.
2. Багато випадків (мабуть, більше, ніж ми уявляємо) потребують спільного доступу до приватного стану: як вже зазначалося, багато додатків потребують деякого схованого стану та/або логіки для нормальної роботи. Спільний доступ до приватного стану є підмножиною цього, де лонгуючий обчислюється для одного й того ж приватного стану. Хоча ми можемо довіряти централізованому суб’єкту зробити це за нас і залишитися задоволеними цим, але в ідеальному випадку ми хочемо зробити це за допомогою мінімізації довіри, щоб уникнути однієї точки відмови. Тільки за допомогою Доказу із нульовим розголошенням (ZKP) не вдасться досягти цього - нам потрібно використовувати інші інструменти, такі як довірена виконавча середа (TEE), повне Гомоморфне шифрування (FHE) та/або лонгуючий обчислення (MPC).
3. Більші шеренги фільтрів можуть найбільш ефективно захистити приватність: більшість інформації може витікати при вході або виході з фільтрів, тому ми маємо намагатися мінімізувати такі ситуації. Побудова кількох приватних додатків на одному блокчейні може допомогти зміцнити захист приватності, збільшивши кількість користувачів та транзакцій у межах однієї шеренги фільтрів.

Завершення приватної інфраструктури

Враховуючи вищезазначені припущення, яка є кінцевою метою інфраструктури конфіденційності Блокчейну? Чи існує метод, який підходить для всіх додатків? Чи існує технологія підвищення конфіденційності, яка може об’єднати всі додатки?

Не цілком так. Усі вони мають різні компроміси, і ми бачили, як вони по-різному поєднуються. В цілому, ми виявили 11 різних способів.

Наразі двома найпопулярнішими методами побудови приватної інфраструктури в блокчейні є використання ZKP або FHE. Однак, обидва методи мають фундаментальні недоліки:

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

Якщо ідеальний кінцевий стан - це наявність Програмованість інфраструктури конфіденційності, яка може обробляти спільний приватний стан * без будь-яких одночасних помилок *, тоді дві шляхи можуть привести до MPC:

Зверніть увагу, що, незважаючи на те, що в кінцевому підсумку ці два методи будуть злиті, MPC має різні застосування:

• ZKP мережа: MPC збільшує можливості виразності, реалізовуючи обчислення спільного приватного стану.
• FHE мережа: MPC підвищує безпеку та забезпечує конфіденційність, розподіляючи Секретний ключ для розшифрування між комітетом MPC (а не окремими сторонами).

Незважаючи на те, що обговорення розпочало переходити до більш деталізованих точок зору, гарантії за цими різними методами все ще не були належним чином досліджені. Оскільки наше припущення про довіру сводиться до припущення про MPC, три ключові питання, які потрібно висунути, полягають у наступному:

1. Наскільки міцним є протокол MPC для забезпечення конфіденційності в Блокчейні?
2. Чи достатньо розвинена технологія? Якщо ні, то які є перешкоди?
3. З урахуванням міри гарантій та витрат, чи має воно сенс порівняно з іншими методами?

Давайте докладніше відповімо на ці питання.

Використання MPC для аналізу ризиків та слабких місць

Кожного разу, коли вирішення використовує FHE, люди завжди запитують: “Хто володіє секретним ключем Секретний ключ?”. Якщо відповідь - “мережа”, то наступне питання: “Які реальні сутності складають цю мережу?”. Останнє питання пов’язане з усіма випадками використання MPC у якості певної форми залежності.

Джерело інформації: Доповідь Zama на ETH CC

Основним ризиком MPC є змова, тобто злочинна домовленість достатньої кількості учасників щодо розшифрування даних або крадіжки обчислень. Змову можна досягти поза блокчейном і вона розкривається тільки тоді, коли злочинна сторона вчиняє якісь очевидні дії (вимагає викуп, незаконно мінтує Токени тощо). Безумовно, це має серйозний вплив на приватність, яку система може забезпечити. Ризик змови залежить від:

• Яку кількість зловмисних сторін може витримати цей протокол?
• З яких сторін складається мережа? Яка їхній рівень довіри?
• Кількість та розподіл різних сторін у мережі - чи існує загальноприйнятий засіб атаки?
• Чи потрібне дозвіл для мережі (економічні вигоди та репутація / правова основа)?
• Яким є покарання за злочинну поведінку? Чи є спілкування та гра вигідним результатом в теорії?

1. Яку силу забезпечення конфіденційності може надати протокол MPC в Блокчейні?

TLDR: не така потужна, як нам б хотілося, але потужніша, ніж залежність від централізованої третьої сторони.

Для розшифрування необхідний поріг залежить від обраної схеми MPC - в значній мірі це баланс між активністю* («гарантована доставка виводу») * та безпекою. Ви можете вибрати дуже безпечну схему N/N, але якщо одна Нода вийде з ладу, вона зазнає аварії. З іншого боку, схема N/2 або N/3 є більш надійною, але має вищий ризик змови.

Два умови, які потрібно збалансувати:

1. Секретна інформація ніколи не буде розголошена (наприклад, розшифруйте Секретний ключ)
2. Секретна інформація ніколи не зникне (навіть якщо 1/3 учасників раптово залишаться).

Обраний план відрізняється від реалізації. Наприклад, метою Zama є N/3, тоді як Arcium наразі реалізує план N/N, але пізніше підтримає плани з більш високими гарантіями активності (і більшими передпосилками довіри).

На цій межі компромісом є використання змішаного підходу:

• Високодовірний комітет виконує обробку з Секретний ключ з використанням, наприклад, порогового значення N/3.
• • Комітет з обчислень * є ротаційним, наприклад, є N-1 поріг (або кілька різних комітетів з різними характеристиками для вибору користувача).

Хоча теоретично це дуже привабливо, але це також вносить додаткову складність, наприклад, як комітети обчислюють взаємодію з високими комітетами довіри.

Ще один спосіб забезпечення безпеки полягає в здійсненні MPC у відповідних апаратних засобах, щоб зберігати спільний Секретний ключ у безпечній області. Це робить видобуток або використання спільного Секретного ключа для будь-яких дій, окрім тих, які визначені протоколом, ще більш складним. Як мінімум, Zama та Arcium досліджують TEE підхід.

Більш витончені ризики включають такі крайні випадки, як соціальний інжиніринг, наприклад, у всіх компаніях групи MPC працює висококваліфікований інженер протягом 10-15 років.

2. Чи достатньо зріла технологія? Якщо ні, яка тут проблема?

З точки зору продуктивності основним викликом для MPC є витрати на зв’язок. Вони зростають разом зі складністю обчислень та збільшенням кількості Нода в мережі (потрібно більше обміну даними). Для використання в Блокчейні це може мати два практичні наслідки:

1. Малий набір операторів: щоб зробити комунікаційні витрати контрольованими, більшість наявних протоколів наразі обмежені малим набором операторів. Наприклад, мережа розшифровки Zama наразі дозволяє максимум 4 вузла (хоча планується розширення до 16). За початковими бенчмарками, опублікованими Zama для своєї мережі розшифровки (TKMS), розшифровка навіть з вузловим кластером з 4 вузлів займає 0,5-1 секунди (повний е2е процес займає більше часу). Іншим прикладом є MPC, реалізований Taceo для бази даних ірисів Worldcoin, яка має 3 сторони (за умови, що 2/3 є чесними).

Джерело інформації: Доповідь Zama на ETH CC 2. 3. Набір ліцензованих операторів: у більшості випадків набір операторів є ліцензованим. Це означає, що ми розраховуємо на репутацію та юридичні контракти, а не на економічну чи шифрування безпеку. Головним викликом безліцензного набору операторів є неможливість з’ясувати, чи вступають люди в поза блокчейном співпрацю. Крім того, це вимагає регулярного керівництва або перерозподілу часток ключів, щоб Нода могла динамічно входити в/виходити з мережі. Хоча безліцензний набір операторів є кінцевою метою та вивчається можливість розширення механізму PoS для досягнення порогового значення MPC (наприклад, Zama), але наразі дозволений шлях здається найкращим напрямком руху.

Альтернативні методи

Повний набір конфіденційності включає:

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

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

Це варто? Можливо варто, але також варто розглянути інші методи, які можуть забезпечити значно кращу обчислювальну ефективність, за дещо меншої гарантії конфіденційності. Як зазначив Лайрон з Seismic - ми повинні фокусуватися на найпростіших рішеннях, щоб відповідати стандартам нашого необхідного рівня конфіденційності та прийнятних компромісів, а не перебувати в перебудові лише для цього.

1. Пряме використання MPC для загальних обчислень

Якщо ZK і FHE врешті-решт повернуться до довіри MPC, чому б не використовувати прямо MPC для обчислень? Це розумне питання, і це те, над чим працюють команди Arcium, SodaLabs (Coti v2 використовує), Taceo та Nillion. Зверніть увагу, що MPC має кілька форм, але в рамках трьох основних методів ми маємо на увазі протоколи, засновані на секретному розподілі та гарбузових мережах (GC), а не на протоколах з використанням FHE для розшифрування.

Хоча MPC вже використовується для розподілених підписів та більш безпечних Гаманець та інших простих обчислень, основним викликом використання MPC для загальних обчислень є витрати на комунікацію (які зростають зі збільшенням складності обчислень та кількості Нод, включених у процес).

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

Таблиця нижче показує, скільки часу потрібно для виконання різних Код операції 1,000 разів у початковому Бенчмарк * (у мікросекундах) у gcEVM від SodaLabs. * Хоча це є кроком у правильному напрямку, все ще є багато роботи, щоб покращити ефективність та розширити набір операторів поза кількома Нода.

Джерело: SodaLabs

Перевагою ZK-базового підходу є те, що ви використовуєте MPC лише для випадків обчислень у спільному приватному стані. Змагання між FHE та MPC більш пряме і сильно залежить від апаратного прискорення.

2. Довірена виконавча середовище

Нещодавно виникло знову зацікавлення TEE. Воно може використовуватися окремо (на основі приватного блокчейну або спільного процесора на основі TEE), або поєднуватися з іншими PET (наприклад, на основі ZK-рішень) для обчислення спільного приватного стану, використовуючи лише TEE.

Хоча TEE в деяких аспектах є більш зрілим і має менше введення продуктивності, вони все ж мають свої недоліки. По-перше, TEE має різні припущення щодо довіри (1/N) і пропонує апаратне, а не програмне рішення. Звичайна критика стосується минулих вразливостей SGX, але варто зауважити, що TEE ≠ Intel SGX. TEE також потребує довіри до постачальника апаратного забезпечення, а апаратне забезпечення є дорогим (більшість людей не може собі це дозволити). Одним з рішень для зменшення ризику фізичних атак може бути використання TEE в космосі для обробки важливих завдань.

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

3. Приватні DAC та інші методи, які залежать від довірених третіх сторін для захисту конфіденційності

проміжне конфіденційності може забезпечити конфіденційність, запобігти доступу інших користувачів, але гарантія конфіденційності повністю ґрунтується на довірі до третьої сторони (однієї точки відмови). Хоча воно схоже на «веб2 конфіденційність» (запобігаючи доступу інших користувачів), воно може бути посилений за допомогою додаткових гарантій (шифрування або економіка) і дозволяє перевірку правильного виконання.

Комітет з доступності приватних даних (DAC) - це лише один приклад; його члени зберігають дані поза блокчейном, користувачі довіряють їм зберігати дані правильно та виконувати оновлення стану. Інша форма - це концесійний послідовник, запропонований Томом Уолпо.

Хоча цей метод робить величезні компроміси у сфері захисту приватності, але з погляду вартості та продуктивності він може бути єдиним життєздатним альтернативним рішенням для низькостатусних, високопродуктивних додатків (принаймні наразі). Наприклад, протокол Lens планує використовувати приватний DAC для реалізації приватного потоку інформації. Для випадків використання, таких як у блокчейні соціальні мережі, компроміс між приватністю та вартістю/продуктивністю наразі, можливо, є розумним (з урахуванням витрат та витрат альтернативних рішень).

4. Інкогніто адреса

Прихована адреса може забезпечити конфіденційність, схожу на створення нової адреси для кожної транзакції, але цей процес відбувається автоматично ззаду, і не розголошується користувачам. Для отримання додаткової інформації див. цей огляд Віталіка або цю статтю, що глибше розглядає різні підходи. Основні учасники в цій галузі включають Umbra та Fluidkey.

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

Крім того, конфіденційність, яку надає Адреса, не так потужна, як інші альтернативи. Анонімність може бути порушена простим кластерним аналізом, особливо коли вхідні та вихідні транзакції не вписуються в схожий діапазон (наприклад, отримання 10 000 доларів, але середні щоденні витрати на транзакції становлять 10-100 доларів). Ще одним викликом для Адреси є оновлення Секретний ключ, яке зараз потрібно виконати окремо для кожного гаманця (зберігання загальних Секретний ключів може допомогти вирішити цю проблему). З точки зору користувацького досвіду, якщо на рахунку немає Токену (наприклад, ETH), то протокол Адреси також потребує абстрагування рахунку або спонсора для оплати витрат.

Наші аргументи стикаються з ризиками

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

1. Поділена приватна статус не настільки важлива, як ми уявляємо: у цьому випадку більш ймовірно перемогу здобуде інфраструктура на основі ZK, оскільки вона має більш сильні гарантії приватності і нижчі витрати, ніж FHE. Вже є деякі випадки використання, які показують, що системи на основі ZK добре працюють у випадках ізольованого використання, наприклад, приватний платіжний протокол Payy.
2. Компроміс в продуктивності не вартий переваги конфіденційності: Деякі можуть сказати, що довіра до мережі MPC з 2-3 дозволеними сторонами майже не відрізняється від довіри до одного централізованого учасника, а значна збільшення витрат не варте того. Для багатьох додатків, особливо для додатків низької вартості, які чутливі до вартості (наприклад, соціальні мережі або ігри), це може бути правдою. Однак існує багато високоцінних випадків застосування, де співпраця в даний момент є дуже дорогою (або неможливою) через юридичні питання або велике узгодження. Останнє - місце, де MPC та рішення на основі FHE можуть блиснути.
3. Спеціалізація переважає загальний дизайн: побудова нового ланцюжка та керування спільнотою користувачів та розробників є дуже складними. Тому загальна інфраструктура конфіденційності (L1/L2) може бути складно підписатися. Ще одна проблема стосується спеціалізації; одночасний дизайн протоколу важко охоплює всі простори компромісів. У цьому світі рішення щодо конфіденційності для існуючої екосистеми (наприклад, послуги конфіденційності) або для конкретного випадку використання (наприклад, платежі) матимуть перевагу. Однак ми ставимося до останнього з певним сумнівом, оскільки це призводить до складності для розробників додатків, які повинні реалізувати деякі шифрувальні технології (замість абстрагування їх).
4. Регулювання продовжує утруднювати експерименти з приватними рішеннями: для будь-якої особи, яка будує інфраструктуру приватності та додатки з певними гарантіями приватності, це є ризиком. Нефінансові використання мають менший регуляторний ризик, але важко (якщо не неможливо) контролювати, що будується на інфраструктурі приватності без дозволу. Ймовірно, ми вирішимо технічні проблеми до вирішення проблем з регулюванням.
5. Для більшості випадків вартість рішень, заснованих на MPC та FHE, все ще залишається занадто високою: хоча MPC в основному страждає від витрат на зв’язок, команда FHE серйозно покладається на апаратне прискорення для підвищення продуктивності. Однак, якщо ми можемо зробити висновок щодо розвитку спеціалізованого апаратного забезпечення в галузі ZK, то час, необхідний для отримання придатного для виробництва апаратного забезпечення FHE, буде набагато довший, ніж більшість людей уявляють. Команди, які працюють над апаратним прискоренням FHE, включають Optalysys, fhela та Niobium.

Загальне

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

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

Проте не всі завдання потребують використання однакових інструментів для вирішення. Навіть якщо ми вважаємо, що MPC - це кінцева мета, поки вартість реалізації рішення, що працює на основі MPC, залишається високою, інші методи також є прийнятними виборами. Ми завжди повинні враховувати, який метод найбільш підходить для конкретних вимог/особливостей завдання, яке ми намагаємося вирішити, а також які компроміси ми готові прийняти.

Навіть якщо у вас є найкращий молоток у світі, це ще не означає, що все - це цвяхи.