Про продуктивність віртуальної машини Ethereum (EVM)
Кожна операція в основній мережі Ethereum коштує певну кількість газу. Якщо ми проведемо всі обчислення, необхідні для запуску основної програми, або програма вийде з ладу, або користувач збанкрутує.
Це призвело до появи L2: OPRU представляє інструмент зіставлення, щоб об’єднати купу транзакцій перед підключенням до основної мережі. Це не тільки допомагає програмі забезпечувати безпеку Ethereum, але й дає користувачам кращий досвід. Користувачі можуть відправляти транзакції швидше, а комісія дешевша. Хоча операції стали дешевшими, він все ще використовує рідний EVM як рівень виконання. Подібно до ZK Rollups, Scroll і Polygon zkEVM використовують або використовуватимуть схеми zk на основі EVM, а zk Proof генеруватиметься в кожній транзакції або великій групі транзакцій, які виконуються на його перевірці. Незважаючи на те, що це дозволяє розробникам створювати «повноланцюгові» додатки, чи ефективним і рентабельним є запуск високопродуктивних додатків?
Що це за високопродуктивні програми?
Першими на думку спадають ігри, книги онлайн-замовлень, соціальні мережі Web3, машинне навчання, моделювання геному тощо. Усі вони потребують обчислень і дорогі для роботи на L2. Ще одна проблема з EVM полягає в тому, що швидкість і ефективність обчислень не такі хороші, як в інших поточних системах, таких як SVM (Sealevel Virtual Machine).
Хоча L3 EVM може здешевити обчислення, сама структура EVM може бути не найкращим способом виконання обчислень із високим вмістом, оскільки вона не може обчислювати паралельні операції. Кожного разу, коли створюється новий рівень вище, щоб зберегти дух децентралізації, потрібно побудувати нову інфраструктуру (нову мережу вузлів), для розширення якої все ще потрібна така сама кількість провайдерів, або абсолютно новий набір вузлів постачальники (індивідуальні/корпоративні) для надання ресурсів або потрібні обидва.
Таким чином, щоразу, коли створюється більш досконале рішення, наявну інфраструктуру потрібно оновити або створити новий рівень поверх неї. Щоб вирішити цю проблему, нам потрібна постквантова безпечна, децентралізована, ненадійна, високопродуктивна обчислювальна інфраструктура, яка може справді й ефективно використовувати квантові алгоритми для обчислень для децентралізованих програм.
Alt-L1, як-от Solana, Sui та Aptos, здатні виконувати паралельно, але через ринкові настрої, брак ліквідності та відсутність розробників на ринку вони не кинуть виклик Ethereum. Через відсутність довіри і рів, побудований Ethereum з мережевими ефектами, є важливою віхою. Поки що вбивці ETH/EVM не існує. Питання тут полягає в тому, чому всі обчислення мають бути в ланцюжку? Чи існує така ж ненадійна децентралізована система примусового виконання? Це те, чого може досягти система DCompute.
Інфраструктура DCompute має бути децентралізованою, постквантовою захищеною та надійною. Їй не потрібна або не повинна бути технологія блокчейн/розподілена, але дуже важливо перевіряти результати обчислень, правильні переходи між станами та остаточне підтвердження. Важливо. Ось як працює ланцюжок EVM. Зберігаючи безпеку та незмінність мережі, децентралізовані, надійні та безпечні обчислення можна перемістити за межі ланцюжка.
Що ми в основному ігноруємо тут, так це питання доступності даних. Ця публікація не позбавлена уваги доступності даних, оскільки такі рішення, як Celestia та EigenDA, уже рухаються в цьому напрямку.
1: лише аутсорсинг Compute
(来源: Моделі автономного ланцюжка та підходи до обчислень поза ланцюгом, Джейкоб Еберхардт і Джонатан Хайс)
2. Аутсорсинг обчислень і доступність даних
(来源: Моделі автономного ланцюжка та підходи до обчислень поза ланцюгом, Джейкоб Еберхардт і Джонатан Хайс)
Коли ми побачили Type 1, zk-rollups вже робили це, але вони були або обмежені EVM, або повинні були навчити розробників абсолютно новій мові/набору інструкцій. Ідеальне рішення має бути ефективним, дієвим (вартість і ресурси), децентралізованим, приватним і таким, що піддається перевірці. Докази ZK можна створювати на серверах AWS, але вони не є децентралізованими. Такі рішення, як Nillion і Nexus, намагаються вирішити проблему загального обчислення децентралізованим способом. Але ці рішення неможливо перевірити без доказів ZK.
Тип 2 поєднує модель обчислення поза ланцюгом із рівнем доступності даних, який залишається окремим, але обчислення все одно потрібно перевіряти в ланцюзі.
Давайте подивимося на різні моделі децентралізованих обчислень, доступні сьогодні, які не є цілком надійними і, можливо, зовсім ненадійними.
TEE (Trusted Execution Environment) — це як спеціальна коробка в комп’ютері чи смартфоні. Він має власний замок і ключ, і лише певні програми (так звані довірені програми) можуть отримати до нього доступ. Коли ці довірені програми запускаються всередині TEE, вони захищені іншими програмами і навіть самою операційною системою.
Це як таємна схованка, куди можуть потрапити лише кілька особливих друзів. Найпоширенішим прикладом TEE є Secure Enclave, який існує на пристроях, які ми використовуємо, як-от чіп T1 від Apple і SGX від Intel, для виконання критичних операцій усередині пристрою, наприклад FaceID.
Оскільки TEE є ізольованою системою, процес автентифікації не може бути скомпрометований через припущення про довіру в автентифікації. Думайте про це як про двері безпеки, які, на вашу думку, є безпечними, оскільки їх створили Intel або Apple, але у світі є достатньо зломників безпеки (включно з хакерами та іншими комп’ютерами), які можуть зламати ці двері безпеки. TEE не є «постквантово безпечними», що означає, що квантовий комп’ютер з необмеженими ресурсами може зламати безпеку TEE. Оскільки комп’ютери швидко стають потужнішими, ми повинні будувати довгострокові обчислювальні системи та криптографічні схеми з урахуванням постквантової безпеки.
Безпечне багатостороннє обчислення (SMPC)
SMPC (Secure Multi-Party Computing) також є добре відомим обчислювальним рішенням в індустрії технології блокчейн.Загальний робочий процес у мережі SMPC складатиметься з наступних трьох частин:
Крок 1: Перетворіть обчислені вхідні дані в спільні ресурси та розподіліть між вузлами SMPC.
Крок 2: Виконайте фактичні обчислення, зазвичай передбачаючи обмін повідомленнями між вузлами SMPC. Наприкінці цього кроку кожен вузол матиме частку обчисленого вихідного значення.
Крок 3: Надішліть спільний доступ до одного або кількох вузлів результатів, які запускають LSS (алгоритм відновлення секретного обміну) для реконструкції вихідного результату.
Уявіть собі лінію з виробництва автомобілів, де будівельні та виробничі компоненти автомобіля (двигун, двері, дзеркала) передані виробнику оригінального обладнання (OEM) (робочі вузли), а потім є складальна лінія, яка об’єднує всі компоненти зробити машину (в результаті вузол).
Обмін секретами важливий для моделі децентралізованих обчислень, що зберігає конфіденційність. Це запобігає отриманню єдиною стороною повного «секрету» (у цьому випадку введення) і зловмисному виведенню помилкових результатів. SMPC, мабуть, одна з найпростіших і найбезпечніших децентралізованих систем. Хоча повністю децентралізованої моделі наразі не існує, вона логічно можлива.
Такі постачальники MPC, як Sharemind, надають інфраструктуру MPC для обчислень, але постачальники все ще централізовані. Як забезпечити конфіденційність, як переконатися, що мережа (або Sharemind) не є зловмисною? Це походження обчислень zk proof і zk verifiable.
Обчислення нульових повідомлень（NMC）
NMC — це новий метод розподілених обчислень, розроблений командою Nillion. Це оновлена версія MPC, де вузлам не потрібно спілкуватися, взаємодіючи через результати. Для цього вони використали криптографічний примітив під назвою One-Time Masking, який використовує серію випадкових чисел, які називаються факторами засліплення, щоб замаскувати секрет, подібно до одноразового заповнення. OTM має на меті забезпечити правильність ефективним способом, що означає, що вузлам NMC не потрібно обмінюватися повідомленнями для виконання обчислень. Це означає, що NMC не матиме проблем масштабованості SMPC.
Обчислення з нульовим знанням, яке можна перевірити
ZK Verifiable Computation (ZK Verifiable Computation) призначений для створення доказу нульового знання для набору вхідних даних і функції, а також для підтвердження того, що будь-який обчислення, виконане системою, буде виконано правильно. Хоча розрахунок перевірки ZK є новим, він уже є дуже важливою частиною дорожньої карти розширення мережі Ethereum,
ZK доводить, що існують різні форми реалізації (як показано на малюнку нижче, згідно з підсумком у статті "Off-Chaining_Models"):
(Джерело: IOSG Ventures, Off-chaining Models and Approaches to Off-chain Computations, Jacob Eberhardt & Jonathan Heiss)
Вище ми маємо базове розуміння реалізації доказів zk, тож які умови для використання доказів ZK для перевірки обчислень?
Перш за все, нам потрібно вибрати примітив доказу. Ідеальний примітив доказу має низьку вартість генерації доказів, не вимагає багато пам’яті та його легко перевірити
Нарешті, в обчислювальній системі/мережі дана функція обчислюється на наданому вхідному сигналі, а вихід надається.
Дилема розробника – дилема довести ефективність
Інша річ, яку я маю сказати, полягає в тому, що поріг для побудови схем все ще дуже високий. Розробникам нелегко вивчити Solidity. Тепер розробникам потрібно вивчати Circom, щоб створювати схеми, або вивчати певну мову програмування (наприклад, Cairo). створення zk-додатків здається далекою перспективою.
Як показує наведена вище статистика, **зробити середовище Web3 більш придатним для розробки видається більш стійким, ніж залучення розробників до нового середовища розробки Web3. **
Якщо ZK – це майбутнє Web3, а додатки Web3 потрібно створювати з використанням наявних навичок розробника, то схеми ZK мають бути розроблені таким чином, щоб вони підтримували обчислення, які виконуються алгоритмами, написаними на таких мовах, як Java або Rust, для створення доказів. .
Такі рішення існують, і я думаю про дві команди: RiscZero та Lurk Labs. Обидві команди поділяють дуже схоже бачення, що вони дозволяють розробникам створювати zk-додатки, не проходячи крутої кривої навчання.
Для Lurk Labs ще рано, але команда працювала над цим проектом протягом тривалого часу. Вони зосереджені на створенні доказів Nova через схеми загального призначення. Докази Nova запропонували Абхірам Котапаллі з Університету Карнегі-Меллона, Срінат Сетті з Microsoft Research і Іоанна Ціаллае з Нью-Йоркського університету. Порівняно з іншими системами SNARK, Nova має особливі переваги у виконанні інкрементних перевірених обчислень (IVC). Інкрементальне перевірене обчислення (IVC) — це концепція в інформатиці та криптографії, яка спрямована на забезпечення верифікації обчислення без повторного обчислення всього обчислення з нуля. Докази потрібно оптимізувати для IVC, коли час обчислення тривалий і складний.
Принадність дизайну мережі Bonsai полягає в тому, що обчислення можна ініціалізувати, перевірити та вивести в мережу. Все це звучить як утопія, але доказ STARK також приносить проблеми - вартість перевірки занадто висока.
Докази Nova, здається, добре підходять для повторних обчислень (його схема згортання є економічно ефективною) і невеликих обчислень, що може зробити Lurk хорошим рішенням для перевірки висновків ML.
Хто переможець?
(Джерело: IOSG Ventures)
Деякі системи zk-SNARK вимагають довіреного процесу налаштування під час початкової фази налаштування, генеруючи початковий набір параметрів. Припущення довіри тут полягає в тому, що довірені налаштування виконуються чесно, без будь-якої зловмисної поведінки чи втручання. У разі атаки це може призвести до створення недійсних доказів.
Докази STARK передбачають безпеку тестів нижчого порядку для перевірки властивостей поліномів нижчого порядку. Вони також припускають, що хеш-функції поводяться як випадкові оракули.
Правильне впровадження обох систем також є припущенням безпеки.
Мережа SMPC спирається на наступне:
*Учасники SMPC можуть включати «чесних, але цікавих» учасників, які можуть спробувати отримати доступ до будь-якої основної інформації, спілкуючись з іншими вузлами.
*Безпека мережі SMPC ґрунтується на припущенні, що учасники правильно виконують протокол і навмисно не створюють помилок або зловмисної поведінки.
Деякі протоколи SMPC можуть вимагати довіреної фази налаштування для створення зашифрованих параметрів або початкових значень. Припущення про довіру тут полягає в тому, що довірені налаштування застосовуються чесно.
Так само, як і в мережі SMPC, припущення щодо безпеки залишається тим самим, але через існування OTM (Off-The-Grid Multi-party Computation) немає «чесних, але цікавих» учасників.
OTM — це багатосторонній протокол обчислень, призначений для захисту конфіденційності учасників. Це забезпечує захист конфіденційності, дозволяючи учасникам не розголошувати свої вхідні дані під час обчислення. Таким чином, «чесних, але цікавих» учасників не буде, оскільки вони не зможуть спілкуватися з іншими вузлами, намагаючись отримати доступ до основної інформації.
Чи є явний переможець? Ми не знаємо. Але кожен спосіб має свої переваги. Хоча NMC виглядає як очевидне оновлення до SMPC, мережа ще не активна чи не випробувана в боях.
Перевага використання верифікованих обчислень ZK полягає в тому, що вони безпечні та зберігають конфіденційність, але не мають вбудованого обміну секретами. Асиметрія між створенням доказів і перевіркою робить його ідеальною моделлю для аутсорсингових обчислень, які можна перевірити. Якщо система використовує чисті обчислення zk-proof, комп’ютер (або окремий вузол) має бути дуже потужним, щоб виконувати багато обчислень. Для того, щоб увімкнути розподіл навантаження та балансування, зберігаючи конфіденційність, має бути таємний розподіл. У цьому випадку систему, як-от SMPC або NMC, можна об’єднати з генератором zk, як-от Lurk або RiscZero, для створення потужної розподіленої перевірюваної обчислювальної інфраструктури.
Це стає ще більш важливим сьогодні, коли мережі MPC/SMPC централізовані. Найбільшим постачальником MPC зараз є Sharemind, і рівень перевірки ZK на його основі може виявитися корисним. Економічна модель децентралізованої мережі MPC ще не відпрацьована. Теоретично режим NMC є модернізацією системи MPC, але ми ще не бачили його успіху.
У змаганні за схеми перевірки ZK може не бути ситуації, коли переможець отримує все. Кожен метод перевірки оптимізований для певного типу обчислень, і жоден не підходить для всіх типів моделей. Існує багато типів обчислювальних завдань, і це також залежить від компромісів, які розробники роблять із кожною системою перевірки. Автор вважає, що як системам на базі STARK, так і системам на основі SNARK та їх майбутній оптимізації є місце в майбутньому ZK.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Хто виграє під час буму інновацій EVM?
Сіддхарт Рао, IOSG Ventures
Про продуктивність віртуальної машини Ethereum (EVM)
Кожна операція в основній мережі Ethereum коштує певну кількість газу. Якщо ми проведемо всі обчислення, необхідні для запуску основної програми, або програма вийде з ладу, або користувач збанкрутує.
Це призвело до появи L2: OPRU представляє інструмент зіставлення, щоб об’єднати купу транзакцій перед підключенням до основної мережі. Це не тільки допомагає програмі забезпечувати безпеку Ethereum, але й дає користувачам кращий досвід. Користувачі можуть відправляти транзакції швидше, а комісія дешевша. Хоча операції стали дешевшими, він все ще використовує рідний EVM як рівень виконання. Подібно до ZK Rollups, Scroll і Polygon zkEVM використовують або використовуватимуть схеми zk на основі EVM, а zk Proof генеруватиметься в кожній транзакції або великій групі транзакцій, які виконуються на його перевірці. Незважаючи на те, що це дозволяє розробникам створювати «повноланцюгові» додатки, чи ефективним і рентабельним є запуск високопродуктивних додатків?
Що це за високопродуктивні програми?
Першими на думку спадають ігри, книги онлайн-замовлень, соціальні мережі Web3, машинне навчання, моделювання геному тощо. Усі вони потребують обчислень і дорогі для роботи на L2. Ще одна проблема з EVM полягає в тому, що швидкість і ефективність обчислень не такі хороші, як в інших поточних системах, таких як SVM (Sealevel Virtual Machine).
Хоча L3 EVM може здешевити обчислення, сама структура EVM може бути не найкращим способом виконання обчислень із високим вмістом, оскільки вона не може обчислювати паралельні операції. Кожного разу, коли створюється новий рівень вище, щоб зберегти дух децентралізації, потрібно побудувати нову інфраструктуру (нову мережу вузлів), для розширення якої все ще потрібна така сама кількість провайдерів, або абсолютно новий набір вузлів постачальники (індивідуальні/корпоративні) для надання ресурсів або потрібні обидва.
Таким чином, щоразу, коли створюється більш досконале рішення, наявну інфраструктуру потрібно оновити або створити новий рівень поверх неї. Щоб вирішити цю проблему, нам потрібна постквантова безпечна, децентралізована, ненадійна, високопродуктивна обчислювальна інфраструктура, яка може справді й ефективно використовувати квантові алгоритми для обчислень для децентралізованих програм.
Alt-L1, як-от Solana, Sui та Aptos, здатні виконувати паралельно, але через ринкові настрої, брак ліквідності та відсутність розробників на ринку вони не кинуть виклик Ethereum. Через відсутність довіри і рів, побудований Ethereum з мережевими ефектами, є важливою віхою. Поки що вбивці ETH/EVM не існує. Питання тут полягає в тому, чому всі обчислення мають бути в ланцюжку? Чи існує така ж ненадійна децентралізована система примусового виконання? Це те, чого може досягти система DCompute.
Інфраструктура DCompute має бути децентралізованою, постквантовою захищеною та надійною. Їй не потрібна або не повинна бути технологія блокчейн/розподілена, але дуже важливо перевіряти результати обчислень, правильні переходи між станами та остаточне підтвердження. Важливо. Ось як працює ланцюжок EVM. Зберігаючи безпеку та незмінність мережі, децентралізовані, надійні та безпечні обчислення можна перемістити за межі ланцюжка.
Що ми в основному ігноруємо тут, так це питання доступності даних. Ця публікація не позбавлена уваги доступності даних, оскільки такі рішення, як Celestia та EigenDA, уже рухаються в цьому напрямку.
1: лише аутсорсинг Compute
(来源: Моделі автономного ланцюжка та підходи до обчислень поза ланцюгом, Джейкоб Еберхардт і Джонатан Хайс)
2. Аутсорсинг обчислень і доступність даних
(来源: Моделі автономного ланцюжка та підходи до обчислень поза ланцюгом, Джейкоб Еберхардт і Джонатан Хайс)
Коли ми побачили Type 1, zk-rollups вже робили це, але вони були або обмежені EVM, або повинні були навчити розробників абсолютно новій мові/набору інструкцій. Ідеальне рішення має бути ефективним, дієвим (вартість і ресурси), децентралізованим, приватним і таким, що піддається перевірці. Докази ZK можна створювати на серверах AWS, але вони не є децентралізованими. Такі рішення, як Nillion і Nexus, намагаються вирішити проблему загального обчислення децентралізованим способом. Але ці рішення неможливо перевірити без доказів ZK.
Тип 2 поєднує модель обчислення поза ланцюгом із рівнем доступності даних, який залишається окремим, але обчислення все одно потрібно перевіряти в ланцюзі.
Давайте подивимося на різні моделі децентралізованих обчислень, доступні сьогодні, які не є цілком надійними і, можливо, зовсім ненадійними.
Альтернативне обчислення s
Екологічна карта Ethereum Outsourcing Computing (Джерело: IOSG Ventures)
TEE (Trusted Execution Environment) — це як спеціальна коробка в комп’ютері чи смартфоні. Він має власний замок і ключ, і лише певні програми (так звані довірені програми) можуть отримати до нього доступ. Коли ці довірені програми запускаються всередині TEE, вони захищені іншими програмами і навіть самою операційною системою.
Це як таємна схованка, куди можуть потрапити лише кілька особливих друзів. Найпоширенішим прикладом TEE є Secure Enclave, який існує на пристроях, які ми використовуємо, як-от чіп T1 від Apple і SGX від Intel, для виконання критичних операцій усередині пристрою, наприклад FaceID.
Оскільки TEE є ізольованою системою, процес автентифікації не може бути скомпрометований через припущення про довіру в автентифікації. Думайте про це як про двері безпеки, які, на вашу думку, є безпечними, оскільки їх створили Intel або Apple, але у світі є достатньо зломників безпеки (включно з хакерами та іншими комп’ютерами), які можуть зламати ці двері безпеки. TEE не є «постквантово безпечними», що означає, що квантовий комп’ютер з необмеженими ресурсами може зламати безпеку TEE. Оскільки комп’ютери швидко стають потужнішими, ми повинні будувати довгострокові обчислювальні системи та криптографічні схеми з урахуванням постквантової безпеки.
SMPC (Secure Multi-Party Computing) також є добре відомим обчислювальним рішенням в індустрії технології блокчейн.Загальний робочий процес у мережі SMPC складатиметься з наступних трьох частин:
Крок 1: Перетворіть обчислені вхідні дані в спільні ресурси та розподіліть між вузлами SMPC.
Крок 2: Виконайте фактичні обчислення, зазвичай передбачаючи обмін повідомленнями між вузлами SMPC. Наприкінці цього кроку кожен вузол матиме частку обчисленого вихідного значення.
Крок 3: Надішліть спільний доступ до одного або кількох вузлів результатів, які запускають LSS (алгоритм відновлення секретного обміну) для реконструкції вихідного результату.
Уявіть собі лінію з виробництва автомобілів, де будівельні та виробничі компоненти автомобіля (двигун, двері, дзеркала) передані виробнику оригінального обладнання (OEM) (робочі вузли), а потім є складальна лінія, яка об’єднує всі компоненти зробити машину (в результаті вузол).
Обмін секретами важливий для моделі децентралізованих обчислень, що зберігає конфіденційність. Це запобігає отриманню єдиною стороною повного «секрету» (у цьому випадку введення) і зловмисному виведенню помилкових результатів. SMPC, мабуть, одна з найпростіших і найбезпечніших децентралізованих систем. Хоча повністю децентралізованої моделі наразі не існує, вона логічно можлива.
Такі постачальники MPC, як Sharemind, надають інфраструктуру MPC для обчислень, але постачальники все ще централізовані. Як забезпечити конфіденційність, як переконатися, що мережа (або Sharemind) не є зловмисною? Це походження обчислень zk proof і zk verifiable.
NMC — це новий метод розподілених обчислень, розроблений командою Nillion. Це оновлена версія MPC, де вузлам не потрібно спілкуватися, взаємодіючи через результати. Для цього вони використали криптографічний примітив під назвою One-Time Masking, який використовує серію випадкових чисел, які називаються факторами засліплення, щоб замаскувати секрет, подібно до одноразового заповнення. OTM має на меті забезпечити правильність ефективним способом, що означає, що вузлам NMC не потрібно обмінюватися повідомленнями для виконання обчислень. Це означає, що NMC не матиме проблем масштабованості SMPC.
ZK Verifiable Computation (ZK Verifiable Computation) призначений для створення доказу нульового знання для набору вхідних даних і функції, а також для підтвердження того, що будь-який обчислення, виконане системою, буде виконано правильно. Хоча розрахунок перевірки ZK є новим, він уже є дуже важливою частиною дорожньої карти розширення мережі Ethereum,
ZK доводить, що існують різні форми реалізації (як показано на малюнку нижче, згідно з підсумком у статті "Off-Chaining_Models"):
Вище ми маємо базове розуміння реалізації доказів zk, тож які умови для використання доказів ZK для перевірки обчислень?
Дилема розробника – дилема довести ефективність
Інша річ, яку я маю сказати, полягає в тому, що поріг для побудови схем все ще дуже високий. Розробникам нелегко вивчити Solidity. Тепер розробникам потрібно вивчати Circom, щоб створювати схеми, або вивчати певну мову програмування (наприклад, Cairo). створення zk-додатків здається далекою перспективою.
Як показує наведена вище статистика, **зробити середовище Web3 більш придатним для розробки видається більш стійким, ніж залучення розробників до нового середовища розробки Web3. **
Якщо ZK – це майбутнє Web3, а додатки Web3 потрібно створювати з використанням наявних навичок розробника, то схеми ZK мають бути розроблені таким чином, щоб вони підтримували обчислення, які виконуються алгоритмами, написаними на таких мовах, як Java або Rust, для створення доказів. .
Такі рішення існують, і я думаю про дві команди: RiscZero та Lurk Labs. Обидві команди поділяють дуже схоже бачення, що вони дозволяють розробникам створювати zk-додатки, не проходячи крутої кривої навчання.
Для Lurk Labs ще рано, але команда працювала над цим проектом протягом тривалого часу. Вони зосереджені на створенні доказів Nova через схеми загального призначення. Докази Nova запропонували Абхірам Котапаллі з Університету Карнегі-Меллона, Срінат Сетті з Microsoft Research і Іоанна Ціаллае з Нью-Йоркського університету. Порівняно з іншими системами SNARK, Nova має особливі переваги у виконанні інкрементних перевірених обчислень (IVC). Інкрементальне перевірене обчислення (IVC) — це концепція в інформатиці та криптографії, яка спрямована на забезпечення верифікації обчислення без повторного обчислення всього обчислення з нуля. Докази потрібно оптимізувати для IVC, коли час обчислення тривалий і складний.
Принадність дизайну мережі Bonsai полягає в тому, що обчислення можна ініціалізувати, перевірити та вивести в мережу. Все це звучить як утопія, але доказ STARK також приносить проблеми - вартість перевірки занадто висока.
Докази Nova, здається, добре підходять для повторних обчислень (його схема згортання є економічно ефективною) і невеликих обчислень, що може зробити Lurk хорошим рішенням для перевірки висновків ML.
Хто переможець?
(Джерело: IOSG Ventures)
Деякі системи zk-SNARK вимагають довіреного процесу налаштування під час початкової фази налаштування, генеруючи початковий набір параметрів. Припущення довіри тут полягає в тому, що довірені налаштування виконуються чесно, без будь-якої зловмисної поведінки чи втручання. У разі атаки це може призвести до створення недійсних доказів.
Докази STARK передбачають безпеку тестів нижчого порядку для перевірки властивостей поліномів нижчого порядку. Вони також припускають, що хеш-функції поводяться як випадкові оракули.
Правильне впровадження обох систем також є припущенням безпеки.
Мережа SMPC спирається на наступне:
*Учасники SMPC можуть включати «чесних, але цікавих» учасників, які можуть спробувати отримати доступ до будь-якої основної інформації, спілкуючись з іншими вузлами. *Безпека мережі SMPC ґрунтується на припущенні, що учасники правильно виконують протокол і навмисно не створюють помилок або зловмисної поведінки.
OTM — це багатосторонній протокол обчислень, призначений для захисту конфіденційності учасників. Це забезпечує захист конфіденційності, дозволяючи учасникам не розголошувати свої вхідні дані під час обчислення. Таким чином, «чесних, але цікавих» учасників не буде, оскільки вони не зможуть спілкуватися з іншими вузлами, намагаючись отримати доступ до основної інформації.
Чи є явний переможець? Ми не знаємо. Але кожен спосіб має свої переваги. Хоча NMC виглядає як очевидне оновлення до SMPC, мережа ще не активна чи не випробувана в боях.
Перевага використання верифікованих обчислень ZK полягає в тому, що вони безпечні та зберігають конфіденційність, але не мають вбудованого обміну секретами. Асиметрія між створенням доказів і перевіркою робить його ідеальною моделлю для аутсорсингових обчислень, які можна перевірити. Якщо система використовує чисті обчислення zk-proof, комп’ютер (або окремий вузол) має бути дуже потужним, щоб виконувати багато обчислень. Для того, щоб увімкнути розподіл навантаження та балансування, зберігаючи конфіденційність, має бути таємний розподіл. У цьому випадку систему, як-от SMPC або NMC, можна об’єднати з генератором zk, як-от Lurk або RiscZero, для створення потужної розподіленої перевірюваної обчислювальної інфраструктури.
Це стає ще більш важливим сьогодні, коли мережі MPC/SMPC централізовані. Найбільшим постачальником MPC зараз є Sharemind, і рівень перевірки ZK на його основі може виявитися корисним. Економічна модель децентралізованої мережі MPC ще не відпрацьована. Теоретично режим NMC є модернізацією системи MPC, але ми ще не бачили його успіху.
У змаганні за схеми перевірки ZK може не бути ситуації, коли переможець отримує все. Кожен метод перевірки оптимізований для певного типу обчислень, і жоден не підходить для всіх типів моделей. Існує багато типів обчислювальних завдань, і це також залежить від компромісів, які розробники роблять із кожною системою перевірки. Автор вважає, що як системам на базі STARK, так і системам на основі SNARK та їх майбутній оптимізації є місце в майбутньому ZK.