Рівень 2 більше не є просто рівнем 2 Ethereum.
Автор: Haotian
На ринку з’явився новий наратив «паралельного EVM», який є дуже цікавим на рівні 2. Він може реалізувати нову «рафіновану» парадигму Rollup. Якщо перебільшити, він може досягти магічного ефекту, коли Солана стає новим рівнем 2 Ethereum.
На мій погляд, паралельний EVM — це лише дуже «модульний» прояв Rollup. Після того, як DA було вторгнуто третьою стороною, рівень виконання VM знову впав, а рівень 2 буде перевизначено в майбутньому. чому Далі проаналізуємо це з науково-популярної точки зору:
Щоб зрозуміти цю тему, ви повинні спочатку прояснити однопотокову модель виконання “EVM”.
Ця модель передбачає, що транзакції повинні оброблятися та підтверджуватися одна за одною в порядку, що безпосередньо впливає на швидкість обробки транзакцій, час генерації блоків, пропускну здатність транзакцій тощо, і є основною причиною високого газу та перевантаження магістралі Ethereum. мережі. Крім того, причина, чому він розроблений як однопотоковий, має певні історичні обмеження.
Оскільки транзакції в Ethereum перевіряються та виконуються розподіленими незалежними вузлами, необхідно переконатися, що дані всіх адрес, такі як баланси, коди смарт-контрактів тощо, залишаються узгодженими між різними вузлами. необхідно переконатися, що немає ідентичних активів.Виникає можливість подвійних витрат.
Це призводить до того, що транзакції ставляться в чергу в порядку. Якщо виникають паралельні транзакції, це може призвести до помилок у синхронізації даних між вузлами.Ключ полягає в тому, що можуть виникнути серйозні транзакції подвійного витрачання.
Популярне пояснення: банк має лише одне вікно обслуговування, і клієнти повинні стояти в черзі, щоб зняти гроші. Будь то депозити, зняття коштів, позики та інші послуги, один клієнт може почати наступний лише після завершення бізнесу. Перевага полягає в тому, що що кожна операція облікової системи банку точно фіксуватиметься, але час черги для клієнтів буде довшим;
Якщо банк відкриває кілька вікон обслуговування, і клієнти можуть вибрати вікно для обробки різних видів бізнесу, буде два вікна, які намагатимуться зняти гроші з одного рахунку одночасно. Якщо звірка системи рахунків між вікнами не відбувається вчасно, це призведе до Подвійні витрати Очевидно, що це буде Ефективність, очевидно, покращиться, але складна облікова логіка чинить тиск на облікову систему.
У сценарії незалежного ланцюга рівня 1, якщо нижній рівень ланцюга підтримує паралельну обробку, проблема буде легко вирішена. Оскільки стани обчислення та сховища Solana розділені, після того, як її віртуальна машина отримає кілька транзакцій від користувачів, вузол сортуватиме ці транзакції та потім викличте незалежний ланцюжок. Дані про стан системи зберігання визначають, чи існує конфлікт статусу в цих транзакціях. Якщо конфлікту немає, транзакцію буде упаковано в блок. Якщо є конфлікт, конфліктну транзакцію буде виключено з цей блок.
Для порівняння, статус зберігання Ethereum обчислюється в режимі реального часу. Кожна транзакція повинна чекати завершення попередньої транзакції перед оновленням статусу. Тому неможливо відфільтрувати транзакції до очікування упаковки, що обмежує можливість її паралельної обробки. .
У сценарії Layer2 Rollup chain для досягнення паралельної обробки відстань є подібною. Ви можете розглядати обчислення транзакцій Solana та виявлення статусу зберігання в очікуванні мітки часу POH як процес обробки транзакцій у ланцюжку зведених даних у Sequener, а потім їх групування в основну мережу.
Тепер, перш ніж рівень 2 групує транзакції, Sequener спочатку розташує nonces для транзакцій у хронологічному порядку, а потім групує їх у основну мережу в порядку.Як ми можемо досягти багатопотоковості?
На основі абстрактної моделі облікового запису AA можна ініціювати кілька транзакцій одночасно зі статусу облікового запису. Наприклад, якщо два перекази виконуються одночасно, смарт-контракт AA надасть їм nonce, який якщо транзакцію схвалено, її можна обробляти більш гнучко паралельно, не обмежуючись nonce. У моделі облікового запису AA кожен обліковий запис може налаштувати логіку обробки транзакцій, а потім співпрацювати з nonce для досягнення високого рівня паралельності.
У Sequencer можна виконувати «покращену» обробку транзакцій. Наприклад, коли транзакції рівня 2 надсилаються до Sequencer, Sequencer може швидко виявити ці логіки транзакцій і виконати уточнене сортування та відбір. Наприклад, якщо той самий обліковий запис ініціює двох переказів, останню необхідно виключити та дочекатися наступної партії. Якщо один і той же обліковий запис ініціює дві операції різного характеру, їх можна групувати в блок одночасно.
Звучить просто? Але це ні в якому разі не так. Беручи за приклад сценарій DeFi, Sequencer стикається з двома основними проблемами, щоб досягти вдосконаленого керування транзакціями:
Необхідно аналізувати дані транзакцій у режимі реального часу та розуміти методи виклику смарт-контракту та параметри вхідних даних. Візьміть як приклад звичайний стейкінг у DeFi. Операція стейкінгу включає передачу токенів, оновлення статусу, період застави та розрахунок потенційних винагород тощо. Якщо велика кількість користувачів надсилає кілька транзакцій застави одночасно, якщо також є транзакції, що включають заставу, а потім передачу, у поєднанні зі складними ціновими факторами Oralce тощо, якщо Sequener не може проаналізувати та обробити це належним чином, помилка в одному крок може призвести до серйозних нещасних випадків.
Секвенсор повинен забезпечувати децентралізацію. Наразі Секвенсор рівня 2 має лише пакетні транзакції, і його права надто великі. Якщо проблему децентралізації Секвенсора неможливо вирішити, тоді Секвенсеру буде надано “досконалений” зведений доступ. Якщо Sequencer здійснює фальшиві транзакції, відверто використовує пастки MEV або навіть зловмисно маніпулює ліквідацією Oracle тощо, це буде розмножуватися.
Нещодавно Metis став популярним. На поверхні він лише реалізує децентралізацію Sequencer. На глибшому рівні він створює основну консенсусну передумову для майбутнього Sequencer для вдосконаленого зведення.
Звичайно, покладатися на Sequencer для досягнення високоточного агрегування та обробки транзакцій Rollup поки що лише ідея. На щастя, абстракція облікового запису AA та відкрита ідея модульної комбінації всього блокчейну забезпечують передумови для реалізації цієї ідеї. .
це все.
Крім того, як згадувалося вище, рівень 2 в цілому стає все більш модульним. Технологія ZK вбудована в структуру OP Stack для досягнення розширення конфіденційності; оригінальний Ethereum DA перетворюється на сторонній DA, такий як Celestia, щоб зменшити витрати; ETH є поступово використовується як газ Традицію комісії також було змінено, що дало токенам рівня 2 більшу практичність; навіть рівень 2 може групувати пакетні транзакції та надсилати їх до різних середовищ виконання ВМ, а транзакції поділяються на Solana та Ethereum для обробки тощо.
До того часу з’явиться нова парадигма. Поточний рівень 2 — це вже не просто рівень 2 Ethereum. Solana також може бути рівнем 2 Ethereum, і навіть визначення рівня 2 буде змінено магічним чином.
Як смілива ідея, рівень 2 тепер став «рівнем 1» початкового рівня, який інтегрує можливості обробки транзакцій з високим рівнем паралелізму, а колишній рівень 1, такий як Ethereum і Solana, став новим «рівнем 2», який обробляє врегулювання активів і забезпечення безпеки.
Рівень 2 ніколи не був жорсткою концепцією. Платформи рівня 2 завжди мали завдання вирішити великомасштабну одночасну обробку транзакцій і залучити додаткові ринкові групи користувачів.
Якщо місія буде досягнута, згідно з модульною ідеєю, легітимність рівня 1 Ethereum буде порушена, але доступність даних DA, рівень виконання віртуальної машини та навіть комунікаційна взаємодія взаємодії всього ланцюга стануть інфраструктурою для реалізації рівня 2 Масове усиновлення.
До того часу Layer2 перестане бути лише доповненням до Layer1, а стане потужною комплексною платформою агрегації транзакцій і обробки розподілу. Дозвольте запитати, хто чий Layer2?