У кінці не переглядати; Занадто довгий, не читав

1. Паралельні EVM представляють нову наратив, що виникає, коли обсяги транзакцій на ланцюжку досягають певного рівня. Вони в основному поділяються на монолітні блокчейни та модулярні блокчейни, при цьому монолітні розділяються на L1 та L2. Паралельні L1 публічні ланцюжки поділяються на два табори: EVM та не-EVM. Наразі наратив про паралельні EVM знаходиться на ранній стадії розвитку.
2. Технічний шлях реалізації паралельних EVM включає віртуальні машини та механізми паралельного виконання. У контексті блокчейнів віртуальна машина - це процесорна віртуальна машина, яка віртуалізує розподілену станову машину для виконання контрактів.
3. Паралельне виконання означає використання багатоядерних процесорів для виконання кількох транзакцій одночасно настільки, наскільки це можливо, забезпечуючи при цьому, що кінцевий стан відповідає тому, що можна досягти через послідовне виконання.
4. Механізми паралельного виконання поділяються на три категорії: передача повідомлень, спільна пам'ять та строгі списки доступу до стану. Спільна пам'ять поділяється на модель блокування пам'яті та оптимістичну паралелізацію. Незалежно від механізму, кожен збільшує технічну складність.
5. Повість про паралельні EVM має не лише вроджені фактори зростання промисловості, але й вимагає від практиків уваги до можливих проблем з безпекою.
6. Кожен паралельний проект EVM надає свій унікальний підхід до паралельного виконання, показуючи як технічні спільності, так і відмінні інновації.

1.Огляд галузі

1.1 Історична еволюція

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

Перші мережі блокчейн першого покоління, що представлені Bitcoin, відкрили новий спосіб децентралізованих електронних валютних транзакцій з технологією розподіленого реєстру, революціонізуючи нову еру. Друге покоління, в якості прикладу Ethereum, повністю використовувало уяву для пропозиції децентралізованих додатків (dApps) через підхід розподіленої машини стану.

З того часу мережі блокчейн розпочали власний стрімкий розвиток протягом понад десяти років, від інфраструктури Web3 до різних напрямків, таких як DeFi, NFT, соціальні мережі та GameFi, що породило численні інновації в технологіях та бізнес-моделях. Процвітаючій галузі постійно потрібно привертати нових користувачів для участі в екосистемі децентралізованих додатків, що в свою чергу висуває вищі вимоги до продуктового досвіду.

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

Ці рішення можна загалом класифікувати на два типи: рішення для масштабування on-chain, такі як шардінг та направлені ациклічні графи (DAGs), та рішення для масштабування off-chain, такі як Plasma, Lightning Networks, sidechains та Rollups. Однак вони все ще далекі від того, щоб встигати за швидким зростанням транзакцій on-chain.

Особливо після Літа DeFi 2020 року та вибухового зростання вписів у біткойн-екосистему наприкінці 2023 року, галузі терміново потрібні нові рішення для покращення продуктивності, щоб задовольнити вимоги щодо "високої продуктивності та низьких комісій". Паралельні блокчейни народилися на тлі цих подій.

1.2 Розмір ринку

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

Конкуренти Ethereum, такі як Solana, Aptos та Sui, всі мають вбудовані можливості паралельної обробки та розвинені екосистеми. Їхні ринкові капіталізації токенів досягли $45 мільярдів, $3,3 мільярдів і $1,9 мільярдів, утворивши паралельний некемпінг EVM. У відповідь на ці виклики екосистема Ethereum також не залишається осторонь, різні проекти виступають на передовій, щоб посилити EVM, тим самим створюючи паралельний некемпінг EVM.

Sei, у своєму пропозиції на оновлення версії 2, відкрито заявив, що стане «першим паралельним блокчейн EVM», з поточною ринковою капіталізацією у $2,1 мільярда та потенціалом для ще більшого зростання. Новий паралельний блокчейн EVM Monad, наразі найгарячіший у маркетинговому паломництві, дуже цінується інвесторами та має значний потенціал. Тим часом, L1 блокчейн Canto, з ринковою капіталізацією $170 мільйонів та власною безкоштовною громадською інфраструктурою, також оголосив про свою пропозицію на оновлення паралельного EVM.

Крім того, кілька проектів ранньої стадії L2 покращують крос-екосистемний рівень продуктивності, інтегруючи можливості кількох ланцюгів L1. Окрім Neon, який досяг ринкової вартості в обігу $69 мільйонів, іншим проектам все ще не вистачає відповідних даних. Очікується, що в майбутньому до бойовику паралельного блокчейну приєднаються ще більше проектів L1 та L2.

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

На даний момент загальна ринкова капіталізація для Шару 1 та Шару 2 становить $752.123 мільярда, при цьому паралельні блокчейни мають ринкову капіталізацію у розмірі $52.539 мільярда, що становить близько 7%. У цьому контексті проекти, пов'язані з паралельною EVM-історією, мають ринкову капіталізацію у розмірі $2.339 мільярда, що становить всього лише 4% від ринкової капіталізації паралельних блокчейнів.

1.3 Карта галузі

Галузь загалом розділяє блокчейн-мережі на чотиришарову структуру:

Шар 0 (Мережа): Це підлоговий рівень блокчейн мережі, який обробляє основні протоколи мережевого зв'язку.

Рівень 1 (Інфраструктура): Цей рівень ґрунтується на різних механізмах консенсусу для підтвердження транзакцій у децентралізованій мережі.

Рівень 2 (розширення): Залежить від Рівня 1, це включає різноманітні протоколи другого рівня, спрямовані на вирішення обмежень Рівня 1, особливо щодо масштабованості.

Шар 3 (Додаток): Залежить від Шару 2 або Шару 1, цей шар використовується для побудови різноманітних децентралізованих додатків (dApps).

Проекти паралельної EVM (Ethereum Virtual Machine) розповіді в основному поділяються на монолітні блокчейни та модулярні блокчейни, причому монолітні блокчейни поділяються на L1 та L2. Загалом за кількістю проектів та розвитком кількох основних напрямів можна побачити, що у публічних екосистемах паралельної EVM L1 все ще є значний потенціал для зростання порівняно з екосистемою Ethereum.

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

L1 представляє нові громадські ланцюги з вбудованими можливостями паралельного виконання і служить як високопродуктивна інфраструктура. У цій фракції проекти, такі як Sei v2, Monad та Canto, незалежно розробили паралельні EVM, які сумісні з екосистемою Ethereum та забезпечують високу пропускну здатність транзакцій.

L2, інтегруючи можливості інших ланцюгів L1, пропонує розширені можливості для міжекосистемної співпраці і є важливим прикладом технології rollup. У цьому фракції Neon діє як емулятор EVM в мережі Solana, тоді як Eclipse виконує транзакції в Solana, але розраховується в EVM. Lumio схожий на Eclipse, за винятком того, що рівень виконання було переключено на Aptos.

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

Fuel спрямований на виконання транзакцій, віддаючи зовнішні компоненти одному або кільком незалежним шарів блокчейну, що дозволяє більш гнучкі комбінації: він може функціонувати як Шар 2, Шар 1, або навіть як побічний ланцюжок або канал стану. Наразі в екосистемі Fuel існують 17 проєктів, що в основному фокусуються на DeFi, NFT та інфраструктурі.

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

2. Технічні шляхи впровадження

Для досягнення децентралізованого виконання транзакцій, мережі блокчейн повинні виконувати чотири відповідальності:

• Виконання: Виконання та перевірка транзакцій.
• Доступність даних: Розподіл нових блоків всім вузлам в мережі блокчейн.
• Механізм консенсусу: Перевірка блоків та досягнення консенсусу.
• Врегулювання: Вирішення та реєстрація кінцевого стану операцій.

Паралельний EVM в основному спрямований на оптимізацію продуктивності рівня виконання. Це поділено на рішення рівня 1 (L1) та рішення рівня 2 (L2). Рішення рівня 1 вводять механізм паралельного виконання транзакцій, що дозволяє виконувати транзакції паралельно в межах віртуальної машини настільки, наскільки це можливо. Рішення рівня 2 фундаментально використовують вже паралелізовану віртуальну машину рівня 1 для досягнення певного рівня "виконання поза ланцюжком + розрахунок на ланцюжку".

Отже, щоб зрозуміти технічні принципи паралельного EVM, необхідно розібрати це: спочатку зрозуміти, що таке віртуальна машина (VM), а потім зрозуміти, що передбачає паралельне виконання.

2.1 Віртуальна машина

У галузі комп'ютерних наук термін "віртуальна машина" відноситься до віртуалізації або емуляції комп'ютерної системи.

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

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

Віртуальні машини блокчейну - це тип віртуальної машини процесу. У контексті блокчейну віртуальна машина посилається на віртуалізацію розподіленої станової машини, яка використовується для розподіленого виконання контрактів, запуску dApps. Аналогічно JVM, EVM - це процес віртуальної машини, призначеної для мови Solidity, де розумні контракти спочатку компілюються в байткод опкоду, а потім інтерпретуються EVM.

Нові громадські ланцюжки поза Ethereum часто використовують віртуальні машини на основі байт-коду WASM або eBPF. WASM - це компактний, швидкий, переносний формат байт-коду на основі механізмів безпеки пісочниці. Розробники можуть писати розумні контракти на різних мовах програмування (C, C++, Rust, Go, Python, Java або навіть TypeScript), компілювати їх у байт-код WASM і виконувати. Розумні контракти, що виконуються на блоці Sei, використовують цей формат байт-коду.

eBPF походить від BPF (Berkeley Packet Filter), спочатку використовувався для ефективного фільтрування мережевих пакетів, і перетворився в eBPF, що пропонує більш багатий набір інструкцій.

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

Інші громадські ланцюги рівня L1, такі як Aptos та Sui, використовують мову програмування розумних контрактів Move, яка компілюється в пропрієтарний байткод, що виконується на віртуальній машині Move. Monad розробив власну віртуальну машину, сумісну з байткодом опкодів EVM (форк Шанхаю).

2.2 Паралельне виконання

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

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

(1) Спочатку, що таке послідовне виконання?

Сценарій 1: Якщо ми розглядаємо систему як банк, а процесор обробки завдань як лічильник, то послідовне виконання завдань подібно до того, що у цьому банку є лише один доступний лічильник для обслуговування. У цьому випадку клієнти (завдання), які приходять в банк, повинні утворити довгу чергу та обслуговувати свої справи по черзі. Для кожного клієнта персонал лічильника повинен повторювати ті ж самі дії (виконувати інструкції) для обслуговування клієнта. Клієнти повинні чекати своєї черги, що призводить до збільшення часу транзакції.

(2) Так що таке паралельне виконання?

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

(3) Яка помилка виникає, якщо немає захисту, і двоє людей одночасно переказують гроші іншій особі?

Сценарій 3: Давайте розглянемо A, B та C, у яких на рахунках відповідно 2 ETH, 1 ETH та 0 ETH. Зараз A та B кожен хоче переказати 0,5 ETH на C. У системі, яка виконує транзакції послідовно, проблем не виникає (ліва стрілка "<=" позначає читання з рахунку, а права стрілка "=>" позначає запис на рахунок, так само нижче):

Однак паралельне виконання не є таким простим, як здається. Є багато важливих деталей, які можуть призвести до серйозних помилок, якщо не ретельно їх обробити. Якщо транзакції A та B з переказом на C виконуються паралельно, послідовність кроків може призвести до неузгоджених результатів:

Паралельне завдання 1 виконує переказ від А до С, а Паралельне завдання 2 виконує переказ від В до С. Кроки, позначені зірочкою, проблематичні: через те що завдання виконуються паралельно, на кроці 2, розрахунок балансу, виконаний Паралельним завданням 1, ще не був записаний в реєстр. На кроці 3 Паралельне завдання 2 зчитує баланс рахунку C (який все ще дорівнює 0) і виконує помилковий розрахунок балансу на основі цього на кроці 5. Потім під час оперції оновлення реєстру на кроці 6, воно неправильно оновлює баланс рахунку, який вже був оновлений до 0.5 на кроці 4, назад до 0.5 знову. Це призводить до того, що баланс рахунку C становить лише 0.5 ETH, незважаючи на те, що як А, так і В переказали по 0.5 ETH кожен, ефективно забираючи інший 0.5 ETH.

(4) Якщо захисту не передбачено, дві задачі, які не залежать одна від одної, можуть виконуватися паралельно без помилок

Сценарій 4: Паралельна задача 1 виконує переказ 0,5 ETH з А (баланс 2 ETH) на C (баланс 0 ETH), і Паралельна задача 2 виконує переказ 0,5 ETH з В (баланс 1 ETH) на D (баланс 0 ETH). Очевидно, що між цими двома завданнями з переказом немає залежності. Незалежно від того, як взаємоплетуться кроки обох завдань, вони не зіткнуться з описаними вище проблемами:

З порівняння цих сценаріїв можна зробити висновок, що при наявності залежності між завданнями під час паралельного виконання можуть виникати помилки в оновленні стану; в іншому випадку помилки не виникатимуть. Завдання (транзакція) вважається мати залежність, якщо воно задовольняє одну з наступних двох умов:

1. Задача записує на вихідну адресу, з якої інша задача читає як вхідну адресу;
2. Дві задачі виводяться на ту саму адресу.

Ця проблема не є унікальною для децентралізованих систем. Будь-який сценарій, що передбачає паралельне виконання, може стикатися з неузгодженістю даних через незахищений доступ до спільних ресурсів (таких як "реєстр" в прикладі з банком або спільна пам'ять у комп'ютерних системах) між кількома залежними завданнями, відомими як гонки даних.

Галузь запропонувала три механізми для вирішення проблем з гонкою даних в паралельному виконанні: механізми передачі повідомлень, механізми спільної пам'яті та механізми строгого списку доступу до стану.

2.3 Механізм передачі повідомлень

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

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

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

Переваги моделі акторів:

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

Недоліки моделі актора:

Кожен актор може виконувати завдання лише послідовно. У певних сценаріях це не використовує переваги паралельності. Наприклад, якщо касири № 2, 3 і 4 одночасно надсилають повідомлення, щоб запитати касира № 1 про баланс рахунку клієнта А, касир № 1 може обробляти ці запити лише по черзі, навіть якщо їх можна було б обробити паралельно.

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

2.4 Механізм спільної пам'яті

2.4.1 Модель блокування пам'яті

Сценарій 6: Уявіть банк з одним великим реєстром, в якому записані баланси рахунків всіх клієнтів. Поруч з реєстром є лише одне ручка для внесення змін до нього.

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

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

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

Платформи блокчейну, такі як Solana, Sui та Sei v1, використовують модель спільної пам'яті на основі блокування пам'яті. Цей механізм може здатися простим, але його складно реалізувати і вимагає від розробників високої кваліфікації у мультипотоковому програмуванні. Недбалість може призвести до різних помилок:

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

Сценарій 2: Завдання блокує ресурс, але в результаті вкладеної бізнес-логіки знову його блокує, що призводить до тупика, де воно чекає на себе.

Модель блокування пам'яті схильна до проблем, таких як взаємоблокування, вічне блокування та голодування:

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

2.4.2 Оптимістичний паралелізм

Сценарій 7

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

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

Під час фази 1 завдання 1, 2 та 3 виконуються паралельно. Однак завдання 2 та 3 одночасно отримують доступ до спільного ресурсу B, що викликає конфлікт, тому завдання 3 переплановано на наступну фазу. У фазі 2 завдання 3 та 4 обидва отримують доступ до ресурсу B, що призводить до перепланування завдання 4, і так далі, поки всі завдання не будуть виконані. Як видно, завдання, які зіштовхуються з конфліктами, повторно виконуються.

Модель оптимістичного паралелізму

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

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

Оптимістична модель паралелізму виникла з ПЗ для управління транзакціями (STM), механізму програмування без блокування в галузі баз даних. Оскільки мережі блокчейн мають вбудований визначений порядок транзакцій, цей концепт було введено та розвинуто в механізм Block-STM. Платформи блокчейну, такі як Aptos та Monad, прийняли Block-STM як свій паралельний механізм виконання.

Варто зазначити, що громадський ланцюг Sei у майбутній версії v2 відмовився від оригінальної моделі блокування пам'яті на користь моделі оптимістичного паралелізму. Блок-STM виконує транзакції з надзвичайною швидкістю; в тестовому середовищі Aptos досяг вражаючої швидкості виконання транзакцій 160 тисяч транзакцій на секунду (tps), що в 18 разів швидше, ніж послідовна обробка транзакцій.

Блок-STM делегує складне виконання транзакцій та їх перевірку команді основних розробників, що дозволяє розробникам писати смарт-контракти так само легко, як у випадку програмування в середовищі послідовного виконання.

2.5 Суворий список доступу до стану

Механізми передачі повідомлень та спільної пам'яті базуються на моделі даних обліку / балансу, яка фіксує інформацію про баланс кожного облікового запису на блокчейні. Це схоже на те, як банківський рахунок показує, що у Клієнта A баланс 1000 одиниць, а у Клієнта B баланс 600 одиниць. Транзакції обробляються просто оновленням статусу балансу облікових записів.

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

• Клієнт А відкриває рахунок та вносить 1 000 одиниць;
• Клієнт B відкриває рахунок (0 одиниць);
• Клієнт А переказує 100 одиниць клієнту Б.

Читаючи та обчислюючи рахунок, можна визначити, що у Клієнта A баланс становить 900 одиниць, а у Клієнта B - 100 одиниць.

UTXO (Unspent Transaction Output) схожий з цією моделлю даних реєстру транзакцій. Це представляє собою спосіб позначення цифрової валюти в Bitcoin, блокчейн першого покоління. Кожна транзакція має входи (як були отримані кошти) та виходи (як були витрачені кошти), і UTXO можна зрозуміти просто як квитанції на отримання коштів, які ще не були витрачені.

Наприклад, якщо клієнт A має 6 BTC і переказує 5,2 BTC клієнту B, залишаючи 0,8 BTC, з точки зору UTXO це виглядає так: 6 UTXO, кожен на 1 BTC, знищуються, і B отримує новий UTXO на суму 5,2 BTC, тоді як A отримує новий UTXO на суму 0,8 BTC як здачу. Таким чином, 6 UTXO знищуються, щоб створити 2 нові UTXO.

Входи та виходи транзакції пов'язані між собою та використовують цифрові підписи для запису інформації про власність, утворюючи таким чином модель UTXO. Блокчейни, які приймають цю модель даних, повинні підсумувати всі UTXO для певної адреси облікового запису, щоб визначити поточний баланс облікового запису. Суворий список доступу до стану (SSAL) базується на моделі UTXO та забезпечує паралельне виконання. Він передбачає попередній розрахунок адрес облікових записів, до яких звертатиметься кожна транзакція, утворюючи список доступу.

Список доступу служить двом цілям:

1. Оцінка безпеки транзакції: Якщо транзакція отримує доступ до адреси, яка не знаходиться у списку доступу, виконання не вдається.
2. Паралельне виконання транзакцій: Згідно зі списком доступу транзакції групуються у кілька наборів. Оскільки між наборами на списку доступу немає залежностей (перетинів), ці набори транзакцій можуть бути виконані паралельно.

3. Фактори зростання промисловості

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

Історично, зі затвердженням SEC фондового Bitcoin ETF та наближенням події зменшення винагороди за блок Bitcoin, а також можливими зниженнями процентних ставок Федерального резерву, очікується, що криптовалюти увійдуть в значний биковий ринок. Стійкий ріст галузі потребує блокчейн-мережевих інфраструктур, здатних обробляти вищу пропускну здатність як міцний фундамент.

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

Щодо розвитку промисловості, хоча постійно з'являються різноманітні технологічні та бізнес-модельні інновації, потенціал для зростання у Web3 залишається в основному невикористаним. Централізовані мережі можуть обробляти понад 50 000 повідомлень на секунду, відправляти 3,4 мільйона електронних листів, виконувати 100 000 пошуків у Google та підтримувати одночасно десятки тисяч гравців в Інтернеті, досягнення, які ще не досягнуті децентралізованими мережами. Для децентралізованих систем, щоб конкурувати та вирізати свою територію, необхідна постійна оптимізація механізмів паралельного виконання та підвищення пропускної здатності транзакцій.

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

4.Існуючі проблеми

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

Багатопотокове програмування особливо складне через дві основні проблеми: по-перше, воно схильне до гонок через неправильну обробку різноманітних складних одночасних операцій управління; по-друге, воно може призвести до аварій через доступ до недійсних адрес пам'яті, що навіть може призвести до вразливостей переповнення буфера, які можуть бути використані зловмисниками.

Існують принаймні три погляди, з яких можна оцінити безпеку проекту:

1. Командний досвід: Команди з досвідом у системному програмуванні володіють багатопотоковим програмуванням та можуть вирішувати 80% складних проблем. Загалом системне програмування включає наступні області:

• Операційні системи
• Різні драйвери пристроїв
• Файлові системи
• Бази даних
• Вбудовані системи
• Криптографія
• Мультимедійні кодеки
• Управління пам'яттю
• Мережа
• Віртуалізація
• Геймінг
• Сучасні мови програмування

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

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

Мова Rust є прикладною у цьому відношенні, тому ми бачимо, що більшість паралельних проектів блокчейну розроблені на Rust. Деякі проекти навіть вибирають з дизайну Rust для реалізації власних мов смарт-контрактів, таких як мова Sway від Fuel.

5. Цільове формування

5.1 На основі оптимістичної моделі паралелізації

5.1.1 Від блокування пам'яті до оптимістичного паралелізму

Sei - це універсальний публічний блокчейн на основі технології з відкритим вихідним кодом, заснований в 2022 році. Засновники є випускниками Університету Каліфорнії в Берклі, а інші члени команди також мають досвід роботи в престижних університетах за кордоном.

Sei отримала фінансування в трьох раундах: раунд насіння на суму 5 мільйонів доларів, перший стратегічний раунд фінансування на суму 30 мільйонів доларів та другий стратегічний раунд фінансування, де сума не була розголошена. Мережа Sei також зібрала загалом 100 мільйонів доларів, щоб підтримати розвиток своєї екосистеми.

У серпні 2023 року Sei запустився на своєму mainnet, претендуючи на звання найшвидшого L1 публічного блокчейну, здатного обробляти 12,500 транзакцій на секунду, при цьому фінальність досягається всього за 380 мс. На даний момент у нього ринкова капіталізація практично $2.2 мільярда.

На сьогоднішній день екосистема Sei налічує 118 проєктів, переважно зосереджених на DeFi, інфраструктурі, NFT, гральних і гаманцях. У спільноті наразі 650 000 учасників у Twitter, 600 000 на Discord і 40 000 у Telegram.

В кінці листопада 2023 року Sei оголосив на своєму офіційному блозі, що запустить найбільше оновлення версії з моменту запуску основної мережі в першій половині 2024 року: Sei v2. Sei v2 вважається першим паралельним блокчейном EVM. Це оновлення версії введе наступні нові можливості:

• Сумісність з попередніми версіями для EVM смарт-контрактів: Розробники можуть мігрувати та розгортати EVM смарт-контракти без модифікації коду.
• Повторне використання загальних інструментів / програм, таких як Metamask.
• Оптимістична паралелізація: Sei v2 відмовиться від механізму спільного доступу до блокування пам'яті на користь оптимістичної паралелізації.
• SeiDB: Оптимізація рівня зберігання.
• Підтримка безшовної взаємодії між Ethereum та іншими ланцюжками.

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

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

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

5.1.2 Потенційний руйнівник на трасі L1: Монада

Якщо ви пропустили розвиток вищезазначених громадських блокчейнів, то вам точно не варто пропустити Monad. Його вважають потенційним дестабілізатором на трасі L1.

Monad був заснований двома старшими інженерами з Jump Crypto у 2022 році. Проект завершив збір $19 мільйонів у лютому 2023 року. У березні 2024 року Paradigm очолив переговори з приводу раунду фінансування понад $200 мільйонів для Monad. У разі успіху це буде найбільше фінансування криптовалюти з початку року.

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

Монада дуже популярна серед капіталу з двох провідних причин: одна - це її міцна технічна база, а інша - вміння ефективно маркетингового хайпу. Основний колектив Monad Labs складається з 30 учасників, всі вони мають десятиліття глибокого досвіду у високочастотній торгівлі, ядерні драйвери та фінансові технології, а також обширний досвід розробки у розподілених системах.

Щоденні операції проекту також дуже «земельні»: постійно залучені до «магічного маркетингу» зі своїми 200 000 фоловерів у Twitter та 150 000 учасників у Discord. Наприклад, проведення щотижневих конкурсів мемів, збір різних кумедних фіолетових тваринних імоджі або відео від спільноти, щоб здійснювати «духовне поширення».

Візія Monad - стати платформою розумних контрактів для розробників, яка принесе екстремальні покращення продуктивності в екосистему Ethereum. Monad вводить два механізми у віртуальну машину Ethereum: один - суперскалярна конвеєрна обробка, а інший - покращений оптимістичний паралельний механізм.

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

Суперскалярна конвеєрна обробка, з іншого боку, починає прати другу купу одягу, поки перша купа висихає. Поки перша купа прасується, друга і третя купи відповідно висихають і прають, забезпечуючи активність кожного етапу.

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

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

5.1.3 Високодецентралізований проект L1: Canto

Заснований у 2022 році, Canto - це високорівневий децентралізований проект L1, побудований на Cosmos SDK. Він працює без офіційного фонду, не займається попередніми продажами, не має стосунків з жодною організацією, не шукає фінансування і повністю керується спільнотою. Навіть основний команду залишається анонімним, працюючи в слабко організованому порядку.

Незважаючи на те, що це загальний блокчейн, сумісний з EVM, основною метою Canto є стати доступною, прозорою, децентралізованою та безкоштовною платформою вартості DeFi. Після вивчення цього сектору було виявлено, що будь-яка здорова екосистема DeFi складається з трьох фундаментальних елементів:

1. Децентралізовані біржі (DEX) такі як Uniswap та Sushiswap;
2. Платформи кредитування, такі як Compound та Aave;
3. Децентралізовані токени, такі як DAI, USDC або USDT.

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

Canto вибирає інший підхід: будує безкоштовну громадську інфраструктуру для DeFi (Безкоштовна Громадська Інфраструктура), робить себе безкоштовним паркінгом для своїх екологічних проєктів.

Інфраструктура складається з трьох протоколів: децентралізована біржа Canto DEX, пулкова платформа для позики Canto Lending Market (CLM), розгалужена від Compound v2, та стабільна валюта NOTE, яку можна позичати з CLM під заставні активи.

Canto вибрав новаторський підхід: побудова безкоштовної громадської інфраструктури, спрямованої на DeFi, позиціонуючи себе як безкоштовне парковочне місце, доступне для використання його проектами екосистеми безкоштовно.

Інфраструктура складається з трьох протоколів: децентралізована біржа Canto DEX, пулкова платформа для позики Canto Lending Market (CLM), розгалужена від Compound v2, та стейблкоїн NOTE, який можна позичати з CLM за допомогою забезпечених активів.

Canto DEX працює постійно як непіддаючий оновленню, протокол без управління. Він ні видає свої токени, ні стягує додаткові комісії. Цей дизайн запобігає різним поведінкам спроби отримати ренту в додатках DeFi екосистеми, уникнення хижих ігор з нульовим сумарним результатом.

Управління платформою кредитування CLM контролюється учасниками, які повністю користуються ростом екосистеми та створюють найкращі умови для розробників та користувачів DeFi, мотивуючи їх продовжувати сприяти. Відсоток, отриманий від виданих позик у NOTE, сплачується позичальникам, протокол не отримує жодних відрахувань.

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

Різними засобами Canto стимулює розробників та користувачів екосистеми приєднатися та постійно збагачувати екосистему. Керуючи 'правами на чеканку', Canto створює можливості для перетинної ліквідності між різними децентралізованими додатками. Якщо екосистема процвітає, її токени збільшуються вартість. Після того, як пропозиція CSR була затверджена голосуванням спільноти 26 січня 2024 року, токен $CANTO пережив підйом ціни.

Внаслідок цього ряду інновацій у бізнес-моделях 18 березня 2024 року Canto оголосила про свій останній раунд технічних ітерацій на своєму офіційному блозі.

Крім того, крім того, якщо підтримується нова версія Cosmos SDK та інтегруються нові технології для зменшення обмежень доступу до сховища, Canto також оновиться до паралельних EVM: введення оптимістичної паралелізації через впровадження Cyclone EVM.

Космос SDK, який використовується Canto, розподіляє обробку транзакцій на три етапи: Пропозиція, Голосування та Фіналізація. Підпроцес ProcessProposal під час Голосування відповідає за паралельне виконання транзакцій. Двигун паралельного виконання відповідає за виконання, тоді як двигун виявлення конфліктів перевіряє валідність транзакцій.

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

5.2 На основі строгих списків доступу до стану: Паливо

Паливо, складене з віртуальної машини FuelVM, мови розробки контрактів Sway, натхненної Rust, та пов'язаного з нею інструментарію, є спеціалізованою модульною «операційною системою для розгортання Ethereum». Проект Fuel був заснований у 2019 році, а в грудні 2020 року Fuel Labs запустила перший шар виконання оптимістичного ролапу на Ethereum, Fuel v1. Після понад трьох років розробки проект нарешті готується до запуску своєї основної мережі у третьому кварталі 2024 року.

Fuel завершив збори коштів у розмірі $1.5 мільйона та $80 мільйонів у 2021 та 2022 роках відповідно. Основна команда складається з понад 60 інженерів, засновник Джон Адлер також є співзасновником рішення щодо доступності даних Celestia Labs та одним з найраніших пропагандистів оптимістичного підходу до rollup. Щодо операцій, у проекті є 270 000 учасників у Twitter та 390 000 в Discord.

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

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

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

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

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

5.3 Крос-ланцюгова інтеграція L1-ланцюгів з L2-рішеннями: Neno, Eclipse та Lumio

L2-рішення мають спільну особливість: вони поєднують можливості двох типів віртуальних машин для підвищення швидкості виконання транзакцій. Зокрема, це передбачає використання паралельних L1 для виконання транзакцій з одночасним збереженням сумісності з іншими ланцюжками (підтримка подвійної віртуальної машини). Однак механізми сумісності, що використовуються різними проектами, відрізняються. У цьому відношенні Neon, Eclipse та Lumio є особливо репрезентативними.

Neon стверджує, що є першим паралельним проектом EVM в екосистемі Solana, що дозволяє розробникам безперешкодно мігрувати проекти екосистеми Ethereum до екосистеми Solana. Eclipse - ще один протокол в екосистемі Solana, сумісний з EVM, побудований за модульною архітектурою. Серед цих трьох проектів тільки Neon випустив свій власний токен, досягнувши ринкової вартості обігу понад 78 мільйонів.

Інші два проекти все ще перебувають на відносно ранніх етапах. Lumio поєднує Aptos та Ethereum для створення оптимістичного протоколу L2 rollup, ефективно виконуючи додатки Ethereum зі швидкістю Move VM.

Щодо фінансування, Neon завершив збір коштів у розмірі $40 мільйонів у листопаді 2021 року та $5 мільйонів у червні 2023 року, загалом $45 мільйонів. Eclipse завершив збір коштів у розмірі $6 мільйонів у серпні 2022 року, $9 мільйонів у вересні 2022 року та $50 мільйонів у березні 2024 року, загалом $65 мільйонів. Lumio ще не збирав коштів.

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

З механічної точки зору, Neon - це емулятор EVM в мережі Solana, який працює як смарт-контракт. Розробники можуть використовувати мови, такі як Solidity та Vyper, для написання додатків dApp, і можуть використовувати інструменти Ethereum та сумісні з Ethereum RPC API, облікові записи, підписи та стандарти токенів, такі як MetaMask, Hardhat та Remix. Тим часом вони користуються перевагами низьких комісій, високої швидкості виконання транзакцій та можливостями паралельної обробки, які надає Solana.

Транзакції Ethereum, відправлені з фронтенду Ethereum dApp, конвертуються проксі в транзакції Solana, після чого вони виконуються в емуляторі, змінюючи стан ланцюга. Це схоже на емулятори ігор, які ми часто використовуємо на ПК, що дозволяють нам грати в ексклюзивні ігри з консолей, таких як Switch і PlayStation, на настільних комп'ютерах. Neon дозволяє розробникам Ethereum запускати додатки Ethereum в мережі Solana.

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

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

Lumio використовує філософію дизайну, незалежну від рівнів виконання та розрахунків, підтримує різні віртуальні машини та сумісний з декількома мережами L1/L2: Ethereum, Aptos, Optimism, Avalanche, zkSync та інші. Він виконує транзакції через Move VM та розраховує їх через EVM, тим самим з'єднуючи екосистеми Ethereum та Aptos.

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

Вище наведено основні проекти, що наразі пов'язані з паралельним наративом EVM, як показано на наступній діаграмі.

6. Висновок та перспективи

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

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

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

З одного боку паралельні EVM використовують спільні технічні принципи. По-перше, оптимістична модель паралельного виконання є консенсусом для L1 публічних блокчейнів. Однак це не означає, що модель блокування пам'яті є непотрібною. Технологічної переваги не існує; скоріше, різниця полягає в рівні кваліфікації розробників.

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

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

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

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

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

Паралельні EVM все ще знаходяться на початкових етапах розвитку, з проектами, такими як Neon, Monad, Canto, Eclipse, Fuel та Lumio, на етапі, коли їхня цінність ще не була повністю реалізована. Особливо Monad, Canto та Fuel.

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

заява:

1. Ця стаття є перепублікуванням з Академія Грифсис) оригінальний заголовок - "Десять тисяч слів інтерпретації паралельного EVM: Як прорвати блокчейн-пропускну спроможність?", авторське право належить оригінальному автору [@leesper6], якщо у вас є які-небудь зауваження до репринту, будь ласка, зв'яжітьсяКоманда Gate Learn, команда якнайшвидше вирішить це відповідно до відповідних процедур.

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

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