BAL (EIP-7928) у дискусіях про Glamsterdam часто називають «передумовою паралельного виконання». Це не означає негайного паралельного виконання всіх транзакцій, а підкреслює, що взаємозв’язки доступу до стану переходять від неявних припущень до чітко окреслених, перевірюваних обмежень. Стабільне планування можливе лише за чітко визначених обмежень.
Цей шар обмежень безпосередньо пов’язаний із цілями оновлення, описаними в Огляд оновлення Glamsterdam, і доповнює механізм ePBS (EIP-7732): ePBS визначає межі співпраці під час виробництва блоків, а BAL — межі виконання обмежень. Вплив Glamsterdam на DApp ілюструє, як зміни на рівні обмежень впливають на очікування продуктивності застосунків і частоту випуску оновлень.
Що таке BAL (EIP-7928)?
BAL — це списки доступу на рівні блоку (Block-Level Access Lists), які фіксують облікові записи та слоти сховища, до яких був доступ під час виконання блоку, а також можуть містити результати стану після виконання. BAL не замінює рушій виконання, а дає йому змогу раніше виявляти конфлікти та готувати дані.
Традиційне послідовне виконання забезпечує просту узгодженість, але швидко досягає меж ефективності під навантаженням. Щоб перейти до паралельного виконання, спочатку треба відповісти: «Які транзакції конфліктують між собою?» BAL цінний тим, що переносить виявлення конфліктів із часу виконання до планового етапу перед виконанням. Відповідно до дорожньої карти Ethereum.org і EIP-7928, BAL — ключова пропозиція для оновлення Glamsterdam.
Навіщо Ethereum потрібні списки доступу на рівні блоку?
Зі зростанням складності блоків, якщо залежності читання/запису стану виявляються лише під час виконання, клієнтам важко планувати виконання наперед. Навіть із потужним обладнанням ефективність страждає через відкати та повторне планування.
Списки доступу на рівні блоку зменшують ризик «виявлення конфліктів лише під час виконання». Чіткі обмеження дають змогу клієнтам підготувати дані, розподілити завдання та ізолювати конфлікти, мінімізуючи випадкові коливання продуктивності. Для індексуючих сервісів і архівних нод, що виконують масштабне читання стану, попереднє знання доступу також оптимізує планування I/O.
| Етап виконання |
Без попередніх обмежень |
З обмеженнями BAL |
| Час виявлення конфлікту |
Відкат під час виконання |
Прогноз до виконання |
| Підготовка даних |
Завантаження на льоту |
Попереднє групування |
| Стратегія планування |
На основі досвіду |
На основі правил |
Таблиця демонструє, що BAL змінює саме «доступність інформації», а не лише фінальну продуктивність.
Як BAL допомагає клієнтам виявляти конфлікти та оптимізувати планування?
Клієнти використовують список доступу для двох рішень: поділу транзакцій на «набори для паралелізації» та збереження «обов’язково послідовних шляхів». Навіть якщо повну паралельність забезпечити неможливо, можна оптимізувати малоконфліктні сегменти, поступово розширюючи область паралелізації.
З інженерної точки зору BAL не створює разового стрибка продуктивності, але підвищує передбачуваність виконання. Для команд експлуатації вузлів передбачуваність важливіша за короткострокові піки, оскільки вона впливає на SLA та реагування на інциденти. Динаміка конфліктів і відкатів на тестових мережах — ключові метрики для оцінки ефективності BAL.
| Етап планування |
Без попередніх обмежень |
З обмеженнями BAL |
| Підготовка до виконання |
Ґрунтується на оцінках |
Групування за списком доступу |
| Обробка конфліктів |
Часті відкати під час виконання |
Рання ізоляція конфліктів |
| Стабільність результатів |
Дуже мінлива |
Більш передбачувані результати |
| Моніторинг операцій |
Важко визначити пороги |
Можливість структурованих метрик |
Рис. 1. Ілюстрація механізму BAL: як списки доступу на рівні блоку підтримують виявлення конфліктів і планування паралельного виконання.
Який зв’язок між BAL і паралельним виконанням?
BAL — це не «замінник» паралельного виконання, а його «шар-передумова». Для паралельного виконання потрібні також реалізація на стороні клієнта, стратегії планування й керування станом. Без фундаментальних обмежень примусова паралелізація лише підвищує невизначеність.
BAL перетворює паралельне виконання з теорії на інженерну задачу. Він відповідає на запитання «чи виконані передумови?», а не «чи досягнуто піку продуктивності?». Навіть при впровадженні агресивних стратегій паралелізації обмеження BAL залишаються ключовими для керування конфліктами.
Що означає BAL для розробників і команд застосунків?
Розробникам слід уважно стежити за шаблонами доступу до стану. Проєкти з частими записами в один стан, складними міжконтрактними залежностями чи пакетною обробкою транзакцій можуть демонструвати нову поведінку виконання під цими обмеженнями. Важливо тестувати шляхи виконання до запуску, а не лише функціонал.
Продуктові команди мають оновити комунікацію щодо продуктивності. Покращення досвіду користувачів після оновлення можуть бути не лінійними, особливо в процесі адаптації екосистеми. Доцільно застосовувати поетапні метрики: перевіряти стабільність, частоту збоїв і перцентилі затримки, а не середні значення. Скидання метрик і поетапні релізи потрібно узгоджувати з фреймворком адаптації застосунку.
Які межі впровадження та потенційні виклики BAL?
Перший виклик — досягнення узгодженості між клієнтами. Різні клієнти можуть по-різному інтерпретувати списки доступу та стратегії планування, тому потрібна постійна конвергенція через тестові мережі й кросклієнтну регресію з фіксацією метрик.
Другий виклик — витрати на навчання для екосистеми. Якщо розробники ігнорують структури доступу до стану, після оновлення можливі відхилення у продуктивності; старі контракти могли бути написані без урахування дружніх до доступу шаблонів, що потребує інструментів і часу для міграції.
Третій виклик — оновлення систем моніторингу. Операційні команди потребують нових метрик щодо обмежень доступу, щоб визначати, чи проблеми пов’язані з підготовкою даних, конфліктами планування чи обмеженнями рушія виконання. Без оновленого моніторингу цінність механізму не розкриється повністю. Для Чек-листа підготовки ноди до оновлення журнали BAL і показники відкату через конфлікт мають входити до критеріїв приймання. У Порівнянні Glamsterdam із Dencun/Fusaka ці виклики — унікальні ризики структурних змін, які не вирішуються досвідом масштабування.
Підсумок
BAL (EIP-7928) робить порядок виконання прозорим, структурує виявлення конфліктів і переводить планування з реактивного у перевірюваний режим. Це не єдина умова успішного оновлення, але критично важливий компонент стабільного паралельного виконання і базовий механізм обмежень у шарі виконання Glamsterdam.
Поширені запитання
Чи є BAL (EIP-7928) самим паралельним виконанням?
Ні. BAL — це обмежувальний шар-передумова для паралельного виконання, що забезпечує основу для виявлення конфліктів. Паралельне виконання також залежить від реалізації клієнта та стратегій планування.
Чому BAL впливає на реальну продуктивність?
Оскільки взаємозв’язки доступу до стану стають явними заздалегідь, клієнти можуть раніше підготувати дані й згрупувати завдання, зменшуючи відкати через конфлікти та підвищуючи стабільність виконання.
Як розподіляються обов’язки між BAL та ePBS (EIP-7732)?
ePBS визначає межі співпраці під час виробництва блоків, а BAL — межі виконання обмежень. Кожен механізм працює на своєму рівні, і вони взаємодоповнюють один одного в Glamsterdam.
Як мають реагувати команди DApp на впровадження BAL?
Перегляньте шаблони доступу до стану та шляхи транзакцій із високою частотою, проведіть тестування поведінки виконання до та після оновлення, оновіть пороги моніторингу продуктивності й сповіщень, щоб не покладатися на застарілі припущення про виконання.
Чи гарантує BAL, що всі транзакції обробляються паралельно?
Ні. BAL надає інструменти для виявлення конфліктів і планування, але транзакції з високим рівнем конфліктів усе одно виконуються послідовно. Обсяг паралелізації залежить від шаблонів доступу, реалізації клієнта та навантаження мережі.
