Відео останнього епізоду готове: Отримайте швидкий огляд парадигми розвитку BTC L2
https://www.bilibili.com/video/BV1dw411575M/?vd_source=e88bbc11f1ecd88d1c5847538efee51c
Конкуренція в просторі Alt L1 нагрівається, оскільки Near вводить рішення DA, а TVL Sui постійно зростає. У той час як Ethereum витрачає час на оновлення mainnet, L2 вводить дві основні конкурентні точки: паралельні EVM і децентралізовані послідовники.
На сьогоднішній день і в майбутньому фундаментальним фактом є те, що позиція Ethereum складно підірвати. Концепція модульності узагальниться, і якщо спроби Віталіка придушити Celestia будуть неуспішними, ринок буде вибирати селективно. Комбінування та модуляризація не будуть обмежені однією системою, оскільки ринкові принципи будуть підштовхувати команди проектів вільно збирати різні компоненти. Це включає комбінації різних публічних ланцюгів, рішень Layer 2 та Bitcoin, як це очевидно у популярності BTC Layer 2.
Якщо Near може забезпечити доступність даних (DA), високопродуктивні громадські ланцюги, такі як Aptos, Solana та Sui, можуть перейти на L2, врешті-решт стаючи сумісними з Ethereum та об'єднуючись з ним.
Паралельна EVM може бути зрозуміла як паралелізація ланцюгів/L2, сумісних з EVM. Рішення починається з вирішення швидкості блокчейну, теоретично існують два способи подолання проблеми повільних операцій блокчейну:
Припускаючи, що використання апаратного забезпечення досягло піку, паралельний EVM можна класифікувати і розуміти на трьох рівнях:
Дослідження некомпатібільних з EVM Alt L1s має особливе значення, оскільки вони можуть бути інтегровані в екосистему EVM. Крім того, революційне рішення Block-STM від Aptos стало фактичним шаблоном і джерелом натхнення для численних нових паралельних рішень EVM, як це розглянуто в наступних розділах.
Я класифікував концепцію паралельного EVM, використовуючи підхід розбиття, але пояснення концепції паралелізму все ще неповне. Якщо ми безпосередньо перейдемо до пояснення логіки реалізації проекту, це може бути плутано для читачів.
Аналогічно, пояснення типу «процес - це найменша одиниця розподілу ресурсів, а потік - найменша одиниця планування ЦП» є професійним, але не дуже зрозумілим для більшості людей. Я б хотів використати приклад покупки кавунів, щоб проілюструвати цей процес.
По-перше, давайте підготуємо ґрунт. Найнижчий рівень нашого комп'ютера – це фізичне обладнання, а зверху нашаровуються операційна система та різні програми. Коли комп'ютер обробляє завдання, він розподіляє програмні та апаратні ресурси за пріоритетністю. Давайте на прикладі Боба, який купує кавуни, пояснимо цей процес:
Взаємозв'язок між потоками, процесами, паралелізмом та конкурентністю
Тепер, якщо є лише один кавун, але кілька людей, які хочуть його з'їсти, це конкурентність. Ось ключовий момент: усі з'їдають кавун разом, забезпечуючи кожній людині можливість хоча б вкусити. Незалежно від того, як сидять люди або в якому порядку вони їдять, це не впливає на кінцевий результат розділити один кавун.
Ви, можливо, помітили проблему – чому так багато людей повинні разом з'їсти один кавун? Власник кіоску з кавунами суттєво є власником фруктового магазину, і ви також можете їсти банани. Точно! Ось і причина реформи по стороні подання. Зараз власник оголошує, що також є банани. У цьому випадку фізичні ресурси (фрукти) збільшились, і двом Бобам можна кожному з'їсти різні фрукти. Це паралелізм – два ряди поруч, кожен насолоджується своїм улюбленим фруктом.
(Відмова від відповідальності: Вищевказане пояснення спрощене і не професійне. У разі спорів довіряйте розумінню програміста.)
Далі ми поєднаємо ці концепції з EVM і розкриємо справжнє значення паралельного EVM.
Незважаючи на те, що EVM часто згадується, його справжнє значення часто невизначене, особливо оскільки віртуальна машина (VM) дає відчуття переходу від реального до віртуального. Насправді, коротко кажучи, віртуальна машина є спеціалізованою операційною системою. Програмісти не повинні розробляти для фізичних сутностей; їм просто потрібно адаптуватися на рівні програмного забезпечення.
Спрощуючи роль EVM, суть полягає в операціях. Користувачі подають інструкції, а EVM, виходячи з вимог користувачів, таких як перекази, обміни, стейкінг або інші взаємодії з розумними контрактами, виконує їх по одному. Ключовим тут є інструкції та послідовне виконання. EVM може розуміти потреби користувачів, але виконання повинно бути поставлене в чергу; порядок не може бути змінений за бажанням.
Таким чином, паралельний EVM фундаментально змінює порядок виконання, дозволяючи одночасно виконувати кілька розумних контрактів (інструкцій). Це подібно до того, як власник стенду наймає робітників - він продає кавуни, а працівники продають банани, але в кінцевому підсумку бос отримує заробіток.
Пояснення EVM
Одним з найбільш типових прикладів є рішення рівня 2 BTC, згадані в моїй попередній статті. Поточні рішення рівня 2 BTC, по суті, спрямовані на інтеграцію Bitcoin в екосистему EVM. По суті, вони служать віртуальною машиною на Bitcoin, і розробники можуть розробляти проти них, не враховуючи власну архітектуру Bitcoin та обмеження мови програмування, використовуючи знайомий процес розробки EVM для виконання роботи.
Аналогічно, EVM є аналогічним. У крайньому випадку, якщо ви є фронтенд розробником, ви навіть можете розробляти, не розуміючи принципів апаратного забезпечення, принципів операційної системи або принципів Ethereum. Вам просто потрібно розуміти документацію для інструментів розробки та інтерфейсів EVM. Наприклад, ви можете створити фронтенд інтерфейс для DEX – тільки теоретичне пояснення, оскільки на практиці це досить складне.
Коротко кажучи, віртуальна машина - це майстерня, яка обробляє без врахування апаратного забезпечення та принципів. Наприклад, якщо Боб хоче зробити арбузний сік, віртуальна машина - це віджималка. Для приготування склянки арбузного соку потрібно лише три кроки: відкрийте кришку, покладіть арбуз і віджміть - готово.
Так само, EVM - це соковижималка Ethereum. Бути сумісним з EVM - це ніби купувати знижену соковижималку для L1/L2, незважаючи на деякі недоліки, вона працює. Паралельний EVM - це ніби декілька соковижималок, що працюють разом.
Справа не в тому, що ручна праця неефективна; просто соковижималка пропонує кращу вартість за гроші.
Нарешті, поняття паралельного EVM знову виходить на передній план. Фактично, Ethereum може обробляти тільки одну транзакцію через іншу через обмеження швидкості, що призводить до стабільності TPS на основній мережі на рівні приблизно 10. Навіть відносно централізовані ланцюжки, сумісні з EVM, як BNB Chain, можуть збільшуватися лише до приблизно 200. У відсутності революційних проривів у фізичному обладнанні та нездатності Ethereum перетворитися на паралельний механізм, трек паралельного EVM залишиться актуальним на довготривалому горизонті. В кінці кінців, ніхто не скаржиться на швидкість.
Концепції паралелізму та VM існують вже давно, але їх впровадження в блокчейн, особливо концепцію паралельного EVM, можна відслідкувати до 2022 року. Aptos опублікував статтю “Block-STM: Масштабування виконання блокчейну, перетворюючи прокляття упорядкування на благословення продуктивності” як початкову точку. Пізніше, ланцюжок Polygon PoS намагався інтегрувати цю функціональність до кінця року. Не лише це, багато рішень та ідей, запропонованих Aptos у цій статті, стали загальними виборами для індустрії та заслуговують на введення.
Паралельні проекти, пов'язані з EVM та класифікація
Block-STM: Початковий проект паралельної EVM
Можна сказати, що Aptos є лідером паралелизації в блокчейні. Хоча Solana та Near досліджували цю область, Aptos, застосовуючи STM (Transactional Memory Software) для перепорядкування транзакцій у блокчейні, передбачає на початку, що перепорядковані транзакції є правильними. Потім він виконує їх паралельно та виявляє будь-які неспівпадіння пізніше. Індивідуальні неспівпадіння вирішуються окремо. Відповідно до принципу Парето, цей підхід прискорює виконання більшості транзакцій. Це називається оптимістичний механізм верифікації, і основна ідея схожа з оптимістичним механізмом верифікації в Rollup.
Блок-STM
Зокрема, Block-STM поділяє процес виконання блокчейну на два етапи: етап секвенування та етап виконання.
З того часу більшість паралельних реалізацій EVM слідують схожому підходу. Відмінності полягають у реалізації послідовності та виконання, а також у необхідності підвищення сумісності з EVM. Проекти, такі як Neon EVM та Polygon PoS, входять в цю категорію.
Sui Трансформація: все є об'єктом
Sui та Aptos мають спільне походження, і хоча вони дуже схожі, ключова відмінність полягає в тому, що Sui акцентує увагу на об'єктах. Наприклад, у процесі передачі 1 USDT від Аліси до Боба:
Як ви можете побачити, вихідна точка Суі - не перевіряти рахунки обох сторін у операції, а замість цього залучати зміни в властивостях об'єктів. Це може бути розширено поза передачу токенів на активи, такі як NFT.
Крім того, якщо актив передбачає лише зміни атрибутів між двома сторонами, немає необхідності синхронізувати весь вузол. До тих пір, поки обидві сторони визнають транзакцію, такі транзакції можуть оброблятися паралельно.
Звісно, конкретні реалізації обох є набагато більш складними, а паралельність призводить до багатьох викликів. Однак розуміння цього вже достатньо.
Solana та Neon EVM: запуск через існуючий механізм
Solana досягає паралельної обробки через механізм Sea Level, схожий на Block-STM (хоча Sea Level було представлено в 2019 році, перед появою Block-STM в 2022 році). Обидва вимагають послідовного виконання транзакцій перед виконанням.
«Інновація» Solana полягає в спеціалізованій оптимізації апаратних ресурсів. У теорії вона може послідовно виконувати всі інструкції, а оптимізоване багатопотокове використання може використовувати повну потужність процесорів, досягаючи високої конкурентоздатності. Теоретичне значення TPS становить 50 000, а фактичні тести дозволяють досягти приблизно 5 000 в піку.
Отже, яка взаємодія з Neon EVM?
Витрати на неонові EVM
Завдання Neon полягає в синхронізації інформації про транзакції з EVM, а потім виконанні обчислень на Solana. Цей підхід дозволяє використовувати багатство та безпеку екосистеми EVM для додатків, водночас використовуючи Solana для підвищення швидкості та зниження витрат. Порівняно з дорогим та повільним головним мережевим розрахунком Ethereum, авторизації, перекази та взаємодії Neon зазвичай коштують близько 0,1 долара або навіть менше 0,01 долара.
У деякій вільній аналогії Neon перетворює Solana на альтернативний рівень L2 для Ethereum. За розширенням, L1/L2 EVM можуть не тільки реалізувати паралелізм, але й виступати посередниками. Вони можуть фокусуватися на сумісності з EVM або діяти виключно як L1/L2, аутсорсинг залишкових компонентів.
Це відповідає більш широкому концепту модульності та узагальнення, згаданому на початку, де L1/L2 паралельний EVM може бути об'єднаний продуктом трьох проектів або навіть включати комбінації міжланцюжкових з'єднань, пропонуючи різноманітні можливості.
Sei V2 та Monad: Сумісність байтів
З технічної точки зору, Sei V2 та Monad мають значні схожості. Обидва проекти фокусуються на сумісності на рівні байт з EVM на Ethereum. Щодо паралелізації, вони незалежно вибирають знайому оптимістичну перевірку. Вони спочатку послідовно розміщують транзакції, виконують ті, які можуть продовжити, та окремо вирішують залежності у випадку помилок.
Пояснення схеми паралелізації Sei V2
Безумовно, зрілі продукти та підходи широко застосовуються. Однак важливо зазначити, що, як і у випадку з BTC L2, справжні технологічні інновації обмежені, і акцент залишається на «комбінації». Solana виділяється як єдина великомасштабна реалізація паралелізму, що досягає високого паралелізму завдяки поєднанню програмного та апаратного забезпечення. Інші переважно пропонують пакетну угоду «сумісність з EVM + паралелізм».
Як можна очікувати, якщо Солана може виступати як прискорювач, то це можуть зробити і Аптос та інші. Наприклад, Луміо діє за схожим принципом - виступаючи як посередник, одночасно забезпечуючи сумісність з EVM та реалізуючи паралелизм. Таким чином, будь-який проект, який приймає цю подвійну стратегію, може бути названий паралельним EVM. Відповідно, я не буду далі досліджувати Луміо в цьому контексті.
У цій статті я підкреслював, що суть паралельного EVM полягає у розподілі апаратних ресурсів, а також у послідовності та виконанні завдань — обидва важливі компоненти. Апаратні обмеження накладають верхню межу на оптимізацію програмного забезпечення, враховуючи, що навіть Усейн Болт не може перевершити швидкість світла. В даний час більшість паралельних ініціатив EVM є або трансформаціями, або імітаціями Block-STM від Aptos, і це фундаментальна реальність.
Крім того, зараз немає потреби у розгорнутому дослідженні паралельних практик на Ethereum L2. Ці рішення в першу чергу повинні вирішувати проблеми централізації, пов'язані з послідовниками, оскільки їх ефективність вже достатньо висока.
Паралельний EVM не є таємницею. У статті я пропустив технічні деталі, такі як проектування механізму читання-запису, порівняння TPS, запис даних та синхронізація стану. Ці складнощі не є необхідними для зрозуміння звичайної людини. Просто пам'ятайте, що зараз ми знаходимося в епоху оптимістичної перевірки, де виконання передує перевірці помилок. Якщо будуть оновлення, я негайно надам додаткову інформацію.
Відео останнього епізоду готове: Отримайте швидкий огляд парадигми розвитку BTC L2
https://www.bilibili.com/video/BV1dw411575M/?vd_source=e88bbc11f1ecd88d1c5847538efee51c
Конкуренція в просторі Alt L1 нагрівається, оскільки Near вводить рішення DA, а TVL Sui постійно зростає. У той час як Ethereum витрачає час на оновлення mainnet, L2 вводить дві основні конкурентні точки: паралельні EVM і децентралізовані послідовники.
На сьогоднішній день і в майбутньому фундаментальним фактом є те, що позиція Ethereum складно підірвати. Концепція модульності узагальниться, і якщо спроби Віталіка придушити Celestia будуть неуспішними, ринок буде вибирати селективно. Комбінування та модуляризація не будуть обмежені однією системою, оскільки ринкові принципи будуть підштовхувати команди проектів вільно збирати різні компоненти. Це включає комбінації різних публічних ланцюгів, рішень Layer 2 та Bitcoin, як це очевидно у популярності BTC Layer 2.
Якщо Near може забезпечити доступність даних (DA), високопродуктивні громадські ланцюги, такі як Aptos, Solana та Sui, можуть перейти на L2, врешті-решт стаючи сумісними з Ethereum та об'єднуючись з ним.
Паралельна EVM може бути зрозуміла як паралелізація ланцюгів/L2, сумісних з EVM. Рішення починається з вирішення швидкості блокчейну, теоретично існують два способи подолання проблеми повільних операцій блокчейну:
Припускаючи, що використання апаратного забезпечення досягло піку, паралельний EVM можна класифікувати і розуміти на трьох рівнях:
Дослідження некомпатібільних з EVM Alt L1s має особливе значення, оскільки вони можуть бути інтегровані в екосистему EVM. Крім того, революційне рішення Block-STM від Aptos стало фактичним шаблоном і джерелом натхнення для численних нових паралельних рішень EVM, як це розглянуто в наступних розділах.
Я класифікував концепцію паралельного EVM, використовуючи підхід розбиття, але пояснення концепції паралелізму все ще неповне. Якщо ми безпосередньо перейдемо до пояснення логіки реалізації проекту, це може бути плутано для читачів.
Аналогічно, пояснення типу «процес - це найменша одиниця розподілу ресурсів, а потік - найменша одиниця планування ЦП» є професійним, але не дуже зрозумілим для більшості людей. Я б хотів використати приклад покупки кавунів, щоб проілюструвати цей процес.
По-перше, давайте підготуємо ґрунт. Найнижчий рівень нашого комп'ютера – це фізичне обладнання, а зверху нашаровуються операційна система та різні програми. Коли комп'ютер обробляє завдання, він розподіляє програмні та апаратні ресурси за пріоритетністю. Давайте на прикладі Боба, який купує кавуни, пояснимо цей процес:
Взаємозв'язок між потоками, процесами, паралелізмом та конкурентністю
Тепер, якщо є лише один кавун, але кілька людей, які хочуть його з'їсти, це конкурентність. Ось ключовий момент: усі з'їдають кавун разом, забезпечуючи кожній людині можливість хоча б вкусити. Незалежно від того, як сидять люди або в якому порядку вони їдять, це не впливає на кінцевий результат розділити один кавун.
Ви, можливо, помітили проблему – чому так багато людей повинні разом з'їсти один кавун? Власник кіоску з кавунами суттєво є власником фруктового магазину, і ви також можете їсти банани. Точно! Ось і причина реформи по стороні подання. Зараз власник оголошує, що також є банани. У цьому випадку фізичні ресурси (фрукти) збільшились, і двом Бобам можна кожному з'їсти різні фрукти. Це паралелізм – два ряди поруч, кожен насолоджується своїм улюбленим фруктом.
(Відмова від відповідальності: Вищевказане пояснення спрощене і не професійне. У разі спорів довіряйте розумінню програміста.)
Далі ми поєднаємо ці концепції з EVM і розкриємо справжнє значення паралельного EVM.
Незважаючи на те, що EVM часто згадується, його справжнє значення часто невизначене, особливо оскільки віртуальна машина (VM) дає відчуття переходу від реального до віртуального. Насправді, коротко кажучи, віртуальна машина є спеціалізованою операційною системою. Програмісти не повинні розробляти для фізичних сутностей; їм просто потрібно адаптуватися на рівні програмного забезпечення.
Спрощуючи роль EVM, суть полягає в операціях. Користувачі подають інструкції, а EVM, виходячи з вимог користувачів, таких як перекази, обміни, стейкінг або інші взаємодії з розумними контрактами, виконує їх по одному. Ключовим тут є інструкції та послідовне виконання. EVM може розуміти потреби користувачів, але виконання повинно бути поставлене в чергу; порядок не може бути змінений за бажанням.
Таким чином, паралельний EVM фундаментально змінює порядок виконання, дозволяючи одночасно виконувати кілька розумних контрактів (інструкцій). Це подібно до того, як власник стенду наймає робітників - він продає кавуни, а працівники продають банани, але в кінцевому підсумку бос отримує заробіток.
Пояснення EVM
Одним з найбільш типових прикладів є рішення рівня 2 BTC, згадані в моїй попередній статті. Поточні рішення рівня 2 BTC, по суті, спрямовані на інтеграцію Bitcoin в екосистему EVM. По суті, вони служать віртуальною машиною на Bitcoin, і розробники можуть розробляти проти них, не враховуючи власну архітектуру Bitcoin та обмеження мови програмування, використовуючи знайомий процес розробки EVM для виконання роботи.
Аналогічно, EVM є аналогічним. У крайньому випадку, якщо ви є фронтенд розробником, ви навіть можете розробляти, не розуміючи принципів апаратного забезпечення, принципів операційної системи або принципів Ethereum. Вам просто потрібно розуміти документацію для інструментів розробки та інтерфейсів EVM. Наприклад, ви можете створити фронтенд інтерфейс для DEX – тільки теоретичне пояснення, оскільки на практиці це досить складне.
Коротко кажучи, віртуальна машина - це майстерня, яка обробляє без врахування апаратного забезпечення та принципів. Наприклад, якщо Боб хоче зробити арбузний сік, віртуальна машина - це віджималка. Для приготування склянки арбузного соку потрібно лише три кроки: відкрийте кришку, покладіть арбуз і віджміть - готово.
Так само, EVM - це соковижималка Ethereum. Бути сумісним з EVM - це ніби купувати знижену соковижималку для L1/L2, незважаючи на деякі недоліки, вона працює. Паралельний EVM - це ніби декілька соковижималок, що працюють разом.
Справа не в тому, що ручна праця неефективна; просто соковижималка пропонує кращу вартість за гроші.
Нарешті, поняття паралельного EVM знову виходить на передній план. Фактично, Ethereum може обробляти тільки одну транзакцію через іншу через обмеження швидкості, що призводить до стабільності TPS на основній мережі на рівні приблизно 10. Навіть відносно централізовані ланцюжки, сумісні з EVM, як BNB Chain, можуть збільшуватися лише до приблизно 200. У відсутності революційних проривів у фізичному обладнанні та нездатності Ethereum перетворитися на паралельний механізм, трек паралельного EVM залишиться актуальним на довготривалому горизонті. В кінці кінців, ніхто не скаржиться на швидкість.
Концепції паралелізму та VM існують вже давно, але їх впровадження в блокчейн, особливо концепцію паралельного EVM, можна відслідкувати до 2022 року. Aptos опублікував статтю “Block-STM: Масштабування виконання блокчейну, перетворюючи прокляття упорядкування на благословення продуктивності” як початкову точку. Пізніше, ланцюжок Polygon PoS намагався інтегрувати цю функціональність до кінця року. Не лише це, багато рішень та ідей, запропонованих Aptos у цій статті, стали загальними виборами для індустрії та заслуговують на введення.
Паралельні проекти, пов'язані з EVM та класифікація
Block-STM: Початковий проект паралельної EVM
Можна сказати, що Aptos є лідером паралелизації в блокчейні. Хоча Solana та Near досліджували цю область, Aptos, застосовуючи STM (Transactional Memory Software) для перепорядкування транзакцій у блокчейні, передбачає на початку, що перепорядковані транзакції є правильними. Потім він виконує їх паралельно та виявляє будь-які неспівпадіння пізніше. Індивідуальні неспівпадіння вирішуються окремо. Відповідно до принципу Парето, цей підхід прискорює виконання більшості транзакцій. Це називається оптимістичний механізм верифікації, і основна ідея схожа з оптимістичним механізмом верифікації в Rollup.
Блок-STM
Зокрема, Block-STM поділяє процес виконання блокчейну на два етапи: етап секвенування та етап виконання.
З того часу більшість паралельних реалізацій EVM слідують схожому підходу. Відмінності полягають у реалізації послідовності та виконання, а також у необхідності підвищення сумісності з EVM. Проекти, такі як Neon EVM та Polygon PoS, входять в цю категорію.
Sui Трансформація: все є об'єктом
Sui та Aptos мають спільне походження, і хоча вони дуже схожі, ключова відмінність полягає в тому, що Sui акцентує увагу на об'єктах. Наприклад, у процесі передачі 1 USDT від Аліси до Боба:
Як ви можете побачити, вихідна точка Суі - не перевіряти рахунки обох сторін у операції, а замість цього залучати зміни в властивостях об'єктів. Це може бути розширено поза передачу токенів на активи, такі як NFT.
Крім того, якщо актив передбачає лише зміни атрибутів між двома сторонами, немає необхідності синхронізувати весь вузол. До тих пір, поки обидві сторони визнають транзакцію, такі транзакції можуть оброблятися паралельно.
Звісно, конкретні реалізації обох є набагато більш складними, а паралельність призводить до багатьох викликів. Однак розуміння цього вже достатньо.
Solana та Neon EVM: запуск через існуючий механізм
Solana досягає паралельної обробки через механізм Sea Level, схожий на Block-STM (хоча Sea Level було представлено в 2019 році, перед появою Block-STM в 2022 році). Обидва вимагають послідовного виконання транзакцій перед виконанням.
«Інновація» Solana полягає в спеціалізованій оптимізації апаратних ресурсів. У теорії вона може послідовно виконувати всі інструкції, а оптимізоване багатопотокове використання може використовувати повну потужність процесорів, досягаючи високої конкурентоздатності. Теоретичне значення TPS становить 50 000, а фактичні тести дозволяють досягти приблизно 5 000 в піку.
Отже, яка взаємодія з Neon EVM?
Витрати на неонові EVM
Завдання Neon полягає в синхронізації інформації про транзакції з EVM, а потім виконанні обчислень на Solana. Цей підхід дозволяє використовувати багатство та безпеку екосистеми EVM для додатків, водночас використовуючи Solana для підвищення швидкості та зниження витрат. Порівняно з дорогим та повільним головним мережевим розрахунком Ethereum, авторизації, перекази та взаємодії Neon зазвичай коштують близько 0,1 долара або навіть менше 0,01 долара.
У деякій вільній аналогії Neon перетворює Solana на альтернативний рівень L2 для Ethereum. За розширенням, L1/L2 EVM можуть не тільки реалізувати паралелізм, але й виступати посередниками. Вони можуть фокусуватися на сумісності з EVM або діяти виключно як L1/L2, аутсорсинг залишкових компонентів.
Це відповідає більш широкому концепту модульності та узагальнення, згаданому на початку, де L1/L2 паралельний EVM може бути об'єднаний продуктом трьох проектів або навіть включати комбінації міжланцюжкових з'єднань, пропонуючи різноманітні можливості.
Sei V2 та Monad: Сумісність байтів
З технічної точки зору, Sei V2 та Monad мають значні схожості. Обидва проекти фокусуються на сумісності на рівні байт з EVM на Ethereum. Щодо паралелізації, вони незалежно вибирають знайому оптимістичну перевірку. Вони спочатку послідовно розміщують транзакції, виконують ті, які можуть продовжити, та окремо вирішують залежності у випадку помилок.
Пояснення схеми паралелізації Sei V2
Безумовно, зрілі продукти та підходи широко застосовуються. Однак важливо зазначити, що, як і у випадку з BTC L2, справжні технологічні інновації обмежені, і акцент залишається на «комбінації». Solana виділяється як єдина великомасштабна реалізація паралелізму, що досягає високого паралелізму завдяки поєднанню програмного та апаратного забезпечення. Інші переважно пропонують пакетну угоду «сумісність з EVM + паралелізм».
Як можна очікувати, якщо Солана може виступати як прискорювач, то це можуть зробити і Аптос та інші. Наприклад, Луміо діє за схожим принципом - виступаючи як посередник, одночасно забезпечуючи сумісність з EVM та реалізуючи паралелизм. Таким чином, будь-який проект, який приймає цю подвійну стратегію, може бути названий паралельним EVM. Відповідно, я не буду далі досліджувати Луміо в цьому контексті.
У цій статті я підкреслював, що суть паралельного EVM полягає у розподілі апаратних ресурсів, а також у послідовності та виконанні завдань — обидва важливі компоненти. Апаратні обмеження накладають верхню межу на оптимізацію програмного забезпечення, враховуючи, що навіть Усейн Болт не може перевершити швидкість світла. В даний час більшість паралельних ініціатив EVM є або трансформаціями, або імітаціями Block-STM від Aptos, і це фундаментальна реальність.
Крім того, зараз немає потреби у розгорнутому дослідженні паралельних практик на Ethereum L2. Ці рішення в першу чергу повинні вирішувати проблеми централізації, пов'язані з послідовниками, оскільки їх ефективність вже достатньо висока.
Паралельний EVM не є таємницею. У статті я пропустив технічні деталі, такі як проектування механізму читання-запису, порівняння TPS, запис даних та синхронізація стану. Ці складнощі не є необхідними для зрозуміння звичайної людини. Просто пам'ятайте, що зараз ми знаходимося в епоху оптимістичної перевірки, де виконання передує перевірці помилок. Якщо будуть оновлення, я негайно надам додаткову інформацію.