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, під керівництвом основних команд розробників (наприклад, Succinct), на високопродуктивному zkVM.

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

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

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

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

Що ж змінилося?

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

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

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

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

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

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

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

Причина заміни EVM полягає не в одній конкретній ваді, а у сукупності фундаментальних обмежень, які в майбутньому з акцентом на zero-knowledge proof вже не можна ігнорувати. Сюди входять вузькі місця продуктивності в ZK-системах та зростаюча складність протоколу, що підвищує ризики.

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

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

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

Цей додатковий шар інтерпретації призводить до величезних втрат продуктивності. Оцінки показують, що порівняно з доказом нативної програми, цей шар може уповільнити продуктивність у 50–800 разів. Після оптимізації інших вузьких місць (наприклад, переходу на Poseidon hash), ця частина «виконання блоку» все одно займає 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 може скористатися десятиліттями колективного прогресу у комп’ютерних науках. Як пояснює Джастін Дрейк, це дає Ethereum можливість безпосередньо використовувати світового класу інструменти:

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

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

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

Де-факто стандарт у сфері zero-knowledge proof Ще важливіше, що екосистема zkVM вже зробила свій вибір. Як зазначає Джастін Дрейк, дані 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 надає «золотий стандарт», що дозволяє доводити математичну коректність — критично важливо для захисту протоколу з величезною вартістю. Як зазначає Алекс Хікс з Ethereum Foundation на Ethproofs, це дозволяє zkVM-колу безпосередньо «верифікуватися з офіційною специфікацією RISC-V». По-друге, RISC-V містить привілейовану архітектуру — часто недооцінювану, але критично важливу для безпеки. Вона визначає різні рівні операцій, зокрема user mode (для недовірених застосунків, як смарт-контракти) і supervisor mode (для довіреного «ядра виконання»). Дієго з Cartesi пояснює це так:

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

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

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

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

Крок перший: заміна попередньо скомпільованих контрактів

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

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

· Спрощення стеку технологій: 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, і їхня робота є потужним доказом життєздатності цієї пропозиції.

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

Вплив Succinct Labs вже відчутний. Їхній продукт OP Succinct використовує SP1 для надання Optimistic Rollups можливостей zero-knowledge proof (ZK-ify). Як пояснює співзасновниця Succinct Ума Рой:

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

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

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

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

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

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

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

Проблема обліку Gas

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

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

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

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

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

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

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

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

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

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

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

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

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

Ця трансформація зосереджена на низці ключових компромісів:

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

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

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

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

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

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

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

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