Переслати оригінальний заголовок: Технічний аналіз Артела: Чому “Паралельна EVM” пов'язана з боротьбою за виживання екосистеми Ethereum EVM?

Останнє лідерське інвестування Paradigm у розмірі вражаючих $225 мільйонів у раунд фінансування Monad вразило ринок, спровокувавши хвилю зацікавленості в “паралельному EVM”. Але що саме вирішує “паралельний EVM”? Які є проблеми та ключові виклики у розробці паралельного EVM? Я вважаю, що “паралельний EVM” представляє останню надію EVM-ланцюга на протистояння високопродуктивним ланцюгам рівня 1, битва, яка визначить виживання екосистеми Ethereum EVM. Чому? Давайте заглибимося у моє розуміння:

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

Навпаки, високопродуктивні ланцюги рівня 1, такі як Solana, Sui та Aptos, мають вроджені переваги паралельної обробки. На цьому тлі ланцюги на основі EVM повинні вирішити вроджену відсутність паралельних можливостей для успішної конкуренції з цими високопродуктивними ланцюгами рівня 1. Давайте дослідимо різні підходи до впровадження паралельного EVM, використовуючи приклад мережі Artela, яка є зіркою у просторі паралельного EVM:

1) Представлені такими ланцюгами, як Monad, Artela та SEI, ці ланцюги значно покращують TPS, забезпечуючи можливості паралельних транзакцій у середовищі квазі-EVM. Ці незалежні паралельні ланцюги рівня 1 EVM мають унікальні механізми консенсусу та технічні характеристики, але вони все ще підтримують мету сумісності та розширення в екосистемі EVM. По суті, вони реконструюють ланцюжки EVM, «змінюючи свій родовід», щоб краще обслуговувати екосистему EVM.

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

3) Представлені ланцюгами, такими як Polygon та BSC, ці ланцюги досягли певної ступені паралельної обробки EVM. Однак їх оптимізація обмежена шаром алгоритму, без глибшого вивчення шарів згоди та зберігання. В результаті їх паралельні можливості більше схожі на конкретну функцію, аніж на комплексне рішення для викликів паралелізації EVM.

4) Наприклад, ланцюжки, такі як Aptos, Sui та Fuel, не є строго ланцюжками EVM. Замість цього вони використовують свої вбудовані високопродуктивні можливості виконання та застосовують проміжний шар або техніки розбору коду для досягнення сумісності з середовищем EVM. Це очевидно в випадку Starknet, рішення другого рівня Ethereum. Сумісність Starknet з EVM потребує спеціального провідника через його мову Cario та функції абстракції облікового запису. Ця проблема сумісності є поширеною проблемою для ланцюжків, які не є EVM, і намагаються побудувати місто з ланцюжками EVM.

Чотири вищезгадані підходи кожен має свій власний акцент. Наприклад, Layer 2 з паралельними можливостями акцентується на гнучкості модульних комбінацій ланцюгів “виконавчого шару”, тоді як EVM-сумісні ланцюги підкреслюють індивідуалізовані особливості конкретних функцій. Що стосується інших не-EVM ланцюгів з функціями сумісності EVM, вони спрямовані більше на використання ліквідності Ethereum. Справжня мета полягає в повній консолідації екосистеми EVM, залишаючи лише один посиленний EVM шар 1 для підвищення паралельних можливостей.

Так які ключові фактори зміцнення паралельного шару 1 громадського ланцюжка EVM? Як ми можемо реконструювати ланцюжок EVM, продовжуючи обслуговування екосистеми EVM? Є дві ключові точки:

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

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

Щодо конкретного проекту паралельного ланцюга EVM рівня 1 самого себе, які технологічні інновації та оптимізації фреймворку потрібні для досягнення "паралельного EVM"?

Для того щоб повністю досягти можливостей координації та оптимізації ресурсів «паралельного EVM» від архітектури нижнього рівня, Artela вводить Еластичне Обчислення та Еластичний Блочний Простір. Як їх розуміти? Еластичне обчислення дозволяє мережі динамічно розподіляти та налаштовувати обчислювальні ресурси згідно з попитом та навантаженням, тоді як еластичний блочний простір динамічно налаштовує розмір блоку на основі кількості транзакцій та обсягу даних у мережі. Увесь принцип еластичного дизайну працює аналогічно ескалаторам у торгових центрах, які автоматично відчувають пішохідний потік, що має сенс.

Як вже зазначалося раніше, продуктивність читання диска стану I/O є критичною для паралельного EVM. Сумісні з EVM ланцюги, такі як Polygon та BSC, досягають покращень ефективності в 2-4 рази завдяки алгоритмічному паралелізму, але це лише оптимізація на рівні алгоритму. Шар консенсусу та шар сховища не пройшли глибокої оптимізації. Яким би було справжня глибока оптимізація?

У відповідь на це, Artela використовує рішення технології баз даних, що поліпшують як читання, так і запис стану. Для запису станів воно використовує технологію Write-Ahead Logging (WAL), яка записує зміни перед їх записом на диск. Ця асинхронна операція уникне безпосереднього запису на диск при зміні стану, зменшуючи операції введення/виведення даних на диск. Що стосується читання стану, воно суттєво використовує асинхронні операції за допомогою стратегій попереднього завантаження для покращення ефективності читання. Прогнозуючи, які стани будуть потрібні на основі історії виконання контрактів і завантажуючи їх у пам'ять, воно підвищує ефективність запитів введення/виведення даних на диск.

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

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

Це все.

Для всіх не складно бачити, що концепція "Parallel EVM" суттєво оптимізує процес виконання статусу транзакції.@monad_xyzстверджує, що може досягти 10 000 транзакцій в секунду, а її технічне ядро нічим більше, як досягнення паралельної обробки великомасштабних транзакцій через спеціалізовані бази даних, дружелюбність до розробників, відкладену виконавчу згоду та технологію суперскалярного конвеєра тощо. Це не дуже відрізняється від еластичного обчислення та асинхронних операцій введення/виведення Artela.

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

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

заява:

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

2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, представляють лише особисті погляди автора і не становлять жодної інвестиційної поради.

3. Інші мовні версії статті перекладені командою Gate Learn і не згадуються в Gate.io, перекладений матеріал не може бути відтворений, поширений або узятий з іншого джерела.