Ethereum може отримати найбільше оновлення в історії: EVM буде відключено, а керування перейде до RISC-V

Оригінальна назва: Goodbye EVM, Hello RISC-V

Оригінальний автор: jaehaerys.eth, крипто-дослідник

Оригінальний переклад: TechFlow

Резюме

Ethereum готується до найважливішої архітектурної трансформації з моменту свого створення: заміна EVM на RISC-V.

Причина проста — у майбутньому, де Zero Knowledge (ZK) є ядром, EVM вже став вузьким місцем продуктивності:

· Поточний zkEVM покладається на інтерпретатор, що призводить до уповільнення продуктивності у 50–800 разів;

· Модулі препроцесування ускладнюють протокол і підвищують ризики;

· 256-бітний стек надзвичайно неефективний при генерації доказів.

Рішення RISC-V:

· Мінімалістичний дизайн (близько 47 базових інструкцій) + зріла екосистема LLVM (підтримка Rust, C++, Go тощо);

· Вже став де-факто стандартом zkVM (90% проєктів використовують);

· Має формальну специфікацію SAIL (на відміну від розмитої Yellow Paper) → забезпечує сувалу верифікацію;

· Шлях до апаратних доказів (ASICs/FPGAs) вже тестується (SP1, Nervos, Cartesi тощо).

Процес міграції складається з трьох етапів:

· Заміна препроцесування на RISC-V (низькоризикове тестування);

· Епоха двох віртуальних машин: EVM та RISC-V співіснують і повністю взаємодіють;

· Реалізація EVM всередині RISC-V (стратегія Rosetta).

Вплив на екосистему:

· Optimistic Rollup (наприклад, Arbitrum та Optimism) повинні перебудувати механізм fraud proof;

· Zero Knowledge Rollup (наприклад, Polygon, zkSync, Scroll) отримають величезну перевагу → дешевше, швидше, простіше;

· Розробники зможуть безпосередньо використовувати бібліотеки мов Rust, Go та Python на L1;

· Користувачі отримають докази приблизно у 100 разів дешевше → шлях до Gigagas L1 (близько 10,000 TPS).

Зрештою, Ethereum еволюціонує з «віртуальної машини смарт-контрактів» у мінімалістичний, верифікований шар довіри для Інтернету, з кінцевою метою — «ZK-Snark-ізувати все».

Роздоріжжя Ethereum

Віталік Бутерін колись сказав: «Кінцева мета — ... зробити все ZK-Snark-ізованим».

Кінцева гра Zero Knowledge Proof (ZK) вже неминуча, і її основний аргумент простий: Ethereum перебудовується з нуля на основі Zero Knowledge Proof. Це знаменує технологічний кінець протоколу — досягнення його остаточної форми через перебудову L1, керовану високопродуктивним zkVM, підтримуваним основними командами розробників (наприклад, Succinct).

З цією візією як кінцевою точкою, Ethereum стоїть на порозі найважливішої архітектурної трансформації з моменту створення. Це вже не питання поступових оновлень, а повна перебудова обчислювального ядра — заміна Ethereum Virtual Machine (EVM). Цей крок є наріжним каменем ширшої візії «Lean Ethereum».

Візія Lean Ethereum полягає у системному спрощенні всього протоколу, розділенні його на три основні модулі: Lean Consensus, Lean Data та Lean Execution. У центрі проблеми Lean Execution — ключове питання: чи стала EVM, як рушій революції смарт-контрактів, основним вузьким місцем для майбутнього розвитку Ethereum?

Як зазначає Justin Drake з Ethereum Foundation, довгострокова мета Ethereum завжди була «Snarkify everything» — потужний інструмент для посилення всіх рівнів протоколу. Проте довгий час це було «далекою мрією», оскільки для її досягнення потрібна була концепція real-time proving. Тепер, коли реальний час доказів стає реальністю, теоретична неефективність EVM перетворилася на нагальну практичну проблему.

У цій статті буде детально проаналізовано технічні та стратегічні аргументи щодо міграції Ethereum L1 на архітектуру інструкцій RISC-V (ISA). Цей крок обіцяє не лише небачену масштабованість, а й спрощення структури протоколу та узгодження Ethereum з майбутнім верифікованих обчислень.

Що саме змінилося?

Перш ніж обговорювати «чому», потрібно чітко визначити, «що» змінюється.

EVM (Ethereum Virtual Machine) — це середовище виконання смарт-контрактів Ethereum, відоме як «світовий комп’ютер», що обробляє транзакції та оновлює стан блокчейну. Протягом багатьох років її дизайн був революційним, заклавши основу для DeFi та NFT екосистем. Однак ця майже десятирічна спеціалізована архітектура накопичила значний технічний борг.

На відміну від цього, RISC-V — це не продукт, а відкритий стандарт — безкоштовний, універсальний «алфавіт» для дизайну процесорів. Як підкреслив Jeremy Bruestle на конференції Ethproofs, його ключові принципи роблять його ідеальним для цієї ролі:

· Мінімалізм: Базовий набір інструкцій RISC-V надзвичайно простий, містить лише близько 40–47 інструкцій. Як зазначає Jeremy, це робить його «майже ідеальним для нашого випадку використання надзвичайно мінімалістичної універсальної машини».

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

· Відкрита екосистема: RISC-V має велику та зрілу підтримку інструментів, включаючи компілятор LLVM, що дозволяє розробникам використовувати популярні мови програмування, такі як Rust, C++ та Go. Як зазначає Justin Drake: «Інструменти навколо компіляторів дуже багаті, а створення компіляторів надзвичайно складне... Тому цінність цих інструментів компілятора дуже висока». RISC-V дозволяє Ethereum безкоштовно успадковувати ці готові інструменти.

Проблема накладних витрат інтерпретатора

Причина заміни EVM — не один недолік, а сукупність фундаментальних обмежень, які у майбутньому з фокусом на Zero Knowledge Proof вже не можна ігнорувати. Це обмеження продуктивності у ZK-системах та ризики, пов’язані зі зростаючою складністю протоколу.

Найнагальніший драйвер цієї трансформації — вроджена неефективність EVM у системах Zero Knowledge Proof. У міру того, як Ethereum переходить до моделі перевірки стану L1 через ZK-докази, продуктивність доказувачів стає головним вузьким місцем.

Проблема у тому, як працює поточний zkEVM. Вони не доводять EVM безпосередньо, а доводять інтерпретатор EVM, який сам компілюється у RISC-V. Віталік Бутерін прямо вказує на цю ключову проблему:

«...Якщо реалізація zkVM — це компіляція виконання EVM у щось, що зрештою стає кодом RISC-V, то чому б не відкрити базовий RISC-V для розробників смарт-контрактів? Це дозволить повністю уникнути накладних витрат зовнішньої віртуальної машини».

Цей додатковий шар інтерпретації призводить до величезних втрат продуктивності. Оцінки показують, що порівняно з доказом нативної програми, цей шар може призвести до уповільнення у 50–800 разів. Після оптимізації інших вузьких місць (наприклад, переходу на хеш-алгоритм Poseidon), ця частина «виконання блоку» все ще займає 80–90% часу доказу, роблячи EVM остаточним і найскладнішим бар’єром для масштабування L1. Усунувши цей шар, Віталік очікує підвищення ефективності виконання у 100 разів.

Пастка технічного боргу

Щоб компенсувати недостатню продуктивність EVM у певних криптографічних операціях, Ethereum ввів препроцесовані контракти — спеціалізовані функції, жорстко закодовані у протоколі. Хоча це було практичним рішенням на той час, зараз це призвело до «жахливої» ситуації, як зазначає Віталік Бутерін:

«Препроцесування для нас катастрофічне... Вони значно роздули довірений код Ethereum... і вже кілька разів призводили до майже фатальних проблем із консенсусом».

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

«Я вважаю, що ми повинні припинити додавати будь-які нові препроцесовані контракти з сьогоднішнього дня».

Технічний борг архітектури Ethereum

Ядро дизайну EVM відображає пріоритети минулої епохи, але воно вже не відповідає сучасним обчислювальним потребам. EVM обрала 256-бітну архітектуру для обробки криптографічних значень, але для типових 32- чи 64-бітних цілих чисел у смарт-контрактах це надзвичайно неефективно. Ця неефективність особливо дорога у ZK-системах. Як пояснює Віталік:

«Коли ви використовуєте менші числа, кожне число насправді не економить жодних ресурсів, а складність зростає у 2–4 рази».

Крім того, стекова архітектура EVM менш ефективна, ніж регістрова архітектура RISC-V та сучасних CPU. Вона вимагає більше інструкцій для виконання тих самих операцій і ускладнює оптимізацію компілятора.

Ці проблеми — включаючи вузькі місця продуктивності ZK-доказів, складність препроцесування та застарілі архітектурні вибори — разом створюють переконливу і нагальну причину: Ethereum повинен перейти за межі EVM до більш відповідної для майбутнього технологічної архітектури.

RISC-V як план: перебудова майбутнього Ethereum на міцнішій основі

Переваги RISC-V полягають не лише у недоліках EVM, а й у внутрішній силі його філософії дизайну. Його архітектура забезпечує міцну, просту та верифіковану основу, ідеальну для такого високоризикового середовища, як Ethereum.

Чому відкритий стандарт кращий за кастомний дизайн?

На відміну від кастомних архітектур інструкцій (ISA), які потребують створення всієї екосистеми з нуля, RISC-V — це зрілий відкритий стандарт із трьома ключовими перевагами:

Зріла екосистема

Використовуючи RISC-V, Ethereum може скористатися десятиліттями колективного прогресу у комп’ютерних науках. Як пояснює Justin Drake, це дає Ethereum можливість використовувати світового класу інструменти:

«Є інфраструктурний компонент під назвою LLVM — це набір компіляторних інструментів, який дозволяє компілювати високорівневі мови програмування у різні бекенди. Один із підтримуваних бекендів — це RISC-V. Тому, якщо ви підтримуєте RISC-V, ви автоматично підтримуєте всі високорівневі мови, які підтримує LLVM».

Це значно знижує поріг входу для розробників, дозволяючи мільйонам тих, хто знайомий із Rust, C++ і Go, легко почати працювати.

Мінімалістична філософія дизайну Мінімалізм RISC-V — це навмисна особливість, а не обмеження. Його базовий набір інструкцій містить лише близько 47 інструкцій, що дозволяє ядру віртуальної машини залишатися надзвичайно простим. Ця простота має значні переваги для безпеки, оскільки менший довірений код легше аудіювати та формально верифікувати.

Де-факто стандарт у сфері Zero Knowledge Proof Ще важливіше, що екосистема zkVM вже зробила свій вибір. Як зазначає Justin Drake, дані Ethproofs показують чітку тенденцію:

«RISC-V — це провідна архітектура інструкцій (ISA) для бекенду zkVM».

Серед десяти zkVM, здатних доводити блоки Ethereum, дев’ять обрали RISC-V як цільову архітектуру. Така ринкова конвергенція є потужним сигналом: приймаючи RISC-V, Ethereum не робить спекулятивної ставки, а узгоджується зі стандартом, який вже довів свою ефективність і був обраний для побудови zero knowledge майбутнього.

Створений для довіри, не лише для виконання

Окрім широкої екосистеми, внутрішня архітектура RISC-V особливо підходить для побудови безпечних і верифікованих систем. По-перше, RISC-V має формалізовану, машинно-читабельну специфікацію — SAIL. Це величезний крок уперед порівняно зі специфікацією EVM (яка переважно існує у вигляді тексту Yellow Paper). Yellow Paper містить певну розмитість, тоді як SAIL надає «золотий стандарт», що дозволяє підтримувати ключові математичні докази коректності — критично важливо для захисту протоколу з величезною вартістю. Як зазначає Alex Hicks з Ethereum Foundation на Ethproofs, це дозволяє zkVM-колам безпосередньо «верифікуватися з офіційною специфікацією RISC-V». По-друге, RISC-V містить привілейовану архітектуру — часто ігноровану, але важливу для безпеки. Вона визначає різні рівні операцій, головним чином user mode (для недовірених застосунків, як смарт-контракти) і supervisor mode (для довіреного «ядра виконання»). Diego з Cartesi пояснює це так:

«Операційна система повинна захищати себе від іншого коду. Вона повинна ізолювати різні програми, і всі ці механізми є частиною стандарту RISC-V».

У архітектурі RISC-V смарт-контракти, що працюють у user mode, не можуть безпосередньо отримати доступ до стану блокчейну. Натомість вони повинні надсилати запит через спеціальну інструкцію ECALL до довіреного ядра, що працює у supervisor mode. Такий механізм створює апаратно забезпечену межу безпеки, яка є більш надійною та легко верифікованою, ніж модель EVM, що покладається лише на програмну пісочницю.

Візія Віталіка

Ця трансформація задумана як поступовий, багатоступеневий процес для забезпечення стабільності системи та зворотної сумісності. Як пояснює засновник Ethereum Віталік Бутерін, цей підхід має на меті «еволюційний» розвиток, а не радикальну «революційну» зміну.

Крок перший: Заміна препроцесування

Початковий етап — найконсервативніший, із впровадженням обмеженої функціональності нової віртуальної машини (VM). Як пропонує Віталік Бутерін: «Ми можемо почати використовувати нову VM у обмежених сценаріях, наприклад, для заміни препроцесованих функцій». Зокрема, це призупинить додавання нових препроцесованих функцій у EVM, замінивши їх реалізацією необхідних функцій через затверджені білим списком програми RISC-V. Такий підхід дозволяє новій VM проходити бойове тестування у основній мережі з низьким ризиком, при цьому клієнти Ethereum виступають посередниками між двома середовищами виконання.

Крок другий: Співіснування двох віртуальних машин

Наступний етап — «дозволити новій VM бути безпосередньо доступною для користувачів». Смарт-контракти можуть позначати, чи є їх байткод EVM чи RISC-V. Ключова особливість — безшовна взаємодія: «Обидва типи контрактів можуть викликати один одного». Це буде реалізовано через системні виклики (ECALL), дозволяючи двом VM співпрацювати в одній екосистемі.

Крок третій: EVM як емуляційний контракт (стратегія «Rosetta»)

Кінцева мета — максимальне спрощення протоколу. На цьому етапі «ми реалізуємо EVM як одну з реалізацій нової VM». Нормалізований EVM стане формально верифікованим смарт-контрактом, що працює на нативному RISC-V L1. Це не лише гарантує постійну підтримку старих застосунків, а й дозволяє розробникам клієнтів підтримувати лише один спрощений рушій виконання, значно знижуючи складність і витрати на обслуговування.

Ефект хвиль для екосистеми

Перехід від EVM до RISC-V — це не лише зміна ядра протоколу, а й глибокий вплив на всю екосистему Ethereum. Ця трансформація не лише змінить досвід розробників, а й докорінно змінить конкурентний ландшафт Layer-2 рішень і відкриє нові економічні моделі верифікації.

Перепозиціонування Rollup: Протистояння Optimistic та ZK

Використання RISC-V як виконуючого шару на L1 матиме різний вплив на два основних типи Rollup.

Optimistic Rollup (наприклад, Arbitrum, Optimism) стикаються з архітектурними викликами. Їх модель безпеки покладається на повторне виконання спірних транзакцій у L1 EVM для fraud proof. Якщо EVM на L1 буде замінено, ця модель повністю зруйнується. Ці проєкти повинні будуть або провести масштабну інженерну перебудову, створивши fraud proof для нової VM L1, або повністю відмовитися від моделі безпеки Ethereum.

На відміну від цього, ZK Rollup отримають величезну стратегічну перевагу. Переважна більшість ZK Rollup вже використовують RISC-V як свою внутрішню архітектуру інструкцій (ISA). L1, що «говорить тією ж мовою», дозволить їм досягти тіснішої та ефективнішої інтеграції. Justin Drake пропонує бачення майбутнього «нативних Rollup»: L2 фактично стає спеціалізованим екземпляром середовища виконання L1, використовуючи вбудовану VM L1 для безшовного розрахунку. Таке узгодження призведе до наступних змін:

· Спрощення технічного стеку: Команди L2 більше не повинні будувати складні містки між внутрішнім середовищем виконання RISC-V та EVM.

· Повторне використання інструментів і коду: Компілятори, дебагери та інструменти формальної верифікації, розроблені для L1 RISC-V, можуть безпосередньо використовуватися L2, значно знижуючи витрати на розробку.

· Узгодження економічних стимулів: Gas-фі L1 точніше відображатимуть реальні витрати на ZK-верифікацію на основі RISC-V, формуючи більш справедливу економічну модель.

Нова епоха для розробників і користувачів

Для розробників Ethereum ця трансформація буде поступовою, а не руйнівною.

Розробники отримають доступ до ширшої та зрілішої екосистеми розробки ПЗ. Як зазначає Віталік Бутерін, розробники «зможуть писати контракти на Rust, і ці опції можуть співіснувати». Водночас він прогнозує, що «Solidity і Vyper залишаться популярними завдяки своїй елегантності для логіки смарт-контрактів». Можливість використовувати основні мови програмування та їх великі бібліотеки через LLVM — це революційна зміна. Віталік порівнює це з «досвідом NodeJS», коли розробники можуть писати on-chain та off-chain код однією мовою, досягаючи інтегрованої розробки.

Для користувачів ця трансформація зрештою принесе нижчі витрати та вищу продуктивність мережі. Очікується, що витрати на докази знизяться приблизно у 100 разів — з кількох доларів за транзакцію до кількох центів або навіть менше. Це безпосередньо призведе до нижчих L1 та L2 комісій за розрахунки. Така економічна доцільність відкриє шлях до бачення «Gigagas L1» із продуктивністю близько 10,000 TPS, прокладаючи шлях для складніших і цінніших on-chain застосунків у майбутньому.

Succinct Labs і SP1: Будуючи майбутнє доказів вже сьогодні

Ethereum готується до прориву. «Масштабування L1, масштабування блоків» — це стратегічне завдання для EF Protocol Cluster. Очікується, що протягом наступних 6–12 місяців буде досягнуто значного підвищення продуктивності.

Команди на кшталт Succinct Labs вже на практиці демонструють теоретичні переваги RISC-V, і їхня робота є потужним доказом життєздатності цієї пропозиції.

SP1 від Succinct Labs — це високопродуктивний, відкритий zkVM на основі RISC-V, який підтверджує життєздатність нового архітектурного підходу. SP1 дотримується філософії «precompile-centric», ідеально вирішуючи криптографічні вузькі місця EVM. На відміну від традиційного повільного, жорстко закодованого препроцесування, SP1 передає інтенсивні операції, такі як Keccak-хешування, у спеціально розроблені, вручну оптимізовані ZK-кола, викликаючи їх через стандартну інструкцію ECALL. Такий підхід поєднує продуктивність кастомного заліза з гнучкістю ПЗ, надаючи розробникам ефективніше та масштабоване рішення.

Реальний вплив Succinct Labs вже помітний. Їхній продукт OP Succinct використовує SP1 для надання Zero Knowledge Proof можливостей Optimistic Rollups (ZK-ify). Як пояснює співзасновниця Succinct Uma Roy:

«Rollup, що використовують OP Stack, більше не потрібно чекати сім днів для остаточного підтвердження та виведення коштів... Тепер підтвердження займає лише годину. Це значне підвищення швидкості».

Цей прорив вирішує ключову проблему всієї екосистеми OP Stack. Крім того, інфраструктура Succinct — Succinct Prover Network — задумана як децентралізований ринок генерації доказів, демонструючи життєздатну економічну модель для майбутнього верифікованих обчислень. Їхня робота — це не лише proof-of-concept, а й реальний план майбутнього, як описано у цій статті.

Як Ethereum знижує ризики

Одна з головних переваг RISC-V — це те, що він робить досяжною «святий Грааль» формальної верифікації — математичний доказ коректності системи. Специфікація EVM написана природною мовою у Yellow Paper, що ускладнює формалізацію. Натомість RISC-V має офіційну, машинно-читабельну специфікацію SAIL, яка забезпечує чітке «золоте посилання» для його поведінки.

Це прокладає шлях до підвищеної безпеки. Як зазначає Alex Hicks з Ethereum Foundation, вже ведеться робота з «формальної верифікації zkVM RISC-V-кол із офіційною специфікацією RISC-V, імпортованою у Lean». Це знаковий крок, який переносить довіру від схильних до помилок людських реалізацій до верифікованих математичних доказів, відкриваючи новий рівень безпеки блокчейну.

Основні ризики трансформації

Попри численні переваги L1 на архітектурі RISC-V, це також приносить нові складні виклики.

Проблема вимірювання Gas

Створення детермінованої та справедливої моделі Gas для універсальної архітектури інструкцій (ISA) — це ще не вирішене завдання. Простий підрахунок інструкцій вразливий до атак відмови в обслуговуванні. Наприклад, зловмисник може створити програму, яка багаторазово викликає cache miss, споживаючи багато ресурсів за мінімальні Gas-витрати. Це серйозний виклик для стабільності мережі та економічної моделі.

Безпека інструментів і проблема «відтворюваних збірок»

Це найважливіший і водночас недооцінений ризик у процесі трансформації. Модель безпеки переходить від залежності від on-chain VM до off-chain компіляторів (наприклад, LLVM), які надзвичайно складні та мають відомі вразливості. Зловмисники можуть використати вразливості компілятора, щоб перетворити безпечний вихідний код на шкідливий байткод. Крім того, забезпечення повної відповідності on-chain бінарника відкритому вихідному коду — проблема «відтворюваних збірок» — також надзвичайно складна. Навіть незначні відмінності у середовищі збірки можуть призвести до різних бінарників, що впливає на прозорість і довіру. Це серйозний виклик для безпеки розробників і користувачів.

Стратегії пом’якшення ризиків

Подальший шлях вимагає багаторівневої стратегії захисту.

Поступове впровадження

Поступовий, багатоступеневий план переходу — ключова стратегія для управління ризиками. Починаючи з впровадження RISC-V як заміни препроцесування, а потім у середовищі двох VM, спільнота може накопичити досвід і впевненість у низькоризиковому середовищі, уникаючи незворотних змін. Такий поступовий підхід забезпечує стабільну основу для технологічної трансформації.

Комплексний аудит: fuzz-тестування та формальна верифікація

Попри те, що формальна верифікація — кінцева мета, вона повинна поєднуватися з постійним, інтенсивним тестуванням. Як показав Valentine з Diligence Security на дзвінку Ethproofs, їхній fuzz-тестер Argus вже виявив 11 критичних вразливостей цілісності та повноти у провідних zkVM. Це свідчить, що навіть найкраще спроєктовані системи можуть містити вразливості, які можна знайти лише через суворе тестування. Поєднання fuzz-тестування та формальної верифікації забезпечує найвищий рівень безпеки.

Стандартизація

Щоб уникнути фрагментації екосистеми, спільнота повинна прийняти єдину, стандартизовану конфігурацію RISC-V. Це, ймовірно, буде комбінація RV64GC з Linux-сумісним ABI, оскільки вона має найширшу підтримку у популярних мовах і інструментах, максимізуючи переваги нової екосистеми. Стандартизація підвищує ефективність розробників і закладає міцну основу для довгострокового розвитку екосистеми.

Верифіковане майбутнє Ethereum

Пропозиція замінити Ethereum Virtual Machine (EVM) на RISC-V — це не просто поступове оновлення, а фундаментальна перебудова виконуючого шару Ethereum. Це амбітне бачення має на меті вирішити глибокі проблеми масштабованості, спростити складність протоколу та узгодити платформу з ширшою екосистемою універсальних обчислень. Попри величезні технічні та соціальні виклики, довгострокові стратегічні вигоди виправдовують цю сміливу ініціативу.

Трансформація фокусується на низці ключових компромісів:

· Баланс між величезним приростом продуктивності ZK-нативної архітектури та нагальною потребою у зворотній сумісності;

· Вибір між перевагами безпеки від спрощення протоколу та інерцією величезного мережевого ефекту EVM;

· Вибір між потужністю універсальної екосистеми та ризиками залежності від складних сторонніх інструментів.

Зрештою, ця архітектурна трансформація стане ключем до виконання обіцянки «Lean Execution» і важливою частиною візії «Lean Ethereum». Вона перетворить L1 Ethereum із простої платформи смарт-контрактів на ефективний і безпечний шар розрахунків і доступності даних, спеціально створений для підтримки всесвіту верифікованих обчислень.

Як сказав Віталік Бутерін: «Кінцева мета — ... забезпечити ZK-snark для всього».

Такі проєкти, як Ethproofs, надають об’єктивні дані та платформу для співпраці, а команда Succinct Labs через практичне застосування SP1 zkVM пропонує реальний план для цього майбутнього. Приймаючи RISC-V, Ethereum не лише вирішує власні проблеми масштабованості, а й позиціонує себе як базовий шар довіри для Інтернету наступного покоління — керований третьою криптографічною примітивою після хешів і підписів — SNARK.

Доведіть програмне забезпечення світу, відкрийте нову еру криптографії.

Дізнатися більше: