Яке значення розпаралелювання EVM? Або це фінал гегемонії EVM?

TL;DR

• Кілька провідних венчурних капіталовкладачів роблять ставку на концепцію Parallel EVM: Paradigm, Jump, Dragonfly тощо.
• Представницький проект - Monad, а також є Sei, MegaETH, Polygon, Neon EVM, BSC та ін. Деякі L1, деякі L2. Повної публічної інформації про конкретні відмінності між командами немає.
• Хоча Parallel EVM буквально означає «розпаралелювання», насправді це спеціальна оптимізація продуктивності кожного компонента EVM, тому його зусилля, ймовірно, представляють межу продуктивності за стандартом EVM.
• Складність: окрім реконструкції всього технологічного стеку, також є можливість заздалегідь передбачити, чи будуть паралельні транзакції конфліктувати, і ефективність повторного виконання після конфліктів.
• Завдання: як створити диференціацію в екосистемі з відкритим кодом і як знайти баланс між децентралізацією та продуктивністю.

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

Спільнота почала звертати увагу на Parallel EVM (розпаралелювання EVM). Воно виникло з того самого ключового слова, яке згадали Георгіос Константопулос (технічний директор Paradigm) і Хасіб Куреші з Dragonfly, коли очікували тенденцій 2024 року в кінці 2023 року. Однак на цю тему небагато деталей, і багато людей вважають, що це не нова концепція. EVM і паралельні обчислення є відносно зрілими концепціями відповідно. Чому це важлива тенденція поєднувати ці два слова? Вовняна тканина?

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

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

Paradigm давно чекає вступу в гру, а Jump робить великі ставки.

За даними Fortune, Paradigm планує очолити останній раунд інвестицій Monad, залучивши 200 мільйонів доларів США при оцінці в 3 мільярди доларів. Незважаючи на те, що це перша командна концепція Parallel EVM, у яку Paradigm планує інвестувати, насправді вони приділяють увагу цій технології протягом багатьох років. Георгіос Константопулос (технічний директор Paradigm) згадав цей термін у 2021 році.

Цікавим є і походження слова монада. У філософській системі філософа Лейбніца монади — це основні елементи, що становлять всесвіт. Вони є неподільними сутностями, на які не впливає фізика. Кожна монада відображає весь всесвіт і колись перекладалася китайською як «монада».

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

Інша цікава річ полягає в тому, що Monad і Nomad є «анаграмами» один одного. Nomad відноситься до кочівника, а digital nomad відноситься до цифрового кочівника/цифрового пастуха.

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

Коли Reth було запущено, члени команди Erigon також звинуватили його в плагіаті відкритого вихідного коду Akula, що також спричинило брак коштів для проекту Akula та припинення розробки. Георгіос відповів, що Reth не є форком будь-якого іншого клієнта, і код не походить від будь-якого іншого клієнта, але він справді створений під впливом і натхненням Гета, Ерігона та Акули. ()

Іншим основним учасником є Jump Trading і Jump Capital. Засновник Monad походить від Jump Trading і має багатий досвід у високочастотній торгівлі; Серед інвесторів Sei є Jump Capital, а Jump був глибоко залучений в екосистему Solana, включаючи інфраструктуру та проекти. .

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

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

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

Але це не так. Якщо ви хочете отримати високопродуктивний публічний ланцюг, потрібно узгодити алгоритм консенсусу та рівень виконання, що також узгоджується з недоліками дерев’яної бочки. Для тих публічних ланцюжків, які базуються на EVM і лише вдосконалюють алгоритм консенсусу, для покращення продуктивності потрібні сильніші вузли. Наприклад, BSC обмежує газ, який може обробити блок, до рівня 2000 TPS, що вимагає конфігурації машини в кілька разів більше інвестицій, ніж повний вузол Ethereum. Полігон теоретично може досягати 1000 TPS, але зазвичай це лише десятки-сотні.

Архівні вузли BSC вимагають щонайменше 16-ядерного ЦП і 128 ГБ пам’яті, а вузли Ethereum вимагають щонайменше 4-ядерного ЦП і 16 ГБ пам’яті.

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

Паралелізм: не лише переходьте від одноядерного до багатоядерного ЦП

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

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

Крім того, Parallel EVM не тільки покращує паралельні можливості, але й оптимізує ефективність однопотокового виконання. Генеральний директор Monad Кеоне Хон сказав: «…справжнім вузьким місцем (EVM) є часте читання та запис статусу під час обробки речей…». Він також сказав, що паралельне виконання є лише частиною дорожньої карти, і більша місія Monad полягає в тому, щоб зосередитися на EVM і зробити його максимально ефективним.

Таким чином, хоча Parallel EVM буквально означає «розпаралелювання», насправді це спеціальна оптимізація продуктивності кожного компонента EVM, тому його зусилля, ймовірно, представляють межу продуктивності за стандартом EVM.

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

Написання смарт-контрактів є важливою навичкою для більшості розробників блокчейнів. Інженери можуть використовувати Solidity або інші мови смарт-контрактів високого рівня, щоб написати відповідні логічні реалізації на основі потреб бізнесу. Однак EVM насправді не може безпосередньо зрозуміти логіку Solidity. Йому потрібно пройти певний «переклад» і перекласти (скомпілювати) його на мову низького рівня, яку може зрозуміти машина (код операції / байт-код байт-код), перш ніж він зможе бути прочитаним віртуальною машиною. Розробникам Solidity не потрібно розуміти цей процес перекладу, оскільки вже існують зрілі інструменти для його реалізації.

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

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

Продуктивність EVM змінюється, і “стандарт” не дорівнює “інженерній практиці”

«Віртуальну машину» також можна назвати «виконавчим рівнем».Це механізм, у якому смарт-контракти остаточно обчислюються та обробляються після їх компіляції в коди операцій. «Байт-код», визначений віртуальною машиною Ethereum (EVM), тепер став галузевим стандартом.Незалежно від того, чи це мережа другого рівня на основі Ethereum чи інших незалежних публічних ланцюжків, вони більше готові бути безпосередньо та повністю сумісними з EVM. Стандарт перед розробкою. Автори можуть написати смарт-контракти один раз і розгорнути їх у кількох мережах, що є надзвичайно рентабельним.

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

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

Оскільки існує реалізація evmone, інші реалізації також можуть бути зроблені. Отже, у цьому прикладі EVM стандарт EVM визначає деякі базові методи роботи «байт-код» (наприклад, підтримку найпростіших арифметичних операцій, таких як додавання, віднімання, множення тощо). Коли кожен байт-код має певний вхід, є визначений вихід . Що стосується відповідності цьому критерію, впровадження (і практики) дуже відрізняються, з великим простором для налаштування та можливостями для інженерної оптимізації.

Подібності та відмінності паралельного EVM

У треку Parallel 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. Хоча існують тонкі відмінності між технологіями (і відкритим кодом), важливішим є те, як створити унікальність екосистеми.

Технічні труднощі Parallel EVM

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

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

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

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

виклик

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

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

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

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

Далі ми продовжимо відстежувати прогрес кожного проекту Parallel EVM і детально обговорюватимемо їхні технології та відмінності.