Ethereum розкриває план масштабування, чим цього разу відрізняється?

Автор оригіналу: @VitalikButerin
Переклад: Пеггі, BlockBeats

Примітка редактора: Оскільки екосистема Ethereum продовжує зростати, досягнення масштабованості мережі без шкоди для безпеки та децентралізації стало основним завданням. У цій статті Віталік Бутерін далі окреслює шлях масштабованості Ethereum: у короткостроковій перспективі покращення ефективності виконання завдяки оптимізації механізму Gas, паралелізації підтвердження блоків та інших технічних оновлень; у довгостроковій перспективі, покладаючись на архітектуру ZK-EVM і структуру даних blobs для забезпечення масштабованості мережі.

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

Ось оригінальний текст:

Тепер давайте поговоримо про масштабування. Вона може бути розділена на дві частини: масштабування в короткостроковій перспективі та масштабування в довгостроковій перспективі.

Масштабування в короткостроковій перспективі

Щодо масштабування в короткостроковій перспективі, я писав про це в іншому місці. Основна ідея приблизно така:

· Списки доступу на рівні блоків (які будуть впроваджені в оновленні Glamsterdam) можуть уможливити паралелізацію перевірки блоків.

· ePBS (також буде впроваджено в Glamsterdam) має кілька функцій, одна з яких: він дозволяє нам безпечно використовувати більшу частку часу в кожному слоті для перевірки блоків, а не просто використовувати кілька сотень мілісекунд, як зараз.

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

Щодо багатовимірного газу, ми розробили поетапний план дій. Перший етап - це оновлення Glamsterdam, де "вартість налаштування стану" відокремлена від "вартість виконання та даних виклику".

Наприклад, зараз: операція SSTORE коштує 5000 газів, якщо слот зберігання змінюється з ненульового → ненульового; вона коштує 20000 газів, якщо він змінюється з нульового → ненульового.

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

Щодо причин, я писав раніше: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

Тому в Glamsterdam: Ця операція SSTORE споживатиме 5000 "базових газів", наприклад, 55000 "газів для створення стану".

Важливо зазначити: Гази для створення стану не враховуються в приблизно 16-мільйонному ліміті транзакційних газів.

Це означає: Стане можливим створювати більші за обсягом контракти, ніж зараз.

Як у EVM досягається багатовимірний газ?

Ось проблема: У конструкції EVM передбачається, що газ має лише один вимір; наприклад, GAS, CALL та інші оператори базуються на цьому припущенні.

Наше рішення полягає в підтримці двох інваріантів:

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

Якщо оператор GAS повідомляє вам, що у вас зараз є газ Y, а потім ви ініціюєте виклик, який споживає газ X, після повернення виклику у вас все ще залишається принаймні газ Y − X, доступний для наступних операцій.

Конкретна реалізація: Ми вводимо N+1 вимірів газу. За замовчуванням N = 1 (створення стану), а додатковий вимір називається резервуаром.

Логіка виконання EVM така:

Якщо можливо, спочатку використовуйте газ із спеціалізованих вимірів.

Якщо цього недостатньо, використовуйте газ із резервуара.

Наприклад, якщо у вас є: (100000 газ для створення стану, 100000 резервуар)

Якщо ви використовуєте SSTORE для створення трьох нових станів, процес трансформації газу такий: (100000, 100000) → (45000, 95000) → (0, 80000) → (0, 20000)

У цій конструкції:

Оператор GAS повертає резервуар

CALL передасть певну кількість газу з резервуара та весь газ, що не належить резервуару

Багатовимірне ціноутворення на газ

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

Це принесе:

Кращу довгострокову економічну стійкість

Оптимізовану ефективність розподілу ресурсів

Детальніше дивіться за адресою: https://vitalik.eth.limo/general/2024/05/09/multidim.html

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

Довгострокове масштабування

Довгострокове масштабування в основному включає два напрямки: ZK-EVM і Blobs.

Об'єкти Blob

Щодо об'єктів Blob, ми плануємо продовжувати вдосконалювати PeerDAS, щоб досягти передачі даних приблизно 8 МБ/с.

Цей масштаб:

Достатній для задоволення власних потреб Ethereum

І не призначений для того, щоб стати "глобальним рівнем даних".

Наразі об'єкти Blob в основному використовуються для L2. У майбутньому планується, щоб самі дані блоків Ethereum записувалися безпосередньо в об'єкти Blob.

Мета цього полягає в тому, щоб дозволити людям перевіряти високо масштабовану мережу Ethereum без завантаження та повторного виконання всього ланцюга:

ZK-SNARKs усувають необхідність повторного виконання

PeerDAS + об'єкти Blob дозволяють перевіряти доступність даних без завантаження всіх даних

ZK-EVM

Наша мета для ZK-EVM полягає в поступовому збільшенні залежності мережі від нього.

2026: З'являться клієнти, що підтримують ZK-EVM, що дозволить вузлам брати участь в атестації за допомогою ZK-EVM. Однак вони ще не є достатньо безпечними, щоб дозволити всій мережі залежати від них у роботі. Проте, якщо близько 5% мережі використовуватиме їх, це буде прийнятно. (Якщо виникнуть проблеми з ZK-EVM, ви не будете покарані за зниження, але можете будувати на недійсних блоках, що призведе до втрати доходів.)

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

Післятехнічна зрілість: Ми впровадимо механізм обов'язкового підтвердження 3 з 5. Тобто блок повинен містити принаймні 3 докази з 5 різних систем доказів, щоб вважатися дійсним. До того часу ми очікуємо, що більшість вузлів будуть покладатися на докази ZK-EVM, за винятком вузлів, яким потрібно виконувати індексацію.

Довгостроково: Продовжуйте вдосконалювати ZK-EVM, щоб зробити його більш надійним і піддати суворішій формальній перевірці. Цей етап також може включати зміни на рівні віртуальної машини, наприклад, напрямок RISC-V.

Дивись: https://ethresear.ch/t/hyper-scaling-state-by-creating-new-forms-of-state/24052

[Посилання на оригінальну статтю]