Вимірювання продуктивності SNARK: інтерфейси, сервери та майбутнє

SNARK (Succinct Non-interactive Arguments of Knowledge) — це важливий криптографічний примітив для пошуку додатків для масштабованості блокчейну (наприклад, зведення L2) і конфіденційності. SNARK дозволяють комусь довести ненадійному верифікатору V (наприклад, блокчейн Ethereum), що вони знають деякі дані (наприклад, пакет дійсних транзакцій). Наївним способом довести це було б надіслати дані V, який потім може безпосередньо перевірити його дійсність. SNARK досягає того ж, але з меншими витратами V. Зокрема, доказ SNARK має бути коротшим, ніж наївний, що містить самі дані. (Детальніше дивіться чернетку мого підручника, Докази, аргументи та нульові знання. Щоб ознайомитись із SNARK, перегляньте сторінку Сари Мейклджон Presentation на крипто a16z Серія літніх досліджень.)

Вартість перевірки для SNARK може відрізнятися, але вона добре зрозуміла і часто досить висока. Наприклад, PlonK докази коштують приблизно 290,000 газ для перевірки на Ethereum, тоді як докази StarkWare коштують близько 5 мільйонів газу. SNARK потенційно можна застосувати в різних налаштуваннях навіть за межами блокчейнів — наприклад, дозволяючи використовувати швидкі, але ненадійні сервери та апаратні засоби. 

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

Але спочатку: як розгортаються SNARK

У розгортанні SNARK розробник зазвичай пише комп’ютерну програму ψ який приймає як вхідні дані w що підтверджувач стверджує, що знає (w стенди для свідок), і перевіряє це w є дійсним. Наприклад, у зведених програмах перевірятиметься, чи всі транзакції входять w мають цифровий підпис, не призводять до падіння залишків на рахунку нижче нуля тощо. Програма ψ потім подається через a Інтерфейс SNARK який компілює його у формат, більш зручний для застосування технології SNARK. Цей дружній до SNARK формат називається an проміжне представництво (ІЧ). 

Як правило, IR є деяким зразком задовільності схеми, який еквівалентний ψ. Це означає, що схема C приймає як вхідні дані w, а також деякі додаткові вхідні дані, які зазвичай називаються «недетермінованими порадами», і виконується ψ on w. Для допомоги використовуються введені поради C пробіг ψ, зберігаючи C маленький. Наприклад, кожного разу ψ ділить два числа x та y, частка q і залишок r можна надати як пораду C та C можна просто перевірити це x = qy + r. Цей чек дешевший, ніж виготовлення C запустіть алгоритм ділення для обчислення q та r з нуля.

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

Як ми побачимо, витрати на перевірку серверної частини SNARK зростають Cс розмір. Збереження C малі можуть бути складними, оскільки схеми є надзвичайно обмеженим форматом для вираження обчислень. Вони складаються з ворота, пов'язаний Провід. Кожні ворота g передає деякі значення та застосовує a дуже проста функція для цих значень. Потім результат подається в «нижні» затвори через дроти, що виходять звідти g.

Масштабованість SNARK: скільки часу насправді потрібно?

Ключове питання полягає в тому, скільки більше часу займає прувер SNARK порівняно з простим повторним виконанням ψ на дані? Відповідь така накладні витрати прувера СНАРК, відносно безпосередній огляд свідків. Останній вислів стосується того факту, що в наївному доказі, в якому P посилає w до V, V перевірки wдійсність шляхом виконання ψ на ньому. 

Доцільно розділити накладні витрати прувера на «завантажу інтерфейсу» та «закладку за сервером». Якщо оцінювати схему C ворота за воротами є F разів дорожче, ніж біг ψ, тоді ми кажемо, що накладні витрати на зовнішній інтерфейс є F. Якщо застосувати серверну перевірку до C is B разів дорожче, ніж оцінка C шлюз за шлюзом, тоді ми кажемо, що це накладні витрати на серверну частину B. Загальні накладні витрати на перевірку є продукт F·B. Ці мультиплікативні накладні витрати можуть бути значними, навіть якщо F та B індивідуально скромні. 

На практиці, F та B обидва можуть бути приблизно 1000 або більше. Це означає, що загальні накладні витрати на прувер щодо прямої перевірки свідків можуть становити від 1 до 10 мільйонів або більше. Програма, яка працює лише одну секунду на ноутбуці, може легко призвести до того, що перевірка SNARK потребуватиме десятків або сотень днів обчислювального часу (однопотоковий). На щастя, цю роботу зазвичай можна розпаралелювати різною мірою (залежно від SNARK). 

Підводячи підсумок, якщо ви хочете використовувати SNARK у програмі сьогодні, тоді одна з трьох речей має бути вірною:

1. Безпосередня перевірка свідків займає набагато менше однієї секунди на ноутбуці.
2. Пряма перевірка свідка особливо піддається представленню в схемі, тому накладні витрати на інтерфейс невеликі.
3. Ви готові чекати днями, поки завершиться перевірка SNARK, і/або платити за величезні паралельні обчислювальні ресурси.

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

Розділення фронтендів і бекендів

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

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

Більшість серверних програм фактично підтримують узагальнення арифметичних схем, які часто називають екземплярами рівня задоволення обмежень рангу 1 (R1CS). За помітним винятком Грот16 і його попередників, ці SNARK також можуть підтримувати інші IR. Наприклад, StarkWare використовує щось під назвою Algebraic Intermediate Representation (AIR), яке також схоже на поняття під назвою Арифметизація ПлонКіш які можуть підтримуватися PlonK та іншими серверними програмами. Здатність деяких серверних модулів підтримувати більш загальні IR може зменшити накладні витрати на інтерфейси, які створюють ці IR. 

Сервери також різняться за кількістю кінцевих полів, які вони підтримують. Я обговорю це далі в наступному розділі.

Різні підходи до інтерфейсів

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

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

Наприклад, StarkWare Каїр це дуже обмежена мова асемблера, в якій інструкції асемблера приблизно дозволяють додавання та множення над скінченним полем, виклики функцій, а також читання та запис у незмінну (тобто одноразову) пам’ять. Cairo VM — це архітектура фон Неймана, що означає, що схеми, створені зовнішнім інтерфейсом, по суті приймають програму Cairo як публічний вхід і «запускають» програму на свідку. Мова Cairo є Turing Complete — незважаючи на обмежений набір інструкцій, вона може імітувати більш стандартні архітектури, хоча це може бути дорогим. Інтерфейс Cairo запускає програми Cairo T примітивні інструкції в те, що називається «ступенем-2 ПОВІТРЯ с T рядів і о 50 стовпці.» Що саме це означає не є важливим для цієї посади, але, що стосується перевірок SNARK, це відповідає схемам із від 50 до 100 вентилів для кожного з T кроків Каїрського КПУ. 

RISC Нуль використовує подібний підхід до Cairo, але віртуальна машина є так званою Архітектура RISC-V, архітектура з відкритим вихідним кодом із багатою програмною екосистемою, популярність якої зростає. Оскільки це дуже простий набір інструкцій, розробка ефективного інтерфейсу SNARK, який його підтримує, може бути відносно легкою (принаймні відносно складних архітектур, таких як x86 або ARM). Станом на травень RISC Zero перевертає програми виконання T примітивні інструкції RISC-V в AIR ступеня 5 з 3T рядки та 160 колонки. Це відповідає схемам з принаймні 500 воріт на крок ЦП RISC-V. Подальші вдосконалення очікуються найближчим часом.

Різні проекти zkEVM (наприклад, zkSync 2.0, Scroll, zkEVM від Polygon) сприймають віртуальну машину як віртуальну машину Ethereum. Процес перетворення кожної інструкції EVM на еквівалентний «гаджет» (тобто оптимізовану схему, що реалізує інструкцію) є значно складнішим, ніж для простіших архітектур Cairo та RISC-V. З цієї та інших причин, деякі з проектів zkEVM не реалізують напряму набір інструкцій EVM, а скоріше компілюють високорівневі програми Solidity на інші мови асемблера перед тим, як перетворити їх на схеми. Результати виконання цих проектів очікуються.

Проекти «емулятора процесора», такі як RISC-V і Cairo, створюють єдину схему, яка може обробляти всі програми на відповідній мові асемблера. Альтернативні підходи є «подібними до ASIC», створюючи різні схеми для різних програм. Цей підхід, схожий на ASIC, може давати менші схеми для деяких програм, особливо коли інструкція асемблера, яку програма виконує на кожному кроці часу, не залежить від вхідних даних програми. Наприклад, він потенційно може повністю уникнути накладних витрат інтерфейсу для прямолінійних програм, таких як просто множення матриць. Але підхід ASIC також виглядає дуже обмеженим; Наскільки я знаю, невідомо, як використовувати його для підтримки циклів без заздалегідь визначених меж ітерації. 

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

Деякі серверні модулі SNARK дозволяють вибирати більш гнучкі поля, ніж інші. Наприклад, якщо серверна частина використовує криптографічну групу G, поле схеми має відповідати кількості елементів у G, що може обмежувати. Крім того, не всі поля підтримують практичні алгоритми ШПФ. 

Існує лише один реалізований SNARK, Гальмування, який нативно підтримує обчислення над довільними (достатньо великими) полями. Разом зі своїм нащадки, він має найшвидшу відому ефективність перевірки бетону навіть над полями, які підтримують інші SNARK, але його докази наразі завеликі для багатьох додатків блокчейну. Останні роботи прагне покращити розмір доказу, але перевірка асимптотично повільніша виявляється бар'єри до практичності.

Деякі проекти вирішили працювати над полями з особливо швидкою арифметикою. Наприклад, Плоньки2 а інші використовують поле характеристики 2⁶⁴ - 2³² + 1, тому що арифметику в цьому полі можна реалізувати в кілька разів швидше, ніж у менш структурованих полях. Однак використання такої малої характеристики може призвести до проблем із ефективним представленням цілочисельної арифметики за допомогою операцій із полями (наприклад, множення двох 32-розрядних цілих чисел без знаку може дати результат, більший за характеристику поля). 

 Але незважаючи ні на що, щоб усі популярні сьогодні SNARK досягли 128 біт безпеки (без значного збільшення витрат на перевірку), вони повинні працювати над полем розміром більше 2¹²⁸. Наскільки я можу судити, це означає, що кожна польова операція вимагатиме принаймні близько десяти 64-розрядних машинних множень і значно більше додавання та побітових операцій. Отже, слід враховувати принаймні порядок величини накладних витрат на зовнішній інтерфейс через потребу в схемах, які працюють над кінцевими полями. 

Підводячи підсумок, існуючі інтерфейси, які використовують абстракцію віртуальної машини, створюють схеми з 100x до 1000x вентилями на крок віртуальної машини, і, можливо, більше для складніших віртуальних машин. Крім того, арифметика кінцевих полів принаймні в 10 разів повільніша за аналогічні інструкції на сучасних процесорах (за можливими винятками, якщо процесор має вбудовану підтримку певних полів). «Підхід інтерфейсу ASIC» може зменшити деякі з цих накладних витрат, але наразі він обмежений у програмах, які він може підтримувати.

Які вузькі місця серверної частини?

SNARK для задовільності схеми зазвичай розробляються шляхом поєднання інформаційно-теоретично захищеного протоколу, який називається “поліноміальний ВГД» за допомогою криптографічного протоколу під назвою «поліноміальна схема зобов'язань.” У більшості випадків конкретним вузьким місцем для прувера є поліноміальна схема зобов’язань. Зокрема, ці SNARK мають криптографічну прихильність до одного або кількох поліномів, ступінь яких (принаймні) |C|, кількість затворів у схемі C. 

У свою чергу, конкретне вузьке місце в поліноміальній схемі зобов’язань залежатиме від використовуваної схеми та розміру схеми. Але це завжди буде одна з наступних трьох операцій: обчислення ШПФ, піднесення до степеня в криптографічній групі або Хешування Меркла. Хешування Merkle зазвичай є вузьким місцем, лише якщо схема невелика, тому ми не будемо обговорювати це далі. 

Поліноміальні зобов'язання на основі дискретного журналу

У поліноміальних зобов'язаннях, заснованих на жорсткості проблеми дискретного логарифмування в криптографічній групі G (КЗГ, Куленепробивні, соняшник та Hyrax-комміт), перевіряльник повинен обчислити a Вектор зобов'язання Педерсена до коефіцієнтів полінома. Це передбачає мультипіднесення до степеня, розмір якого дорівнює степеню полінома. У SNARK цей ступінь зазвичай є розміром |C| контуру C.

Зроблено наївно, багатоступеневе піднесення розміру |C| потрібно близько 1.5·|C|·журнал |G| ≈ 400·|C| групові операції, де |G| позначає кількість елементів у групі G. Однак існує підхід, який називається алгоритмом Піппенгера, який може зменшити це приблизно в log |C|. Для великих схем (скажімо, |C| ≥ 225), цей журнал |C| коефіцієнт конкретно може становити 25 або більше, тобто для великих схем ми очікуємо, що зобов’язання вектора Педерсена можна обчислити з трохи більше 10·|C| групові операції. Кожна групова операція, у свою чергу, має тенденцію (як дуже приблизний приклад) приблизно в 10 разів повільніше, ніж операція кінцевого поля. SNARK, які використовують ці поліноміальні зобов’язання, є такими ж дорогими P приблизно 100·|C| польові операції. 

На жаль, існуючі SNARK мають додаткові накладні витрати на додаток до 100-кратного коефіцієнта вище. Наприклад:

• спартанськийПрограма перевірки, яка використовує поліноміальне зобов'язання Hyrax, має зробити |C|^½ багато мультипіднесення до степеня, кожне з яких має розмір |C|^½, послаблюючи прискорення від алгоритму Піппенгера приблизно в два рази. 
• In Грот16, P повинні працювати над групою, яка підтримує створення пар, операції якої зазвичай принаймні вдвічі повільніші, ніж групи, які не є дружніми до пар. P також потрібно виконати 3 мультипіднесення до степеня, а не 1. У сукупності це призводить до принаймні додаткового уповільнення коефіцієнта 6 порівняно зі 100·|C| оцінка вище. 
• Marlin та PlonK також вимагають створення пар, а їхні перевірювачі зобов’язані використовувати значно більше ніж 3 поліноми. 
• Для будь-якого SNARK, який використовує Куленепробивні (наприклад, Halo2, що приблизно є PlonK, але з поліноміальними зобов’язаннями Bulletproofs, а не KZG), прувер повинен логарифмічно обчислити багато мультипіднесення під час фази «відкриття» схеми зобов’язань, і це значною мірою стирає будь-яке прискорення Піппенгера. 

Підводячи підсумок, відомі SNARK, які використовують векторні зобов’язання Педерсена, мають накладні витрати принаймні в 200 разів і до 1000 разів або більше. 

Інші поліноміальні зобов'язання

Для SNARK, що використовують інші поліноміальні зобов’язання (наприклад БЕЗКОШТОВНО та Ligero-комміт), вузьким місцем є те, що прувер повинен виконувати великі ШПФ. Наприклад, у AIRs ступеня 2 виробництва Cairo (з 51 колонкою та T рядків, по одному на крок ЦП Cairo), розгорнутий прувер StarkWare виконує принаймні 2 ШПФ на стовпець довжиною між 16 ·T та 32 ·T. Константи 16 та 32 залежать від внутрішніх параметрів FRI, встановлених StarkWare, і можуть бути зменшені — але ціною збільшення витрат на перевірку. 

Оптимістично, ШПФ довжиною 32·T займає близько 64·T·журнал (32T) поле множення. Це означає, що навіть для відносно малих значень T (наприклад, T ≥ 2²⁰), кількість польових операцій на стовпець становить принаймні 64·25·T= 1600·T. Таким чином, накладні витрати на бекенд вимірюють щонайменше тисячі. Крім того, можливо, що великі ШПФ ще більше обмежені пропускною здатністю пам’яті, ніж польовими операціями. 

У деяких контекстах накладні витрати SNARK, які виконують великі ШПФ, можна зменшити за допомогою техніки, яка називається агрегацією доказів. Для зведених це означало б, що P (служба зведення) розбиває велику партію транзакцій на, скажімо, 10 менших груп. Для кожної невеликої партії i, P створює доказ SNARK πi дійсність партії. але P не публікує ці докази в Ethereum, оскільки це призведе до майже 10-кратного збільшення витрат на газ. Натомість SNARK застосовано знову, цього разу для отримання доказу π встановлення того P знає π₁ ...,π₁₀. Тобто свідок того P стверджує, що знає десять доказів π₁,…,π₁₀, а пряма перевірка свідків застосовує процедуру перевірки SNARK до кожного з доказів. Це єдиний доказ π розміщується в Ethereum. 

У поліноміальних зобов’язаннях, таких як FRI та Ligero-commit, існує сильна напруга між ними P час і V витрати, з внутрішніми параметрами, що діють як ручка, яка може змінювати один на інший. Оскільки π₁ ,…,π₁₀ не опубліковано в Ethereum, ручку можна налаштувати так, щоб ці докази великі, і їх виготовлення відбувається швидше. Тільки в остаточному застосуванні SNARK, щоб агрегувати π₁ ,…,π₁₀ в єдиний доказ π, чи потрібно налаштувати схему зобов’язань, щоб забезпечити невеликий доказ. 

StarkWare планує розгорнути агрегацію доказів неминуче. Це також є фокусом таких проектів, як Плоньки2.

Які інші вузькі місця є для масштабованості SNARK?

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

Інший приклад: багато популярних SNARK (наприклад, PlonK, Marlin, Грот16) вимагають складної «церемонії довіреного налаштування» для створення структурованого «ключа перевірки», які повинні зберігатися прувером. Наскільки я знаю, найбільша така церемонія згенерував перевірочний ключ, здатний підтримувати схеми з приблизно 2²⁸≈250 мільйонів воріт. Розмір ключа підтвердження становить кілька десятків гігабайт. 

У контекстах, де можливе агрегування доказів, ці вузькі місця можна суттєво пом’якшити. 

Заглядаючи вперед: перспективи для більш масштабованих SNARK

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

Я думаю, ми це зробимо — до певної міри. По-перше, найшвидші серверні модулі на сьогодні (наприклад, спартанський та Гальмуваннята інші SNARK, які поєднують протокол підсумкової перевірки з поліноміальними зобов’язаннями) мають великі докази — зазвичай квадратний корінь у розмірі схеми — тому люди насправді ними не користуються. Я очікую, що розмір перевірки та час верифікації будуть суттєво зменшені в найближчому майбутньому завдяки композиції глибини один із SNARK для невеликих перевірок. Подібно до агрегації доказів, це означає, що перевірник спочатку згенерує доказ SNARK π із SNARK «швидка перевірка, велика перевірка», але не надсилати π до V. Швидше, P використовував би SNARK з малим пробним зразком для отримання доказу π" що воно знає π, і відправити π" до V. Це може на порядок зменшити накладні витрати на бекенд популярних сьогодні SNARK. 

По-друге, може допомогти апаратне прискорення. Дуже грубе загальне правило полягає в тому, що графічні процесори можуть отримати 10-кратне прискорення порівняно з центральними процесорами, а ASIC – 10-кратне прискорення порівняно з графічними процесорами. Однак у мене є три проблеми з цього приводу. По-перше, великі ШПФ можуть бути обмежені пропускною здатністю пам’яті, а не польовими операціями, тому SNARK, які виконують такі ШПФ, можуть мати обмежене прискорення від спеціалізованого обладнання. По-друге, хоча ця публікація зосереджена на вузькому місці поліноміальних зобов’язань, багато SNARK вимагають від перевірки виконання інших операцій, які лише трохи дешевші. Таким чином, розрив вузького місця поліноміального зобов’язання (наприклад, прискорення багатоступеневого піднесення у SNARK на основі дискретного журналу) може залишити нову операцію з вузьким місцем, яка не є значно кращою за стару. (Наприклад, SNARK, у тому числі Groth16, Marlin і PlonK, також мають перевірку, яка виконує ШПФ, на додаток до багатоступеневого зведення.) Нарешті, поля та еліптичні криві, які призводять до найефективніших SNARK, можуть продовжувати розвиватися протягом деякого часу, і це може створити проблеми для прискорення пруверів на основі ASIC.

Що стосується зовнішнього інтерфейсу, ми все частіше можемо виявити, що підхід «емулятора процесора» таких проектів, як Cairo, RISC Zero, zkEVMs та інших, насправді досить добре масштабується (з точки зору продуктивності) зі складністю наборів інструкцій ЦП. Справді, саме на це сподіваються різні проекти zkEVM. Це може означати, що, хоча накладні витрати на інтерфейс залишаються на три порядки або більше, інтерфейси встигають підтримувати віртуальні машини, які все більше відповідають реальним архітектурам ЦП. Додаткове занепокоєння полягає в тому, що зовнішні інтерфейси можуть ускладнюватися та бути складними для перевірки, оскільки поширюється кількість гаджетів із ручним кодом, які реалізують дедалі складніші інструкції. Формальні методи перевірки, ймовірно, зіграють важливу роль у вирішенні цієї проблеми. 

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

***

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

***

Подяка: Я вдячний Олена Бургер за пропозицію теми цього допису та до Арасу Арун, Джозеф Бонно та Сем Регсдейл за глибокі коментарі. Особлива подяка також моєму редактору, Тім Салліван.

***

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

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

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