Безпека та продуктивність SNARK

SNARK (Succinct Non-interactive Argument of Knowledge) — це криптографічний інструмент, який відкриває захоплюючі нові можливості в системному проектуванні, особливо в децентралізованих налаштуваннях. SNARK дозволяють обробляти дані ненадійним особам, які потім можуть довести, що дані дійсні та оброблені правильно. Наївним способом довести це було б опублікувати дані, дозволивши кожному, хто бажає, перевірити їх достовірність і безпосередньо обробляти. 

SNARK досягає такого ж ефекту, але дешевшеs до валідаторів. Наприклад, у верифікованому зведенні рівня другого (L2) служба зведення обробляє транзакції блокчейну. Сервіс періодично публікує баланси рахунків своїх користувачів у блокчейні першого рівня. Кожного разу, коли він публікує оновлення балансів, він додає SNARK-підтвердження того, що йому відома послідовність дійсних транзакцій, які змінили старі баланси облікового запису на оновлені. Таким чином, валідаторам блокчейну не потрібно виконувати важку роботу з перевірки дійсності транзакцій (наприклад, перевіряти цифровий підпис для кожної транзакції), а також явно обробляти транзакції для обчислення оновлених балансів.  

My попередній публікації зосереджено на продуктивності пруверів SNARK – головному визначальному факторі застосовності SNARK. Хоча запуск перевірки SNARK може потребувати інтенсивних обчислень, оскільки неможливо створити доказ для великомасштабних обчислень, перевірка SNARK зазвичай набагато дешевша, ніж безпосередня перевірка та обробка даних. Однак витрати на перевірку SNARK значно відрізняються. Ця публікація розповідає про ці витрати та порівнює властивості безпеки різних SNARK. 

Зокрема, я пояснюю, що в практичних SNARK з вірогідною постквантовою безпекою (PQ-SNARK) існує значне протиріччя між безпекою та вартістю перевірки. Крім того, у деяких випадках цю напругу зараз вирішують на користь витрат на перевірку, а не на безпеку.

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

Кількісні заходи безпеки 

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

Рівень безпеки SNARK вимірюється обсягом роботи, яку необхідно виконати, щоб знайти переконливий доказ неправдивої заяви. Подібно до інших криптографічних примітивів, таких як цифрові підписи, логарифм цього обсягу роботи називають «бітами безпеки». Наприклад, 30 біт безпеки означає, що 2³⁰ Для атаки на SNARK потрібно ≈ 1 мільярд «кроків роботи». За своєю суттю це приблизний показник безпеки в реальному світі, оскільки поняття одного кроку роботи може відрізнятися, а практичні міркування, як-от вимоги до пам’яті чи можливості паралелізму, не враховуються.

І якісних

Частини безпеки - це a кількісний міра безпеки СНАРК. SNARK також відрізняються своїми якісний властивості безпеки. 

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

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

SNARK також відрізняються своєю сприйнятливістю до квантових атак. Зокрема, багато SNARK (наприклад, Грот16, PlonK, Marlin, Куленепробивні, Нова зірка) спираються на припущення, що дискретні логарифми важко обчислити (і в деяких випадках також на додаткові припущення). Обчислення дискретних логарифмів — це те, що квантові комп’ютери могли б ефективно робити. Отже, ці SNARK не є постквантово безпечними (не PQ). 

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

Поліноміальні зобов'язання

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

Одним із яскравих прикладів є т. зв КЗГ поліноміальні зобов'язання, якими користуються PlonK, Marlin, та багато інших. Зобов’язання KZG не є ані прозорими, ані постквантовими. Інші схеми зобов’язань є прозорими, але не постквантовими, зокрема Куленепробивні, Гіракс та соняшник. 

Ще інші схеми є водночас прозорими та ймовірно постквантовими. До них відносяться БЕЗКОШТОВНО, Лігеро, Ligero++, Гальмування та Orion. Усі ці схеми засновані на кодах з виправленням помилок. Хешування — єдиний криптографічний примітив, який вони використовують. Вони також мають таку властивість: вартість верифікації (вимірюється кількістю оцінок хешування та польових операцій) зростає лінійно зі збільшенням кількості бітів безпеки.

Грубо кажучи, одна «ітерація» цих постквантових поліноміальних зобов’язань забезпечує лише невелику кількість (скажімо, 2-4) бітів безпеки. Таким чином, протокол потрібно повторювати багато разів, щоб «підвищити» рівень безпеки, при цьому вартість перевірки зростає з кожним повторенням. Таким чином, щоб контролювати витрати на верифікацію в PQ-SNARK (і, отже, витрати на газ у блокчейн-додатках), розробники протоколів мають стимул підтримувати низький рівень безпеки. 

З рідкісними Винятки, ця напруга між конкретною безпекою та витратами на перевірку не виникає в SNARK, що не належать до PQ (як прозорих, так і непрозорих). Не-PQ-SNARK використовують групи еліптичних кривих, у яких дискретні логарифми вважаються складними для обчислення, а їхні рівні безпеки визначаються використовуваною групою. Розмір відповідної групи еліптичних кривих, а отже, і вартість кожної групової операції зростають разом із бажаним рівнем безпеки. Однак, номер елементів групи в доказі не залежать від вибору групи. 

У PQ-SNARK не тільки розмір хеш-оцінок зростає лінійно з бажаним рівнем безпеки, а й кількість оцінок, включених у доказ і виконаних верифікатором. 

Вартість конкретного верифікатора та безпека в розгорнутих SNARK

Вартість конкретного верифікатора та рівні безпеки розгорнутих SNARK значно відрізняються. Ось кілька наочних прикладів:

Витрати верифікатора 

My попередній публікації згадав два приклади конкретних витрат на перевірку: PlonK вартість доказів при 300,000 газ для перевірки на Ethereum, тоді як докази StarkWare коштують близько 5 мільйонів газу. Докази StarkWare є прозорими та правдоподібно постквантовими, а докази PlonK – ні. Однак, як детально описано далі, перевірки StarkWare виконуються на набагато нижчому рівні безпеки, ніж перевірки PlonK на Ethereum.

Бетонна безпека

Єдина еліптична крива з попередніми компіляціями Ethereum називається altbn128, тож це крива, яку використовують усі не-PQ SNARK, розгорнуті на Ethereum, у тому числі ацтекскійі с zkSync's. Спочатку вважалося, що ця крива — а отже й розгорнуті SNARK, які її використовують — забезпечує приблизно 128 біт безпеки. Але завдяки покращені атаки (точний час виконання якого є важко визначити), широко вважається, що крива забезпечує від 100 до 110 біт безпеки. 

Є ЕІП при розгляду щоб представити попередні компіляції для різних кривих, які, як і раніше, вважають, що пропонують близько 128 біт безпеки. Такі криві є вже використовується у SNARK проектів, не пов’язаних з Ethereum, зокрема ZCash, Algorand, Dfinity, Filecoin і Aleo. 

Навпаки, згідно з даними в мережі, PQ-SNARK від StarkWare (у так званій системі SHARP, скорочення від SHARed Prover) налаштовано на 80-бітний захист. Цей рівень безпеки зберігається за певних припущень щодо статистичної надійності FRI (про що я розповім пізніше в цій публікації). 

Термін «80 біт безпеки» розпливчастий у цьому контексті, тому дозвольте мені його розпакувати. Грубо кажучи, це означає, що зловмисник може створити переконливий доказ хибного твердження, оцінивши хеш-функцію 2⁸⁰ разів (а саме KECCAK-256, хеш-функція, яку використовує Ethereum). Точніше, зловмисник, який бажає виконати 2^k хеш-оцінки можуть дати переконливий доказ з імовірністю приблизно 2^K-80. Наприклад, з 2⁷⁰ хеш-оцінки, можна знайти «доказ» SNARK хибного твердження з імовірністю приблизно 2^-10 = 1/1024. 

Це поняття слабше, ніж те, що означає термін «80 біт безпеки» в інших контекстах. Наприклад, хеш-функція, стійка до зіткнень (CRHF), налаштована на 80 біт безпеки, створить 160-бітні виходи. Якщо хеш-функція добре розроблена, найшвидшою процедурою пошуку колізій буде Напад на день народження, процедура грубої сили, яка може знайти зіткнення приблизно з 2^160/2 = 2⁸⁰ хеш-оцінки. Проте з 2^k хеш-оцінки, атака Birthday виявить зіткнення з імовірністю лише 2^2к-160. 

Наприклад, 2 рік⁷⁰ хеш-оцінки дадуть зіткнення з імовірністю 2^-20  ≈ 1/1,000,000 1 1,000. Це набагато менше, ніж ймовірність 80/XNUMX того, що зловмисник підробить доказ PQ-SNARK, налаштований на XNUMX біт безпеки. 

Ця різниця може кардинально змінити привабливість виконання атаки. Для ілюстрації уявіть, що зловмисник має бюджет у 100 тис. доларів США, на який можна купити 2⁷⁰ хеш-оцінки. І припустімо, якщо зловмиснику це вдасться, виграш становитиме 200 мільйонів доларів. Очікувана вартість атаки проти PQ-SNARK, налаштованого на 80-бітну безпеку, становить (1/1,000) * 200 мільйонів доларів США, або 200 тисяч доларів США – це вдвічі більше. Якби ймовірність успіху була лише 1/1,000,000 200 XNUMX, як у випадку з CRHF, очікувана вартість атаки становила б лише XNUMX доларів. 

Два поняття «80 біт безпеки» також різко відрізняються своєю стійкістю до незалежних атак. Наприклад, припустимо, що 1,000 незалежних сторін атакують PQ-SNARK, виконуючи 2⁷⁰ хеш-оцінки. Оскільки кожен досягає успіху з імовірністю приблизно 1/1,000, принаймні один із них цілком імовірно досягне успіху. Це було б не так, якби кожен досяг успіху з імовірністю лише 1/1,000,000 XNUMX XNUMX.

Очікується, що добре розроблені групи еліптичних кривих поводитимуться подібно до CRHF, з атаками, схожими на день народження, такими як Алгоритм Ро Полларда будучи найвідомішим. Це означає, що в групі, яка пропонує 128 біт безпеки, 2^k групові операції повинні давати розв’язок прикладу задачі дискретного логарифмування з імовірністю лише 2^2к-256. Наприклад, 2⁷⁰ групові операції знайшли б дискретний логарифм лише з астрономічно малою ймовірністю 2^-116. Крім того, кожна групова операція повільніша, ніж оцінка CRHF. 

Скільки хеш-оцінок можливо сьогодні?

У січні 2020 року вартість обчислювальної техніки трохи перевищувала 2⁶⁴ Оцінки SHA-1 за допомогою GPU були $45,000. Це складає вартість 2⁷⁰ Оцінки SHA-1 для графічних процесорів на кілька мільйонів доларів (можливо, нижче після злиття з Ethereum, оскільки перехід від майнінгу доказів роботи, домінованого графічним процесором, ймовірно, зменшить попит на обчислення на графічному процесорі, знизивши їх вартість). 

Оскільки зведені дані вже зберігають сотні мільйонів доларів у фондах користувачів, пошук переконливого доказу неправдивої заяви може принести багато мільйонів доларів прибутку. Налаштування PQ-SNARK на 80 біт безпеки за умов агресивних припущень залишає менше 10 біт простору між прибутковими атаками та здогадною безпекою PQ-SNARK.

Як ще одна точка даних, хеш-рейт мережі Bitcoin наразі становить приблизно 2⁶⁴  хеш-оцінок за секунду, тобто біткойн-майнери в цілому виконують 2⁸⁰ Оцінки SHA-256 кожні 18 годин. Звичайно, ця вражаюча цифра пояснюється великими інвестиціями в ASIC для майнінгу біткойнів. 

Якщо припустити, шість блоків біткойн створених за годину, і враховуючи поточну винагороду за блок у 6.25 біткойна за блок, ці 2⁸⁰ Оцінки SHA-256 імовірно коштують менше 22,000 18 доларів США * 6 * 6.25 * 15 ≈ XNUMX мільйонів доларів США. Інакше майнінг біткойнів не був би прибутковим за поточних цін. 

Пропоновані дії для здорової екосистеми

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

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

Але з PQ-SNARK навіть експертам може бути важко визначити рівень безпеки розгорнутого протоколу з тієї самої причини, з якої безпека та продуктивність верифікатора є проблемними для цих SNARK: рівень безпеки (і вартість верифікатора) залежить від внутрішніх параметрів СНАРК. І принаймні для StarkWare розумні контракти, ці параметри, called logBlowupFactor, ​​proofOfWorkBits і n_Queries не вказуються безпосередньо в коді смарт-контракту, а передаються в смарт-контракт як публічні дані. Наскільки я знаю, найпростіший спосіб визначити ці параметри з інформації в ланцюжку — це виконати чотири етапи: 

1. переглянути відповідний смарт-контракт у провіднику блоків, наприклад Etherscan, 
2. натисніть на відповідну транзакцію «перевірити підтвердження»., 
3. декодувати вхідні дані транзакції та
4. з'ясувати, як це зробити інтерпретувати декодовані вхідні дані, щоб дізнатися ключові параметри SNARK, які разом визначають рівень безпеки. 

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

Пропозиція 1: Перевірка 

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

Пропозиція 2: посилення норм

80 біт безпеки є занадто низьким, особливо слабка версія, в якій 2⁷⁰ хеш-оцінок достатньо для успішної атаки з імовірністю приблизно 1/1000 — навіть більше, враховуючи довгу історію несподіваних атак на криптографічні примітиви. Одна з них, згадана вище, полягає в кращих атаках на еліптичні криві, зручні для створення пар, такі як altbn128. Більш відомим прикладом є SHA-1, який був стандартизований на 80 біт безпеки, але зрештою було показано, що досягає лише близько 60 біт. З огляду на цю історію, розробники PQ-SNARK повинні залишити собі більше ніж 10 біт вільного простору під час налаштування рівня безпеки, особливо якщо аналіз безпеки включає сильні припущення щодо статистичної безпеки відносно нових протоколів, таких як FRI.

Навіть для PQ-SNARK завжди можна досягти належного рівня безпеки, просто збільшивши витрати на перевірку. Наприклад, збільшення безпеки верифікатора SHARP з 80 до 128 біт (за припущеннями про статистичну надійність FRI) збільшить витрати на газ приблизно вдвічі, з трохи більше 5 мільйонів до трохи більше 10 мільйонів. Без припущень щодо ПТІ витрати на газ зросли б ще в два рази, до понад 20 мільйонів. 

Моя наступна пропозиція полягає в тому, що спільнота web3 повинна розробити жорсткіші норми щодо відповідних рівнів безпеки для розгорнутих SNARK. Моєю особистою рекомендацією було б не менше 100 біт і не менше 128, якщо безпека SNARK базується на нестандартних припущеннях. Я не перший зробити таку пропозицію.

Тут я готовий класифікувати як «стандартне припущення» безумовну безпеку в випадкова модель оракула, якщо випадковий оракул у розгорнутому SNARK створено за допомогою стандартної хеш-функції, такої як KECCAK-256. Модель випадкового оракула — це ідеалізоване налаштування, призначене для фіксації поведінки добре розроблених криптографічних хеш-функцій. Він часто використовується для аналізу безпеки PQ-SNARK. 

Прикладом нестандартних припущень є гіпотези (описані нижче) щодо кількісної надійності протоколу, такого як FRI, або в інтерактивному середовищі, або як неінтерактивний протокол у моделі випадкового оракула.

Розробники SNARK впроваджують інновації багатьма захоплюючими способами, деякі з яких можуть розширити межі з точки зору безпеки, наприклад, використовуючи зручні для SNARK хеш-функції, які не піддаються стільки криптоаналізу, як більш стандартні хеш-функції. Я не закликаю до припинення таких зусиль – далеко не так. Але ці примітиви повинні бути створені на рівнях безпеки, які перевищують відомі можливі атаки більш ніж на 10 біт. 

Зведення з використанням SNARK зазвичай описується як успадкування безпеки їх L1. Але це важко зробити, якщо вони налаштовані на набагато нижчі рівні безпеки, ніж будь-які криптографічні примітиви, які використовує L1. Оскільки SNARK зростає, ми повинні переконатися, що ми розгортаємо їх у спосіб, який відповідає тому, як ми про них говоримо. Якщо SNARK ретельно проаналізовано, належним чином налаштовано та правильно реалізовано, вони настільки ж безпечні, як і будь-який криптографічний примітив, що використовується сьогодні. 

У бік: ще глибше занурення в безпеку PQ-SNARK

80 біт безпеки в PQ-SNARK від StarkWare враховуються наступним чином. Ці PQ-SNARK використовують поліноміальну схему зобов’язань, яка називається БЕЗКОШТОВНО, а верифікатор SHARP від ​​StarkWare запускає FRI з 48 бітами безпеки згідно гіпотези. Грубо кажучи, припущення полягає в тому, що проста атака на надійність FRI є оптимальною. У цій атаці обманщик, докладаючи невеликих зусиль, генерує «доказ FRI», який проходить випадково вибрані перевірки верифікатора з імовірністю 2^-48. 

StarkWare поєднує FRI з технікою під назвою «шліфування». Це вимагає від чесного перевірника створити 32-розрядне підтвердження роботи перед тим, як створити підтвердження FRI. Перевага шліфування полягає в тому, що воно суттєво збільшує роботу, необхідну для перевірки шахрайства, щоб виконати просту атаку на FRI, згадану вище, приблизно до 2³² хеш-оцінки. 

Оскільки (в очікуванні) 2⁴⁸ необхідні спроби простої атаки, перш ніж одна з них буде успішною, загальний обсяг роботи, який має виконати обман, щоб підробити доказ FRI, становить приблизно 2⁴⁸ * 2³² = 2⁸⁰ хеш-оцінки.

Нарешті, давайте розберемо, як виникають 48 біт безпеки для FRI. Верифікатор FRI робить «запити» до зафіксованого полінома. Вартість верифікації FRI зростає лінійно зі збільшенням кількості запитів. Наприклад, 36 запитів перевірки FRI приблизно в 4 рази дорожчі за 9 запитів. Але більше запитів означає більше безпеки. Кількість «біт безпеки на запит» залежить від іншого параметра FRI, який називається кодовою швидкістю. 

Зокрема, FRI використовує те, що називається кодом Ріда-Соломона r, Де r завжди є числом між 0 і 1. Витрати на перевірку FRI обернено пропорційні r, тому швидкість 1/16 призводить до прувера, який приблизно в чотири рази повільніший і займає більше місця, ніж швидкість ¼. 

Верифікатор SHARP запускав FRI з частотою кодування 1/16 і з 12 запитами верифікатора.

StarkWare припускає, що кожен запит верифікатора FRI додає журнал₂(1 /r) шматочки безпеки. Відповідно до цієї гіпотези, 12 перевірочних запитів дають 12 * log₂(16) = 48 біт безпеки.

Однак поточні аналізи встановлюють лише те, що кожен запит верифікатора додає трохи менше, ніж журнал₂(1/r^1/2) біти безпеки. Отже, 12 запитів верифікатора FRI дають лише менше 12 * log₂(4) = 24 біти «доказової» безпеки. 

Пропозиція щодо послаблення суперечності між безпекою та продуктивністю

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

Два приклади 

Багатокутник Гермез є створення PQ-SNARK з PlonK. Ідея полягає в тому, що довідник спочатку генерує доказ PQ-SNARK π. Якщо PQ-SNARK налаштовано на швидкий прувер і адекватний рівень безпеки, тоді π буде великим. Тому перевіряльник не надсилає π верифікатору. Натомість він використовує PlonK, щоб довести, що він знає π. 

Це означає застосування PlonK до схеми, яка приймає π як вхідні дані та перевіряє, чи прийме верифікатор PQ-SNARK π. Оскільки PQ-SNARK має вартість полілогарифмічної перевірки, PlonK застосовується до невеликої схеми, а отже, прувер PlonK працює швидко. Оскільки докази PlonK невеликі та дешеві для перевірки, витрати на перевірку низькі. 

На жаль, використання PlonK руйнує прозорість і постквантову безпеку. Натомість можна розглянути можливість використання самого PQ-SNARK замість PlonK, щоб підтвердити знання π (насправді PQ-SNARK, який використовується Polygon, самокомпонується таким чином). 

У цьому другому застосуванні PQ-SNARK, щоб підтвердити знання π, систему можна налаштувати для досягнення адекватної безпеки за допомогою доказів розумного розміру, наприклад, шляхом вибору дуже малої кодової швидкості для використання в FRI. Ключовим моментом є те, що хоча така мала кодова швидкість є поганою для часу перевірки, друге застосування PQ-SNARK застосовується лише до невеликої схеми, тому загальний час перевірки має бути малим.

Наше теоретичне розуміння безпеки складених SNARK залишає бажати кращого. Однак немає відомих атак на них, які були б швидшими, ніж атака на один із складових SNARK окремо. Наприклад, якщо ми створюємо PQ-SNARK з PlonK, ми не знаємо кращої атаки, ніж атакувати PQ-SNARK (тобто знайти доказ PQ-SNARK π хибного твердження) або атакувати PlonK (тобто, знайдіть доказ PlonK хибного твердження «Я знаю доказ PQ-SNARK π, який верифікатор прийняв би».)

Складання SNARK таким чином стає все більш популярним способом покращення продуктивності. Я сподіваюся, що розробники протоколів також використовують його для підвищення безпеки.

***

Джастін Талер є доцентом Джорджтаунського університету. Перш ніж приєднатися до Джорджтауна, він два роки пропрацював науковим співробітником Yahoo Labs у Нью-Йорку, а до цього він був науковим співробітником у Інститут теорії обчислювальної техніки Саймонса в UC Berkeley. 

Редактор: Тім Салліван @tim_org

***

Погляди, висловлені тут, є поглядами окремих співробітників AH Capital Management, LLC («a16z»), які цитуються, і не є поглядами a16z або його філій. Певна інформація, що міститься тут, була отримана зі сторонніх джерел, зокрема від портфельних компаній фондів, якими керує a16z. Хоча отримано з джерел, які вважаються надійними, a16z не перевіряв таку інформацію незалежно та не робить жодних заяв щодо тривалої точності інформації чи її відповідності певній ситуації. Крім того, цей вміст може містити рекламу третіх сторін; a16z не переглядав такі оголошення та не схвалює будь-який рекламний вміст, що міститься в них.

Цей вміст надається лише в інформаційних цілях, і на нього не можна покладатися як на юридичну, ділову, інвестиційну чи податкову консультацію. Ви повинні проконсультуватися з власними радниками щодо цих питань. Посилання на будь-які цінні папери чи цифрові активи наведено лише з метою ілюстрації та не є інвестиційною рекомендацією чи пропозицією надати інвестиційні консультаційні послуги. Крім того, цей вміст не призначений для будь-яких інвесторів чи потенційних інвесторів і не призначений для використання ними, і за жодних обставин на нього не можна покладатися при прийнятті рішення інвестувати в будь-який фонд, яким керує a16z. (Пропозиція інвестувати у фонд a16z буде зроблена лише на підставі меморандуму про приватне розміщення, угоди про підписку та іншої відповідної документації будь-якого такого фонду, і її слід читати повністю.) Будь-які інвестиційні чи портфельні компанії, згадані, згадані або описані не є репрезентативними для всіх інвестицій у транспортні засоби, якими керує a16z, і не може бути гарантії, що інвестиції будуть прибутковими або що інші інвестиції, здійснені в майбутньому, матимуть подібні характеристики чи результати. Список інвестицій, здійснених фондами під управлінням Andreessen Horowitz (за винятком інвестицій, щодо яких емітент не надав дозволу a16z на оприлюднення, а також неоголошених інвестицій у публічні цифрові активи) доступний за адресою https://a16z.com/investments /.

Наведені в ньому діаграми та графіки призначені виключно для інформаційних цілей, і на них не слід покладатися під час прийняття інвестиційних рішень. Минулі результати не вказують на майбутні результати. Зміст відповідає лише вказаній даті. Будь-які прогнози, оцінки, прогнози, цілі, перспективи та/або думки, висловлені в цих матеріалах, можуть бути змінені без попередження та можуть відрізнятися або суперечити думкам, висловленим іншими. Додаткову важливу інформацію можна знайти на сторінці https://a16z.com/disclosures.