Оригінальний автор: Haotian (X: @tmel0211)
На ринку з’явився новий наратив про «паралельний EVM», який дуже цікавий на рівні 2, який може реалізувати нову парадигму «рафінованого» роллапу, а перебільшення може досягти магічного ефекту перетворення Solana на новий рівень 2 Ethereum.
На мою думку, паралельний EVM — це лише прояв високого ступеня «модульності» Rollup, ** після вторгнення DA третьою стороною, рівень виконання VM знову впав, і рівень 2 буде перевизначено в майбутньому. Далі розберемо з позицій науково-популярної тематики:
Щоб розібратися в цій темі, потрібно спочатку уточнити однопотокову модель виконання «ЕВМ».
Ця модель передбачає, що транзакції повинні оброблятися та підтверджуватися одна за одною по порядку, що безпосередньо впливає на швидкість обробки транзакцій, час блоку та пропускну здатність транзакцій, що є основною причиною високого газу та перевантаженості основної мережі Ethereum. Крім того, причина, по якій він розроблений як однопотоковий, має певні історичні обмеження. **
Оскільки транзакції на Ethereum перевіряються та виконуються розподіленими незалежними нодами, необхідно забезпечити, щоб усі адресні дані, такі як баланси, код смарт-контракту тощо, зберігали однаковий стан між різними вузлами, і в той же час гарантувати, що немає можливості подвійного витрачання одного й того ж активу.
Це дозволяє послідовно ставити транзакції в чергу. Якщо є паралельні транзакції, це може призвести до помилок синхронізації даних між вузлами, а ключовим є те, що будуть серйозні транзакції з подвійними витратами.
Популярне пояснення: у банку лише одне вікно обслуговування, зняття коштів клієнтами має бути в черзі по порядку, будь то зняття депозитів та кредити та інші справи, клієнт може розпочати наступне після завершення бізнесу, перевага в тому, що кожна операція системи рахунків банку буде точно фіксуватися, але час очікування клієнта в черзі буде довшим;
Якщо банк відкриє кілька вікон обслуговування, клієнти можуть вибрати вікно для ведення різних справ, буде два вікна одночасно, щоб спробувати списати гроші з одного рахунку, якщо звірка системи рахунків між вікнами не буде своєчасною, це призведе до подвійних витрат, очевидно, це значно підвищує ефективність, але складна логіка бухгалтерського обліку створить тиск на систему обліку.
У сценарії незалежного ланцюга рівня 1, якщо базовий ланцюг підтримує паралельну обробку, проблема буде вирішена завдяки розділенню стану обчислень і зберігання VM Solana Node відсортує ці транзакції після отримання кількох транзакцій від користувачів, а потім викличе дані про стан незалежної системи зберігання, щоб визначити, чи мають ці транзакції конфлікти станів, якщо конфлікту немає, транзакції будуть упаковані в блок, а якщо конфлікт є, конфліктуючі транзакції будуть виключені з цього блоку.
Навпаки, стан зберігання Ethereum обчислюється в режимі реального часу, і кожна транзакція повинна дочекатися завершення попередньої транзакції, перш ніж оновлювати стан, тому неможливо перевірити транзакції перед очікуванням упаковки, що обмежує можливість паралельної обробки. **
У випадку ланцюжків згортання рівня 2, щоб досягти паралельної обробки, це схоже на те, щоб триматися подалі. Ви можете думати про обчислення транзакцій і визначення стану зберігання Solana під час очікування часових позначок POH як процес, за допомогою якого Rollup Chain обробляє транзакції в Sequener, а потім пакетує їх в основну мережу.
Тепер, коли Sequener рівня 2 буде розташовувати транзакції в хронологічному порядку перед пакетними транзакціями, а потім групувати їх в основній мережі по порядку, як він може бути багатопотоковим?
**1) Виходячи з моделі абстракції рахунку АА, зі стану рахунку можна ініціювати кілька транзакцій одночасно, **Наприклад, якщо два перекази виконуються одночасно, смарт-контракт АА дасть йому nonce, який потрібно виконувати послідовно, якщо один Transfer, інший Approve, його можна обробляти паралельно більш гнучко без обмежень nonce. У моделі облікового запису АА кожен акаунт може налаштувати логіку обробки транзакцій для досягнення високого паралелізму з nonce.
Наприклад, коли транзакції рівня 2 надсилаються до секвенсера, секвенсер може швидко визначити логіку транзакції та виконати тонке сортування та перевірку, наприклад, якщо один і той самий рахунок ініціює два перекази, останній слід виключити та дочекатися наступного пакету, а якщо один і той самий рахунок ініціює дві операції різного характеру, це можна зробити одночасно Згрупуйте в блок.
Звучить просто, але це не так, якщо взяти за приклад сценарій децентралізованих фінансів, то для Sequencer є дві основні проблеми, пов’язані з досягненням точного управління транзакціями:
**1) Щоб проаналізувати дані про транзакції в режимі реального часу та зрозуміти методи виклику смарт-контрактів та параметри вхідних даних, **Візьмемо для прикладу звичайний стейкінг децентралізованих фінансів, операція стейкінгу включає передачу токенів, оновлення стану, період стейкінгу та розрахунок потенційної винагороди. Якщо в деякі транзакції стейкінгу одночасно надходить велика кількість користувачів, якщо є також транзакції, змішані зі стейкінгом, а потім переказом, у поєднанні зі складними ціновими факторами Oralce тощо, якщо Sequener не може правильно розібрати та обробити його, помилка може призвести до серйозних аварій.
- Секвенсер повинен забезпечити децентралізацію, поточний Sequener рівня 2 є лише Пакетною транзакцією за умови, що права занадто великі, якщо проблема децентралізації секвенсера не може бути вирішена, а потім зробити «тонке» зведення, що еквівалентно наданню Секвенсеру більше дозволів. Якщо Секвенсер здійснює фальшиві транзакції, нахабно бере участь у кліпах MEV або навіть зловмисно маніпулює ліквідацією Oracle тощо, він розмножиться.
Останнім часом **Metis став популярним, нібито просто Sequencer досяг децентралізації, і на більш глибокому рівні він побудував базову передумову консенсусу для Sequencer, щоб робити вдосконалені зведення в майбутньому. **
Звичайно, покладатися на Sequencer для досягнення високоточної агрегації та обробки транзакцій rollup - це все ще лише ідея, ** На щастя, абстракція облікового запису AA, загальна модульна комбінація відкритого розуму Blockchain забезпечує передумову для реалізації цієї ідеї. **
Вище.
Крім того, як згадувалося вище, рівень 2 в цілому стає все більш модульним, вбудовуючи технологію ZK в структуру стека OP для досягнення розширення конфіденційності, перетворюючи оригінальний DA Ethereum на сторонній DA, такий як Celestia, щоб зменшити витрати, поступово змінюючи традицію ETH як плату за газ, надаючи токену рівня 2 більше можливостей корисності, і навіть рівень 2 може групувати транзакції та надсилати їх у різні середовища виконання віртуальних машин, і транзакції будуть розподілені Solana, Ethereum та багато іншого.
У цей час з’явиться нова парадигма, і нинішній рівень 2 - це вже не просто рівень 2 Ethereum, Solana також може бути рівнем 2 Ethereum, і навіть визначення рівня 2 буде чарівним чином змінено.
** Сміливе припущення, тепер рівень 2 став «рівнем 1» початкового рівня, що об’єднує високі можливості одночасної обробки транзакцій, а Ethereum, Solana, ці колишні рівні 1, стали новим «рівнем 2» для розрахунків за активами та забезпечення безпеки. **
** Рівень 2 ніколи не був жорсткою концепцією, і місія платформ рівня 2 щодо вирішення великомасштабної паралельної обробки транзакцій і залучення додаткових груп користувачів ринку існувала завжди. **
Якщо місія буде досягнута, згідно з ідеєю модульності, не тільки легітимність рівня 1 Ethereum буде порушена, але і весь ланцюжок доступності даних DA, рівня виконання віртуальних машин і навіть взаємодії зв’язку інтероперабельності стане інфраструктурою для рівня 2 для досягнення масового прийняття.
У той час рівень 2 перестане бути просто доповненням до рівня 1, а стане потужною та всеосяжною платформою агрегації транзакцій та обробки розподілу.
Посилання на оригінал статті
