УД;НЧ

1. 1. Декілька провідних венчурних капіталістів, включаючи Paradigm, Jump та Dragonfly, інвестують у концепцію Parallel EVM.
2. 1. Представницькі проекти в цій галузі включають Monad, Sei, MegaETH, Polygon, Neon EVM та BSC, які працюють як на рішеннях Першого рівня (L1), так і на рішеннях Другого рівня (L2).
3. 1. Однак є обмежена загальнодоступна інформація про конкретні відмінності між командами.
4. 1. Хоча «паралелізація» є буквальним значенням Parallel EVM, це позначає спеціалізовану оптимізацію, спрямовану на покращення різних аспектів продуктивності EVM, що потенційно може розширити межі можливостей EVM.
5. 1. Виклики включають потребу у рефакторингу всього технологічного стеку та вирішенні проблем, таких як передбачення конфліктів між паралельними транзакціями та ефективне вирішення конфліктів у разі їх виникнення.
6. 1. Ще одним викликом є встановлення відмінностей в екосистемі відкритого коду, збалансовуючи децентралізацію з продуктивністю.

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

Увага на Паралельний EVM, також відомий як паралелізація EVM, зростала, коли Георгіос Константопулос, головний технічний директор Paradigm, і Хасіб Куреші з Dragonfly випадково підкреслили цей концепт наприкінці 2023 року, обговорюючи майбутні тенденції на 2024 рік. Незважаючи на цю увагу, докладні обговорення з цього питання були розріджені, що призвело до того, що багато хто відкидає його як щось особливо нове. Оскільки як Ethereum Virtual Machine (EVM), так і паралельне обчислення є добре встановленими поняттями, те, що піднімає злиття цих двох термінів до статусу важливого експериментального тренду, залишається невизначеним.

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

Основною перевагою Parallel EVM є його здатність надавати існуючим децентралізованим додаткам можливість досягнення рівня продуктивності, подібного до того, який є в Інтернеті. Фактично, можна стверджувати, що Parallel EVM стоїть окремо як нова технологія, здатна використовувати велику кількість встановлених смарт-контрактів та досягати високої продуктивності та паралельної пропускної здатності на публічних ланцюжках.

Парадигма довгий час очікувала вступити в гру, Jump сильно інвестує

За даними журналу "Fortune", Paradigm має намір очолити останній раунд фінансування для Monad з метою залучити $200 мільйонів за оцінкою у $3 мільярди. Це позначає перший випадок Paradigm у підтримці команди з концепцією Parallel EVM, але вони уважно стежили за цією технологією протягом кількох років. Георгіос Константопулос, головний технічний директор Paradigm, вперше згадав цей термін у 2021 році.

Етимологія терміну «Монада» додає ще один рівень інтриги. У філософській системі Лейбніца Монада означає фундаментальний елемент, що складає всесвіт. Ці недільні сутності залишаються непроникними для фізичних впливів, кожна з них відображає увесь всесвіт, відомий як «单子» у китайській мові.

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

Значним відомостям є лінгвістична симетрія між Монадою та Номадом, останнє позначає странця, а "цифровий номад" посилається на странця у цифровій сфері.

Георгіос, у своєму виступі зазначив також Сей та Полігон. Однак його оптимізм стосовно Паралельного EVM посилюється розвитком Рет, клієнта Ethereum, розробленого Paradigm. Позиціонуючись як швидкодіючий клієнт екзекуційного шару Ethereum, побудований на Rust, Рет швидко розвивається і недавно перейшов на бета-стадію. Хоча можливість інтеграції Паралельного EVM безпосередньо в Рет вважається, значний інженерний зусилля, що потрібне, вказує на те, що підтримка Паралельного EVM через інвестиції в інші команди може бути більш життєздатним варіантом. Документація Monad відкриває їх переважне використання C++ та Rust у їхніх інженерних зусиллях.

Після створення Reth з'явилися обвинувачення від членів команди Erigon, які стверджують, що відбулось плагіат їх відкритого коду Akula, що призвело до зменшення фінансування проекту Akula. Георгіос спростував ці заяви, стверджуючи, що Reth не є похідним або форком будь-якого іншого клієнта, хоча він бере натхнення з Geth, Erigon та Akula.

Ще одним ключовим гравцем є Jump Trading та Jump Capital, засновник Monad походить з Jump Trading, що має великий досвід у високочастотній торгівлі. Sei вважає Jump Capital серед своїх інвесторів, а участь Jump виявляється глибоко в екосистемі Solana, охоплюючи інфраструктуру та проекти.

Dragonfly, ранній інвестор в Monad, також тримав руку на пульсі стосовно пов'язаних подій, з інвестиціями в NEAR, фокусуючись на технології розділення, поряд з Aptos, Avalanche, Nervos та іншими публічними ланцюжками.

Оновлення алгоритмів узгодження недостатньо, нарешті час виконавчого рівня

У недавніх битвах серед громадських ланцюжків увага постійно обминала шар виконання, замість цього майже виключно фіксувалася на інноваційних алгоритмах консенсусу, чи то це буде Solana, Avalanche, чи EOS, серед інших. Незважаючи на значні інновації в шарі виконання цими ланцюжками, спільнота має тенденцію в основному згадувати їх використані алгоритми консенсусу. Більше того, в спільноті панує уява, що виняткову продуктивність цих високошвидкісних громадських ланцюжків забезпечує виключно їхні революційні алгоритми консенсусу.

Однак досягнення високопродуктивного громадського ланцюга передбачає симбіотичні відносини між алгоритмом консенсусу та шаром виконання, віддзеркалюючи принцип того, що ланцюг міцний лише наскільки міцний його найслабший ланцюг. Громадські ланцюги, які покладаються на віртуальну машину Ethereum (EVM) та виключно спрямовані на покращення свого алгоритму консенсусу, стикаються з обмеженнями продуктивності, які вимагають все більш міцних вузлів. Візьміть, наприклад, Binance Smart Chain (BSC), який обмежує обробку газових блоків на рівні 2000 транзакцій на секунду (TPS). Для підтримки цього конфігурації вузлів повинні перевищувати ті, які має повноцінний вузол Ethereum у декілька разів. Хоча Polygon теоретично має місткість 1000 TPS, на практиці він зазвичай досягає лише десятків до сотень.

Ноди архіву BSC потребують мінімум 16-ядерних процесорів і 128 ГБ пам'яті, у порівнянні з вузлами Ethereum, які вимагають щонайменше 4-ядерні процесори і 16 ГБ пам'яті.

Розпізнавши ці виклики, команда BSC увійшла в співпрацю з NodeReal для розробки технології Parallel EVM. Ця інновація спрямована на подальше підвищення пропускної здатності транзакцій на блок, дозволяючи паралельне виконання транзакцій та відповідно підвищуючи верхній ліміт TPS.

Паралельно: оновлення з одноядерного на багатоядерний ЦП

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

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

Для непов'язаних розумних контрактів, що виконуються паралельно, пропускна здатність може бути подальше збільшена за рахунок масштабування відповідно до кількості одночасних оброблювальних потоків. Крім того, Паралельний EVM не тільки розширює паралельні можливості, але й підвищує ефективність виконання одного потоку. Кіоне Хон, генеральний директор Monad, підкреслив, що основним обмеженням EVM є часті читання та записи станів. Він підкреслив, що хоча паралельне виконання є ключовим аспектом дорожньої карти, загальна мета Monad - оптимізувати ефективність EVM до максимуму.

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

EVM не дорівнює Solidity

Написання розумних контрактів - важлива навичка для розробників блокчейнів, яка вимагає здатності реалізувати логіку на основі бізнес-вимог за допомогою Solidity або інших мов високого рівня. Однак Ethereum Virtual Machine (EVM) не розуміє логіку Solidity безпосередньо; для виконання необхідно перекласти її в машинний код низького рівня. Розробники Solidity зазвичай користуються існуючими інструментами для обробки цього процесу перекладу.

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

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

Відмінності в продуктивності EVM, «Стандарт» не дорівнює «інженерній практиці»

Двигун, де розумні контракти компілюються в опкоди та обробляються, часто називається "шаром виконання" або "віртуальна машина." Байткод, встановлений Віртуальною Машиною Ethereum (EVM), став стандартом промисловості. Незалежно від того, чи йдеться про мережі другого рівня Ethereum, чи про інші незалежні публічні ланцюги, сумісність зі стандартом EVM має велике значення. Розробники користуються можливістю написати розумний контракт один раз і розгорнути його на кількох мережах, що призводить до значних економічних вигід.

Хоча дотримання стандарту байткоду EVM вважає систему сумісною з EVM, методи реалізації можуть значно відрізнятися. Наприклад, клієнт Ethereum Geth використовує мову Go для реалізації стандарту EVM, тоді як дослідницька команда Фонду Ethereum Ipsilon підтримує незалежну реалізацію EVM, розроблену на C++. Інші клієнти Ethereum можуть безпосередньо використовувати цю реалізацію як двигун виконання EVM.

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

Існування реалізацій, таких як evmone, свідчить про можливість альтернативних підходів. Відповідно, в контексті EVM стандарт визначає фундаментальні операції байткоду (наприклад, основні арифметичні функції, такі як додавання, віднімання, множення), кожен байткод надає конкретний результат на основі визначених входів. Хоча виконання цього стандарту є важливим, методології, що застосовуються на практиці, можуть значно відрізнятися, надаючи достатньо місця для налаштувань та інженерних оптимізацій.

Схожості та відмінності паралельного EVM

У паралельному треку EVM, крім широко відомого Monad, інші видатні учасники включають Sei, MegaETH, Polygon, Neon EVM, BSC та клієнт Reth Paradigm, який також прагне інтегрувати паралелизм.

Щодо їх позиціонування, Monad, Sei, Polygon та BSC категоризуються як блокчейни 1-го рівня, тоді як MegaETH може потенційно працювати як рішення 2-го рівня, а Neon EVM працює в межах рамок мережі Solana. Крім того, Reth виділяється як клієнт з відкритим вихідним кодом, причому MegaETH готується продовжувати свій розвиток, використовуючи певні аспекти інженерії Reth.

Природно, існує конкуренція між цими командами, і повні технічні характеристики та інженерна документація ще не були повністю розкриті. Для подальших порівнянь доведеться зачекати поступового виявлення у майбутньому. Ця динаміка може нагадувати гонку озброєнь, схожу на події, які були помічені в BTC Layer 2, Restaking та Ethereum Layer 2. Незважаючи на відтінки технічних відмінностей та відкритий характер цих проектів, вирішальним фактором є встановлення відмінності кожної екосистеми.

Технічні виклики паралельного EVM

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

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

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

Крім інженерних реалізацій, що специфічні для Parallel EVM, команди зазвичай акцентують увагу на переробці та оптимізації продуктивності читання/запису бази даних стану. Крім того, вони розробляють алгоритми консенсусу, такі як Monad’s MonadDb та MonadBFT.

Виклики

Для паралельного EVM виникають дві потенційні проблеми: захоплення довгострокової інженерної вартості Ethereum та централізація вузлів.

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

Проте ця проблема не становить непереважну перешкоду. З одного боку, у криптовалютних розробників тепер є більший вибір ліцензій з відкритим кодом (таких як ліцензійна модель Uniswap, яка дозволяє розголошення коду, але обмежує відгалуження у комерційні проекти). З іншого боку, позиціонування Monad відрізняється від Ethereum. Навіть якщо Ethereum досягне однослотової остаточності (SSF) у майбутньому, остаточність транзакції залишається принаймні 12 секунд, що недостатньо для високочастотних використань.

Ще одним спільним викликом для високопродуктивних громадських ланцюжків є розгортання додаткових вузлів для задоволення фундаментальних передумов безкомісійності та відсутності довіри користувачів: децентралізація. Можливо, певні метрики, такі як 'TPS, поділене на вимоги апаратного забезпечення вузла', можна кількісно оцінити, щоб забезпечити порівняльний аналіз та визначити, який громадський ланцюжок/клієнт пропонує вищий TPS за певних апаратних передумов. У кінцевому підсумку, менші вимоги до апаратного забезпечення для вузлів сприяють більшому їх розгортанню.

Надалі ми будемо продовжувати моніторити прогрес різних проєктів, пов'язаних з Parallel EVM, і детально розглядати їх технології та відмінності.

Disclaimer：

1. Ця стаття розміщена з [ Дослідження ChainFeeds], Усі авторські права належать оригінальному авторові [ZHIXIONG PAN]. Якщо є зауваження до цього перепублікування, будь ласка, зв'яжіться з Ворота Навчитисякоманда, і вони оперативно з ним впораються.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно думкою автора і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.