EVM (Віртуальна машина Ethereum) є ядром Ethereum і відповідає за смартконтракти та обробку транзакцій.
Віртуальна машина зазвичай використовується для віртуалізації реального комп'ютера, як правило, «гіпервізором» (наприклад, VirtualBox) або цілим екземпляром операційної системи (наприклад, KVM для Linux). Вони, відповідно, повинні забезпечувати програмні абстракції фактичного обладнання, системних викликів та інших функцій ядра.
EVM працює в більш обмеженій сфері: це просто обчислювальний движок, тому він надає абстракції для обчислень і зберігання, подібно до специфікації Java Віртуальна машина (JVM). З точки зору високого рівня, JVM призначений для забезпечення середовища виконання, яке не залежить від базової основної операційної системи або апаратного забезпечення, тим самим забезпечуючи сумісність з різними системами. Так само EVM виконує власний набір байт-код інструкцій, які зазвичай компілюються Solidity.
EVM є квазі-повною державною машиною Тюрінга. Він є «квазі», оскільки всі кроки виконання споживають обмежений ресурс Gas, тому будь-яке виконання смарт-контракту буде обмежене обмеженою кількістю кроків обчислення, що дозволить уникнути можливих помилок у процесі виконання. Нескінченний цикл, що змушує всю Ethereum платформу зупинятися.
EVM не має функції планування. Модуль виконання Ethereum видаляє транзакції одну за одною з блоку, а EVM відповідає за їх послідовне виконання. Остання світова держава буде змінена в процесі виконання. Після того, як транзакція буде виконана, стан буде накопичено, щоб досягти останнього стану світу після завершення блоку. Виконання наступного блоку строго залежить від стану світу після виконання попереднього блоку, тому процес лінійного виконання транзакцій Ethereum не може бути добре оптимізований для паралельного виконання.
У цьому сенсі Ethereum протокол передбачає, що угоди виконуються послідовно. У той час як послідовне виконання гарантує, що транзакції та смартконтракти можуть бути виконані в детермінованому ордер, гарантуючи безпеку, це може призвести до перевантаження мережі та затримка при зіткненні з високим навантаженням. Ось чому Ethereum має значні вузькі місця в продуктивності та потребує Layer2 Rollup для розширення потужності.
Більшість високопродуктивних Layer 1 розробляють власні рішення для оптимізації, засновані на нездатності Ethereum обробляти паралельну обробку. Тут ми говоримо лише про оптимізацію виконавчого шару, тобто віртуальних машин і паралельного виконання.
EVM розроблено як 256-бітну віртуальну машину в ордер для полегшення обробки алгоритму хешування Ethereum, і вона явно видаватиме 256-бітний результат. Однак комп'ютер, на якому фактично запущено EVM, повинен зіставити 256-бітні байти з локальною структурою для виконання смарт-контракту, що робить всю систему дуже неефективною та непрактичною. Таким чином, з точки зору вибору віртуальних машин, високопродуктивний рівень 1 використовує віртуальні машини на основі WASM, eBPF байт-код або Move байт-код, а не EVM.
WASM — це компактний, швидко завантажуваний, портативний формат байт-коду, заснований на механізмі безпеки пісочниці. Розробники можуть використовувати кілька мов програмування (C/C++, Rust, Go, AssemblyScript, JavaScript тощо) для написання смартконтракти, а потім компілювати їх у байт-код WASM і виконувати. WASM був прийнятий як стандарт багатьма блокчейн-проектами, включаючи EOS, Dfinity, Polkadot (Gear), Cosmos (CosmWasm), Near тощо. Ethereum також інтегрує WASM у майбутньому, щоб гарантувати, що рівень виконання Ethereum буде більш ефективним, простим і придатним як повністю децентралізована обчислювальна платформа.
eBPF, раніше відомий як BPF (Berkeley Packet Filter), спочатку використовувався для ефективної фільтрації пакетів мережевих даних. Після еволюції він сформував eBPF, надаючи багатший набір інструкцій, що дозволяє динамічно втручатися та модифікувати ядро операційної системи без зміни вихідного коду. Пізніше ця технологія розвинулася з ядра для розробки середовища виконання eBPF у режимі користувача, яке є високопродуктивним, безпечним і портативним. Всі смартконтракти, виконані на Solana, компілюються в SBF (на основі eBPF) байт-код і працюють в його мережі блокчейн.
Move — це нова мова програмування смарт-контрактів, розроблена Diem, зосереджена на гнучкості, безпеці та перевірюваності. Мова Move спрямована на вирішення проблем безпеки в активах і транзакціях, роблячи активи і транзакції строго визначеними і контрольованими. Верифікатор байт-код Move — це інструмент статичного аналізу, який аналізує байт-код Move і визначає, чи відповідає він необхідним правилам безпеки, пам'яті та ресурсів, без реалізації на рівні смарт-контракту та перевірки під час виконання. Aptos успадкував Diem Move, в той час як Sui пише свій смартконтракти через власну кастомізовану версію Sui Move.
Паралельне виконання в блокчейні означає одночасну обробку непов'язаних транзакцій. Розглядайте непов'язані транзакції як події, які не впливають одна на одну. Наприклад, якщо двоє людей торгують токенами на різних біржах, їхні транзакції можуть оброблятися одночасно. Однак, якщо вони торгуються на одній платформі, транзакції можуть бути виконані в певному ордер.
Основною проблемою в досягненні паралельного виконання є визначення того, які транзакції не пов'язані між собою, а які є незалежними. Більшість високопродуктивних рівнів 1 спирається на два підходи: методи доступу до станів і оптимістичні паралельні моделі.
Методи державного доступу повинні заздалегідь знати, до якої частини стану блокчейну може отримати доступ кожна транзакція, щоб проаналізувати, які транзакції є незалежними. Представницькими рішеннями є Solana і Sui.
У Solana програми (смартконтракти) не мають стану, оскільки вони не можуть отримати доступ (прочитати або записати) будь-який постійний стан протягом усього процесу транзакції. Щоб отримати доступ до стану або підтримувати його, програмам потрібно використовувати облікові записи. Кожна транзакція в Solana повинна вказувати, до яких облікових записів буде здійснюватися доступ під час виконання транзакції, щоб середовище виконання обробки транзакцій могло планувати транзакції, що не перетинаються, для паралельного виконання, забезпечуючи при цьому узгодженість даних.
У Sui Move кожен смарт-контракт є модулем, що складається з визначень функцій і структур. Екземпляри структур створюються у функціях і можуть бути передані іншим модулям за допомогою викликів функцій. Збережені екземпляри структур під час виконання виступають як об'єкти. Sui має три різні типи об'єктів: об'єкти-власники, спільні об'єкти та незмінні об'єкти. Стратегія розпаралелювання Sui схожа на стратегію Solana, оскільки транзакції також повинні вказувати, якими об'єктами оперувати.
Оптимістична паралельна модель працює в припущенні, що всі транзакції є незалежними, ретроспективно перевіряючи це припущення і вносячи корективи, коли це необхідно. Представницьким рішенням є Aptos.
Aptos використовує метод Блок-STM (Блок Software Transactional Memory) для застосування оптимістичного паралельного виконання. У Блок-STM транзакції спочатку встановлюються в певному ордер всередині блоку, а потім розподіляються між різними потоками обробки для одночасного виконання. Обробляючи ці транзакції, система відстежує ділянки пам'яті, змінені кожною транзакцією. Після кожного раунду обробки система перевіряє всі результати транзакцій. Якщо він виявляє, що транзакція торкнулася ділянки пам'яті, зміненої попередньою транзакцією, він стирає її результат і запускає її знову. Цей процес триває до тих пір, поки не буде оброблена кожна транзакція в блоці.
Паралельний EVM вперше був згаданий у 2021 році, тоді він стосувався EVM, який підтримує обробку кількох транзакцій одночасно, спрямований на підвищення продуктивності та ефективності існуючої EVM. Серед репрезентативних рішень – паралельний EVM Polygon на основі Блок-STM та паралельний EVM, розроблений спільно BSC та NodeReal.
Однак наприкінці 2023 року Георгіос Константопулос, CTO Paradigm, і Хасіб Куреші з Dragonfly, випадково згадали паралельні EVM, розглядаючи тенденції на 2024 рік, запаливши хвилю EVM сумісних Layer1, які прийняли технологію паралельного виконання, включаючи Monand і Sei V2.
В даний час Neon, EVM сумісне рішення на Solana, Layer2 Rollup Eclipse Ethereum's SVM (Solana Віртуальна машина), Layer2 Rollup Lumio Ethereum's Move Віртуальна машина і модульний виконавчий рівень Layer1 Fuel позначені паралельними EVM, що робить його досить заплутаним.
Я думаю, що є лише наступні три категорії, які можна обґрунтовано визначити як паралельні EVM:
Зайве говорити, що BSC і Polygon є найбільш популярними EVM-сумісними рівнями 1. Ось короткий вступ до Monand, Sei V2, Artela та Solana Neon.
Monad — це високопродуктивний EVM-сумісний рівень 1, що використовує механізм PoS, призначений для значного підвищення масштабованості та швидкості транзакцій за рахунок паралельного виконання. Monad Labs була заснована Кеоне Хоном, колишнім керівником відділу досліджень у Jump Trading. Монади дозволяють виконувати транзакції паралельно всередині блоку для підвищення ефективності. Він використовує оптимістичну модель паралелізму і починає виконувати нову транзакцію до завершення виконання попереднього кроку. Щоб впоратися з неправильними результатами, Monad відстежує введення/виведення та повторно виконує непослідовні транзакції. Статичні аналізатори коду можуть передбачати залежності, уникати неефективного паралелізму та повертатися до простого режиму під час невизначеності. Таке паралельне виконання збільшує пропускну здатність, одночасно зменшуючи ймовірність збою транзакції.
Sei – це Layer1, розроблений на основі Cosmos SDK, публічного ланцюга, спеціально розробленого для DeFi. Члени команди Sei мають як технічну, так і традиційну фінансову освіту, працюючи в таких компаніях, як Robinhood, Databricks, Airbnb і Goldman Sachs. Sei V2 – це серйозне оновлення мережі Sei, яке має на меті стати першим повністю паралельним EVM. Як і Monand, Sei V2 використовуватиме оптимістичне розпаралелювання. Це дозволяє блокчейну виконувати транзакції одночасно, не визначаючи розробниками жодних залежностей. Коли виникають конфлікти, блокчейн відстежує частини сховища кожної транзакції, до яких торкаються, і повторно запускає ці транзакції в ордер. Цей процес продовжується рекурсивно, доки не будуть вирішені всі невирішені конфлікти.
Artela — це масштабована блокчейн-мережа, яка дозволяє розробникам створювати багатофункціональні децентралізовані програми (dApps) з основними членами AntChain. Artela EVM++ являє собою високу масштабованість + високопродуктивний паралельний EVM. Вона буде реалізована в два етапи, перший з яких буде присвячений паралельному виконанню. Заснований на паралельному виконанні, за допомогою пружних обчислень, він забезпечує масштабованість обчислювальної потужності вузла мережі, в кінцевому підсумку досягаючи еластичного блокового простору. Його паралельне виконання згрупує транзакції відповідно до аналізу конфлікту залежності транзакцій для підтримка паралельного виконання.
Solana Neon – це рішення, розроблене компанією Neon Labs для виконання EVM транзакцій на Solana. Neon EVM фактично є смарт-контрактом на Solana, який реалізує інтерпретатор EVM в рамках контракту, скомпільованого в SBF байт-код. Neon EVM внутрішньо реалізує набір моделей транзакцій Ethereum і рахунок, і користувачам потрібно лише сплатити EVM комісію GAS, щоб надсилати транзакції. Комісію мережі Solana оплачує проксі-сервер Neon. Solana вимагає, щоб транзакції обов'язково надавали рахунок список, включаючи обгорнуті транзакції, тому в обов'язки Neon Proxy входить генерація цього рахунок список, а також він отримує можливість паралельного виконання транзакцій Solana
.Крім того, подібно до Solana Neon, інші рішення, які працюють EVM як смарт-контракт для досягнення EVM сумісності, включають Near Aurora та EOS EVM+. Теоретично Aptos і Sui також могли б використовувати це рішення для досягнення ненав'язливої EVM сумісності, але я не знайшов відповідної інформації (можливо, Pontem це робить?). Якщо є поточні проекти, будь ласка, зв'яжіться зі мною для отримання доповнення. EVM сумісність дозволяє розробникам легко мігрувати свої Ethereum додатки в ланцюжок, не вносячи істотних змін, що є відмінним напрямком для побудови екосистеми Aptos і Sui.
Тема паралельних технологій у блокчейні вже є банальною темою, і час від часу наративи спливають на поверхню. Однак в даний час основна увага приділяється модифікаціям і імітаціям оптимістичної моделі виконання, представленої механізмом Aptos Блок-STM. Однак без істотних проривів спеку важко витримати.
Забігаючи наперед, ми можемо очікувати, що більше нових проєктів Layer1 приєднаються до гонки за паралельні EVM. Крім того, деякі існуючі проєкти рівня 1 можуть впроваджувати EVM паралельні оновлення або EVM-сумісні рішення. Ці два шляхи призводять до схожого результату, потенційно породжуючи більше наративів, пов'язаних із продуктивністю.
Однак, порівняно з наративом про високопродуктивні EVM, я більше сподіваюся на різноманітний блокчейн-ландшафт, де з'являються наративи, схожі на WASM, SVM і Move VM.
Ця стаття відтворена з [小猪Web3], авторські права належать оригінальному автору [ web3朱大胆], якщо у вас є заперечення проти передруку, будь ласка, зв'яжіться з Gate Learn команда, і команда впорається з цим якомога швидше згідно з відповідними процедурами.
Відмова від відповідальності: Погляди та думки, висловлені в цій статті, відображають лише особисті погляди автора та не є будь-якою інвестиційною порадою.
Інші мовні версії статті перекладені командою Gate Learn і не згадуються в Gate.io, перекладена стаття не може бути відтворена, поширена або плагіатна.
EVM (Віртуальна машина Ethereum) є ядром Ethereum і відповідає за смартконтракти та обробку транзакцій.
Віртуальна машина зазвичай використовується для віртуалізації реального комп'ютера, як правило, «гіпервізором» (наприклад, VirtualBox) або цілим екземпляром операційної системи (наприклад, KVM для Linux). Вони, відповідно, повинні забезпечувати програмні абстракції фактичного обладнання, системних викликів та інших функцій ядра.
EVM працює в більш обмеженій сфері: це просто обчислювальний движок, тому він надає абстракції для обчислень і зберігання, подібно до специфікації Java Віртуальна машина (JVM). З точки зору високого рівня, JVM призначений для забезпечення середовища виконання, яке не залежить від базової основної операційної системи або апаратного забезпечення, тим самим забезпечуючи сумісність з різними системами. Так само EVM виконує власний набір байт-код інструкцій, які зазвичай компілюються Solidity.
EVM є квазі-повною державною машиною Тюрінга. Він є «квазі», оскільки всі кроки виконання споживають обмежений ресурс Gas, тому будь-яке виконання смарт-контракту буде обмежене обмеженою кількістю кроків обчислення, що дозволить уникнути можливих помилок у процесі виконання. Нескінченний цикл, що змушує всю Ethereum платформу зупинятися.
EVM не має функції планування. Модуль виконання Ethereum видаляє транзакції одну за одною з блоку, а EVM відповідає за їх послідовне виконання. Остання світова держава буде змінена в процесі виконання. Після того, як транзакція буде виконана, стан буде накопичено, щоб досягти останнього стану світу після завершення блоку. Виконання наступного блоку строго залежить від стану світу після виконання попереднього блоку, тому процес лінійного виконання транзакцій Ethereum не може бути добре оптимізований для паралельного виконання.
У цьому сенсі Ethereum протокол передбачає, що угоди виконуються послідовно. У той час як послідовне виконання гарантує, що транзакції та смартконтракти можуть бути виконані в детермінованому ордер, гарантуючи безпеку, це може призвести до перевантаження мережі та затримка при зіткненні з високим навантаженням. Ось чому Ethereum має значні вузькі місця в продуктивності та потребує Layer2 Rollup для розширення потужності.
Більшість високопродуктивних Layer 1 розробляють власні рішення для оптимізації, засновані на нездатності Ethereum обробляти паралельну обробку. Тут ми говоримо лише про оптимізацію виконавчого шару, тобто віртуальних машин і паралельного виконання.
EVM розроблено як 256-бітну віртуальну машину в ордер для полегшення обробки алгоритму хешування Ethereum, і вона явно видаватиме 256-бітний результат. Однак комп'ютер, на якому фактично запущено EVM, повинен зіставити 256-бітні байти з локальною структурою для виконання смарт-контракту, що робить всю систему дуже неефективною та непрактичною. Таким чином, з точки зору вибору віртуальних машин, високопродуктивний рівень 1 використовує віртуальні машини на основі WASM, eBPF байт-код або Move байт-код, а не EVM.
WASM — це компактний, швидко завантажуваний, портативний формат байт-коду, заснований на механізмі безпеки пісочниці. Розробники можуть використовувати кілька мов програмування (C/C++, Rust, Go, AssemblyScript, JavaScript тощо) для написання смартконтракти, а потім компілювати їх у байт-код WASM і виконувати. WASM був прийнятий як стандарт багатьма блокчейн-проектами, включаючи EOS, Dfinity, Polkadot (Gear), Cosmos (CosmWasm), Near тощо. Ethereum також інтегрує WASM у майбутньому, щоб гарантувати, що рівень виконання Ethereum буде більш ефективним, простим і придатним як повністю децентралізована обчислювальна платформа.
eBPF, раніше відомий як BPF (Berkeley Packet Filter), спочатку використовувався для ефективної фільтрації пакетів мережевих даних. Після еволюції він сформував eBPF, надаючи багатший набір інструкцій, що дозволяє динамічно втручатися та модифікувати ядро операційної системи без зміни вихідного коду. Пізніше ця технологія розвинулася з ядра для розробки середовища виконання eBPF у режимі користувача, яке є високопродуктивним, безпечним і портативним. Всі смартконтракти, виконані на Solana, компілюються в SBF (на основі eBPF) байт-код і працюють в його мережі блокчейн.
Move — це нова мова програмування смарт-контрактів, розроблена Diem, зосереджена на гнучкості, безпеці та перевірюваності. Мова Move спрямована на вирішення проблем безпеки в активах і транзакціях, роблячи активи і транзакції строго визначеними і контрольованими. Верифікатор байт-код Move — це інструмент статичного аналізу, який аналізує байт-код Move і визначає, чи відповідає він необхідним правилам безпеки, пам'яті та ресурсів, без реалізації на рівні смарт-контракту та перевірки під час виконання. Aptos успадкував Diem Move, в той час як Sui пише свій смартконтракти через власну кастомізовану версію Sui Move.
Паралельне виконання в блокчейні означає одночасну обробку непов'язаних транзакцій. Розглядайте непов'язані транзакції як події, які не впливають одна на одну. Наприклад, якщо двоє людей торгують токенами на різних біржах, їхні транзакції можуть оброблятися одночасно. Однак, якщо вони торгуються на одній платформі, транзакції можуть бути виконані в певному ордер.
Основною проблемою в досягненні паралельного виконання є визначення того, які транзакції не пов'язані між собою, а які є незалежними. Більшість високопродуктивних рівнів 1 спирається на два підходи: методи доступу до станів і оптимістичні паралельні моделі.
Методи державного доступу повинні заздалегідь знати, до якої частини стану блокчейну може отримати доступ кожна транзакція, щоб проаналізувати, які транзакції є незалежними. Представницькими рішеннями є Solana і Sui.
У Solana програми (смартконтракти) не мають стану, оскільки вони не можуть отримати доступ (прочитати або записати) будь-який постійний стан протягом усього процесу транзакції. Щоб отримати доступ до стану або підтримувати його, програмам потрібно використовувати облікові записи. Кожна транзакція в Solana повинна вказувати, до яких облікових записів буде здійснюватися доступ під час виконання транзакції, щоб середовище виконання обробки транзакцій могло планувати транзакції, що не перетинаються, для паралельного виконання, забезпечуючи при цьому узгодженість даних.
У Sui Move кожен смарт-контракт є модулем, що складається з визначень функцій і структур. Екземпляри структур створюються у функціях і можуть бути передані іншим модулям за допомогою викликів функцій. Збережені екземпляри структур під час виконання виступають як об'єкти. Sui має три різні типи об'єктів: об'єкти-власники, спільні об'єкти та незмінні об'єкти. Стратегія розпаралелювання Sui схожа на стратегію Solana, оскільки транзакції також повинні вказувати, якими об'єктами оперувати.
Оптимістична паралельна модель працює в припущенні, що всі транзакції є незалежними, ретроспективно перевіряючи це припущення і вносячи корективи, коли це необхідно. Представницьким рішенням є Aptos.
Aptos використовує метод Блок-STM (Блок Software Transactional Memory) для застосування оптимістичного паралельного виконання. У Блок-STM транзакції спочатку встановлюються в певному ордер всередині блоку, а потім розподіляються між різними потоками обробки для одночасного виконання. Обробляючи ці транзакції, система відстежує ділянки пам'яті, змінені кожною транзакцією. Після кожного раунду обробки система перевіряє всі результати транзакцій. Якщо він виявляє, що транзакція торкнулася ділянки пам'яті, зміненої попередньою транзакцією, він стирає її результат і запускає її знову. Цей процес триває до тих пір, поки не буде оброблена кожна транзакція в блоці.
Паралельний EVM вперше був згаданий у 2021 році, тоді він стосувався EVM, який підтримує обробку кількох транзакцій одночасно, спрямований на підвищення продуктивності та ефективності існуючої EVM. Серед репрезентативних рішень – паралельний EVM Polygon на основі Блок-STM та паралельний EVM, розроблений спільно BSC та NodeReal.
Однак наприкінці 2023 року Георгіос Константопулос, CTO Paradigm, і Хасіб Куреші з Dragonfly, випадково згадали паралельні EVM, розглядаючи тенденції на 2024 рік, запаливши хвилю EVM сумісних Layer1, які прийняли технологію паралельного виконання, включаючи Monand і Sei V2.
В даний час Neon, EVM сумісне рішення на Solana, Layer2 Rollup Eclipse Ethereum's SVM (Solana Віртуальна машина), Layer2 Rollup Lumio Ethereum's Move Віртуальна машина і модульний виконавчий рівень Layer1 Fuel позначені паралельними EVM, що робить його досить заплутаним.
Я думаю, що є лише наступні три категорії, які можна обґрунтовано визначити як паралельні EVM:
Зайве говорити, що BSC і Polygon є найбільш популярними EVM-сумісними рівнями 1. Ось короткий вступ до Monand, Sei V2, Artela та Solana Neon.
Monad — це високопродуктивний EVM-сумісний рівень 1, що використовує механізм PoS, призначений для значного підвищення масштабованості та швидкості транзакцій за рахунок паралельного виконання. Monad Labs була заснована Кеоне Хоном, колишнім керівником відділу досліджень у Jump Trading. Монади дозволяють виконувати транзакції паралельно всередині блоку для підвищення ефективності. Він використовує оптимістичну модель паралелізму і починає виконувати нову транзакцію до завершення виконання попереднього кроку. Щоб впоратися з неправильними результатами, Monad відстежує введення/виведення та повторно виконує непослідовні транзакції. Статичні аналізатори коду можуть передбачати залежності, уникати неефективного паралелізму та повертатися до простого режиму під час невизначеності. Таке паралельне виконання збільшує пропускну здатність, одночасно зменшуючи ймовірність збою транзакції.
Sei – це Layer1, розроблений на основі Cosmos SDK, публічного ланцюга, спеціально розробленого для DeFi. Члени команди Sei мають як технічну, так і традиційну фінансову освіту, працюючи в таких компаніях, як Robinhood, Databricks, Airbnb і Goldman Sachs. Sei V2 – це серйозне оновлення мережі Sei, яке має на меті стати першим повністю паралельним EVM. Як і Monand, Sei V2 використовуватиме оптимістичне розпаралелювання. Це дозволяє блокчейну виконувати транзакції одночасно, не визначаючи розробниками жодних залежностей. Коли виникають конфлікти, блокчейн відстежує частини сховища кожної транзакції, до яких торкаються, і повторно запускає ці транзакції в ордер. Цей процес продовжується рекурсивно, доки не будуть вирішені всі невирішені конфлікти.
Artela — це масштабована блокчейн-мережа, яка дозволяє розробникам створювати багатофункціональні децентралізовані програми (dApps) з основними членами AntChain. Artela EVM++ являє собою високу масштабованість + високопродуктивний паралельний EVM. Вона буде реалізована в два етапи, перший з яких буде присвячений паралельному виконанню. Заснований на паралельному виконанні, за допомогою пружних обчислень, він забезпечує масштабованість обчислювальної потужності вузла мережі, в кінцевому підсумку досягаючи еластичного блокового простору. Його паралельне виконання згрупує транзакції відповідно до аналізу конфлікту залежності транзакцій для підтримка паралельного виконання.
Solana Neon – це рішення, розроблене компанією Neon Labs для виконання EVM транзакцій на Solana. Neon EVM фактично є смарт-контрактом на Solana, який реалізує інтерпретатор EVM в рамках контракту, скомпільованого в SBF байт-код. Neon EVM внутрішньо реалізує набір моделей транзакцій Ethereum і рахунок, і користувачам потрібно лише сплатити EVM комісію GAS, щоб надсилати транзакції. Комісію мережі Solana оплачує проксі-сервер Neon. Solana вимагає, щоб транзакції обов'язково надавали рахунок список, включаючи обгорнуті транзакції, тому в обов'язки Neon Proxy входить генерація цього рахунок список, а також він отримує можливість паралельного виконання транзакцій Solana
.Крім того, подібно до Solana Neon, інші рішення, які працюють EVM як смарт-контракт для досягнення EVM сумісності, включають Near Aurora та EOS EVM+. Теоретично Aptos і Sui також могли б використовувати це рішення для досягнення ненав'язливої EVM сумісності, але я не знайшов відповідної інформації (можливо, Pontem це робить?). Якщо є поточні проекти, будь ласка, зв'яжіться зі мною для отримання доповнення. EVM сумісність дозволяє розробникам легко мігрувати свої Ethereum додатки в ланцюжок, не вносячи істотних змін, що є відмінним напрямком для побудови екосистеми Aptos і Sui.
Тема паралельних технологій у блокчейні вже є банальною темою, і час від часу наративи спливають на поверхню. Однак в даний час основна увага приділяється модифікаціям і імітаціям оптимістичної моделі виконання, представленої механізмом Aptos Блок-STM. Однак без істотних проривів спеку важко витримати.
Забігаючи наперед, ми можемо очікувати, що більше нових проєктів Layer1 приєднаються до гонки за паралельні EVM. Крім того, деякі існуючі проєкти рівня 1 можуть впроваджувати EVM паралельні оновлення або EVM-сумісні рішення. Ці два шляхи призводять до схожого результату, потенційно породжуючи більше наративів, пов'язаних із продуктивністю.
Однак, порівняно з наративом про високопродуктивні EVM, я більше сподіваюся на різноманітний блокчейн-ландшафт, де з'являються наративи, схожі на WASM, SVM і Move VM.
Ця стаття відтворена з [小猪Web3], авторські права належать оригінальному автору [ web3朱大胆], якщо у вас є заперечення проти передруку, будь ласка, зв'яжіться з Gate Learn команда, і команда впорається з цим якомога швидше згідно з відповідними процедурами.
Відмова від відповідальності: Погляди та думки, висловлені в цій статті, відображають лише особисті погляди автора та не є будь-якою інвестиційною порадою.
Інші мовні версії статті перекладені командою Gate Learn і не згадуються в Gate.io, перекладена стаття не може бути відтворена, поширена або плагіатна.