Як технічно відбувається міграція?
Це відбувається відповідно до процедури «заморожування, а потім скидання» у Mainnet:
- Фіксація L1 на обраному блоці-снапшоті, щоб він більше не генерував нових блоків. Цей останній блок і є блоком-снапшотом.
- Експорт повного стану на момент цього блоку та перевірка його на відповідність кореневому стану блоків і відомому загальному обсягу емісії.
- Перетворення цього стану на генезисний стан OP Stack L2, щоб L2 починався з уже сформованого повного стану L1.
У чому полягають технічні відмінності між L1 і L2?
| L1 | L2 | |
| Архітектура | Виконання, консенсус і дані в одному сервісі | OP Stack: розділення виконання, даних та розрахунків |
| Консенсус | Proof of Authority (один валідатор) | Секвенсер OP Stack, який на етапі запуску обслуговуватиме компанія WhiteBIT |
| Токен газу | WBT | WBT |
| Модель газу | Фіксована: 10 gwei | EIP-1559 та комісія L1 data |
| Час виконання блоку | 2 секунди | 1 секунда |
| Дані та розрахунки | Автономні | Опубліковуються та фіксуються на Ethereum за допомогою “blobs” |
| Bridging | Тільки сторонній bridge | Нативний OP canonical bridge, Portal, та сторонній bridge |
Оскільки EVM залишається незмінним, код смарт-контракту виконується так само. Відмінності полягають у двох моментах: модель комісій змінюється з фіксованої суми 10 gwei на EIP-1559 плюс комісія за передачу даних на рівні L1, а блоки надходять щосекунди, а не кожні 2 секунди. Рекомендується переглянути будь-яку логіку, в якій жорстко задано ціну газу або передбачено інтервал між блоками.
Зверніть увагу, що байт-код, storage, nonces та адреси зберігаються, тому контракти існують на L2 за тими самими адресами. Це означає, що повторне розгортання не потрібне; просто змініть URL-адресу RPC та ідентифікатор ланцюга, а потім повторно перевірте вихідний код вашого смарт-контракту в експлорері L2, щоб користувачі могли його там переглянути.