Тепер — масштабування.
Існують дві категорії: короткострокова та довгострокова.
Я вже писав про короткострокове масштабування в інших матеріалах. Основні моменти:
Списки доступу на рівні блоків (з’являться у Glamsterdam) дадуть змогу перевіряти блоки паралельно.
ePBS (з’явиться у Glamsterdam) має низку функцій, серед яких — можливість безпечно використовувати значну частину кожного слота (замість лише кількох сотень мілісекунд) для перевірки блоку.
Перепрайсинг газу забезпечує відповідність вартості газу фактичному часу виконання операцій і додатковим витратам. Ми також розпочинаємо впровадження багатовимірного газу, що гарантує різні обмеження для різних ресурсів. Обидва підходи дозволяють використовувати більшу частину слота для перевірки блоків без загрози виняткових випадків.
Для багатовимірного газу передбачена багатоступенева дорожня карта.
Спочатку, у Glamsterdam, ми розділяємо витрати на “створення стану” та “виконання і calldata”. На даний момент SSTORE, який змінює слот з ненульового на ненульовий, коштує 5 000 газу, а SSTORE, який змінює з нуля на ненульовий — 20 000. Один із перепрайсингів Glamsterdam суттєво збільшує цю додаткову суму (наприклад, до 60 000); наша мета — масштабувати виконання значно більше, ніж масштабувати розмір стану, що я вже пояснював раніше (
https://
ethresear.ch/t/hyper-scalin
g-state-by-creating-new-forms-of-state/24052
). Тобто у Glamsterdam SSTORE стягуватиме 5 000 “звичайного” газу та (наприклад) 55 000 “газу створення стану”.
Газ створення стану НЕ враховується до приблизно 16 мільйонного ліміту газу на транзакцію, тому створення великих контрактів (більших, ніж нинішні) стане можливим.
Одна з проблем: як це працює в EVM? Опкоди EVM (GAS, CALL…) розраховані на одну вимірність. Наш підхід такий: ми підтримуємо дві інваріанти:
Якщо ви робите виклик із X газом, цей виклик матиме X газу, який можна використати для “звичайного”, “створення стану” чи інших майбутніх вимірностей.
Якщо ви викликаєте опкод GAS, він показує, що у вас є Y газу, після виклику з X газом у вас залишається щонайменше Y-X газу, який можна використати для будь-якої функції після виклику для виконання постоперацій.
Ми створюємо N+1 “вимірність” газу, де за замовчуванням N=1 (створення стану), а додаткову вимірність називаємо “резервуар”. EVM за замовчуванням використовує “спеціалізовані” вимірності, якщо це можливо, інакше — резервуар. Наприклад, якщо у вас (100 000 газу створення стану, 100 000 резервуару), і ви тричі використовуєте SSTORE для створення нового стану, залишок газу змінюється так: (100 000, 100 000) -> (45 000, 95 000) -> (0, 80 000) -> (0, 20 000). GAS повертає резервуар. CALL передає вказану кількість газу з резервуару плюс весь не резервуарний газ.
У майбутньому ми перейдемо до багатовимірного ціноутворення, де різні вимірності матимуть різні плаваючі ціни газу. Це забезпечить довгострокову економічну стійкість і оптимальність (див.
https://
vitalik.eth.limo/general/2024/0
5/09/multidim.html
). Механізм резервуару вирішує проблему підвикликів, описану в кінці цієї статті.
Тепер, для довгострокового масштабування є дві складові: ZK-EVM і blobs.
Щодо blobs, план — продовжувати розвивати PeerDAS і довести його до фінального стану, де він зможе обробляти ~8 МБ/сек даних. Це достатньо для потреб Ethereum, без наміру стати глобальним шаром даних. Сьогодні blobs використовуються для L2. У майбутньому планується, щоб дані блоків Ethereum напряму переходили у blobs. Це необхідно, щоб хтось міг перевірити масштабований ланцюг Ethereum без особистого завантаження та повторного виконання: ZK-SNARKs усувають потребу у повторному виконанні, а PeerDAS на blobs дозволяє перевірити доступність без особистого завантаження.
Щодо ZK-EVM, мета — поступово підвищувати “комфорт” використання його на різних етапах:
Клієнти, що дозволяють брати участь як засвідчувач із ZK-EVM, з’являться у 2026 році. Вони ще не будуть достатньо безпечними для роботи всієї мережі, але, наприклад, 5% мережі можуть на них покладатися. (Якщо ZK-EVM зламається, вас не покарають, просто буде ризик побудувати на недійсному блоці і втратити доходи)
У 2027 році рекомендуватимемо, щоб більша частина мережі працювала на ZK-EVM, і водночас повністю зосередимося на формальній верифікації, максимізації безпеки тощо. Навіть 20% мережі на ZK-EVM дозволить суттєво підвищити ліміт газу, адже це дає дешевий шлях для solo stakers, яких і так менше 20%.
Коли будемо готові, перейдемо до обов’язкового доведення 3 з 5. Для того, щоб блок був дійсним, він має містити 3 з 5 типів доказів із різних систем. На цьому етапі очікується, що всі вузли (крім тих, які виконують індексацію) покладатимуться на докази ZK-EVM.
Постійно вдосконалювати ZK-EVM і зробити його максимально надійним, формально перевіреним тощо. Це також стосуватиметься змін у VM (наприклад, RISC-V).
Відмова від відповідальності:
- Ця стаття є передруком із [vitalikbuterin]. Всі авторські права належать оригінальному автору [vitalikbuterin]. Якщо є заперечення щодо передруку, звертайтеся до команди Gate Learn, і вони оперативно розглянуть питання.
- Відмова від відповідальності: думки та погляди, висловлені в цій статті, є виключно авторськими і не є інвестиційною порадою.
- Переклади статті іншими мовами виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження або плагіат перекладів заборонено.
