Цей документ був натхненний нашою роботою над Специфікація консенсусу FOCIL 23, де ми зрозуміли, що протокол потребував більш обдуманого врахування обмежень ресурсів, оскільки певні деталі не були явно вказані в Дослідження Ethereum FOCIL 14.

Передумова

Перш ніж ми почнемо, ми припускаємо наступну установку, щоб встановити чіткий базовий рівень для наших міркувань:

• Налаштування ґрунтується на відгалуженні Electra. Також має сенс переглянути це на тлі EIP-7732 (ePBS) для порівняння
• Ми припускаємо створення та випуск блоків у режимі одиночного виконання, де пропозер не використовує MEV-Boost. Це перший ключовий компонент, щоб зробити все правильно, тоді як API будівельника - це вторинне увага
• Ми припускаємо, що налаштовано одиночного стейкера з типовими вимогами до обчислювальної потужності, пам'яті та пропускної здатності, які ви легко можете використовувати на ланцюжку Ethereum сьогодні

Актори

Перш ніж ми продовжимо, ми припускаємо, що наступні актори є частиною протоколу і аналізуємо їх відповідальність:

• Члени комітету зі списку включення (IL), які несуть відповідальність за обмеження наступного ініціатора слота набором транзакцій зі списку включень
• Пропонент, який відповідає за пропозицію наступного слоту
• Атестатори, які засвідчують наступний слот для голови ланцюга
• Вузли, які перевіряють та слідують за ланцюгом. Пропоненти та атестатори є частиною вузлів, які вклали Ether

Графік

Ми припускаємо наступний часовий графік, в якому Комітет з ІЛ, пропонент та співробітники виконують деякі чесні дії:

• Слот n-1, t=6: Комітет ІЛ публікує свої місцеві списки включення (ILs) по глобальній темі після ознайомлення з вмістом блоку n-1
• Слот n-1, t=9: Підтверджувачі та чесні перевіряючі вузли фіксують своє бачення місцевих ILs
• Слот n, t=0: Пропонент блоку для слоту n випускає блок B, який містить корисне навантаження, яке повинно задовольняти вимогу IL
• Slot n, t=4: Свідки для слоту n голосують за блок B, перевіряючи агрегацію IL, порівнюючи її зі своїми місцевими видами IL та підтверджуючи, чи блок B є "дійсним"
  • Ми перевантажуємо слово "дійсний", коли йдеться про блок, але воно може означати "імпортований", "канонічний" або щось інше. Див. відкрите запитання для подальшого уточнення.

Інтервал 1: Комітет IL публікує місцевий IL

Актор: Комітет зі списком включень

Члени комітету IL отримують список транзакцій IL від клієнта EL, використовуючи голову (виклик СL → EL), потім вони підписують місцевий IL (транзакції + підсумки) і публікують його в мережі gossip.

Розгляд ресурсів

• Отримання транзакцій IL з пам'яті EL → CPU/MEM
• Підписання списку включення → CPU
• Завантаження списку включень до мережі чуток → Пропускна здатність (Вивантаження)

Актор: вузли (включаючи атестатори)

Вузли, які слідкують за ланцюжком, завантажать IL, перевірять його на відсутність імпортування до EL та перешлють його іншим пірингам. Вузли також імпортують IL до вибору гілки та відстежують, які IL були побачені, використовуючи агрегатний кеш. Атестатори та вузли, які слідкують за ланцюжком, повинні мати однаковий погляд на ланцюжок.

Розгляд ресурсів

• Завантаження IL → Пропускна здатність (завантаження)
• Пересилання IL → Пропускна здатність (Відвантаження)
• Підтвердження IL для анти-DOS → CPU/MEM
• Кешування бачене та агреговані ILs → MEM

Актор: Заявник

Ініціатор наступного слота активно відстежує мережу пліток IL і збирає та аггреGates локальні IL, а потім на граничному рівні агрегації IL (інтервал #2) оферент оновлює процес побудови блоку списком транзакцій IL, які повинні бути включені до його блоку. Для цього потрібен виклик CL до EL.

Врахування ресурсів

• Успадковує ті самі витрати, що й вузли, що йдуть по ланцюжку

Випадок відправника пропозицій

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

Висновок

На основі вищезазначеного, ми можемо виявити можливі області, які потребують значних ресурсів та зосередитися на них:

• Вплив ЦП Комітету IL: отримання транзакції IL від EL & підпису: хоча тут є вимоги до ресурсів, це припускається як відносно недороге і не велике занепокоєння.
• Вплив на пропускну здатність вузлів: Вузли, які завантажують і вивантажують IL, можуть використовувати тонни пропускної здатності, особливо в дослідницьких публікаціях в даний час зазначено, що розмір списку включень є гнучким/необмеженим. Це створює потенційний ризик DOS, оскільки зловмисний член комітету IL може наповнити мережу великою кількістю транзакцій, навіть якщо вони недійсні. Вузли все одно будуть пліткувати про IL до того, як вони імпортують IL. Необхідно ретельно обміркувати заходи проти DoS.

Інтервал 2: Вузли блокують свій вигляд, пропонент імпортує IL транзакції

Актор: Пропонувач

Пропонент оновлює процес побудови блоку зі списком включення транзакцій. Це виклик CL → EL.

Ресурсні міркування

• Оновлення процесу побудови блоку зі списком транзакцій включення → CPU/MEM

Актор: Вузли (включаючи Атестанти)

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

Розгляд ресурсів

• Блокувати перегляд локального списку включення → Нічого

Висновок

• Вплив центрального процесора пропозиціонера: Імпорт інформації про транзакції в процес побудови блоку може нарушити процес побудови блоку, потенційно напружуючи ЦП виконавчого рівня клієнта під час симуляції транзакцій. Це може ускладнити абстракцію облікового запису, оскільки транзакції можуть анулювати одна одну. Це слід подальше проаналізувати.

Інтервал 3: Пропонент випускає блок

Актор: Пропонувач

Заявник отримує виконавчий навантаження від клієнта EL (CL → EL виклик) і розповсюджує його в мережі розговорів блоків бікону. Потім всі інші перевіряють блок.

Врахування ресурсів

• Отримання навантаження з EL-клієнта → CPU/MEM

Дійова особа: Вузли

Вузли отримують блок маяків і перевіряють його. Нові етапи верифікації включають перевірку конструкції списку включень aggreGate і перевірку того, чи задовольняє список включень функції оцінки, яка повинна бути виконана на CL. Перевірка умов ІЛ (чи можна їх пропустити через конфлікти чи ні) буде виконана на ЕЛ.

Розгляд ресурсів

• Перевірка того, що список включення виконується на CL → CPU
• Перевірка умов списку включення на EL → CPU

Висновок

Додаткові обов'язки для заявника, здається, не є значною проблемою. Нові етапи верифікації вузлів - перевірка та перевірка того, чи включений список відповідає задовільним умовам, - можуть внести додаткове навантаження на ЦП, але це, здається, не є серйозною проблемою.

Інтервал 4: Комітет підтверджувачів

Актор: Атестатор

Атестатор голосує за блок маяка, використовуючи правило вибору вилки LMD GHOST. Атестатори будуть голосувати лише за блок маяка, який задовольняє функцію оцінки списку включення, на основі спостережень з Інтервалу 1.

Врахування ресурсів

• Attesters голосують за блок, який задовольняє функцію оцінки списку включення → Без додаткових витрат

Висновок

Немає різниці від сьогодні.

Зведений розгляд ресурсів

Як видно з вище зазначеного, найбільш важливі проблеми, що стосуються ресурсів, пов'язані з завантаженням, завантаженням списку включення та можливістю спаму з точки зору вузла. Ще одна ключова проблема - це навантаження на вузли для перевірки та імпорту списку включення, а також потреба пропонента оновити свій процес побудови блоку для задоволення списку включення. Ці аспекти потребують ретельного вивчення та розробки, щоб забезпечити ефективність та безпеку.

Відкриті питання

На основі вищезазначеного ми намічаємо кілька відкритих питань, які впливатимуть на те, як буде написана специфікація:

1. Блок, який не задовольняє функцію оцінки: Як слід обробляти блок, який не проходить функцію оцінки включення в список, і які конструктивні розгляди враховувати для таких умов?
   • Чи воно має бути оброблено аналогічно краплями і не може бути імпортовано?
   • Чи не слід фільтрувати за вибором вілки?
   • Чи не повинно це бути дійсним у функції переходу стану?
2. Еквівокації щодо списку включень: Якщо член комітету зі списком включень надсилає різні версії списку включень різним вузлам, і вони всі передаються по мережі, які наслідки можуть мати такі дії? Як така поведінка може негативно вплинути на побудову наступного блоку відправника?
3. Пропонувальник вже будує на іншій голові: Якщо пропонувальник будує на іншій голові, ніж та, яку надіслала комісія по включенню до списку, і, отже, потребує зміни свого погляду на голову, які наслідки цієї дії для валідності блоку та поведінки пропонувальника?
4. Транзакції зі списком включень недійсні: локальні транзакції списку включень можуть бути визнані недійсними кількома способами. Навіть якщо ці транзакції визнані недійсними, блок все одно повинен задовольняти функції оцінки. Транзакції можуть бути визнані недійсними, оскільки кілька списків включення об'єднуються один з одним або з транзакціями в блоці. Окрім типової перевірки nonce, абстракція рахунку вводить нові способи визнання транзакцій недійсними, оскільки баланс може бути спустошений статичним nonce. Скільки додаткової симуляції потрібно виконати конструктору блоків через визнання транзакції недійсною і наскільки це впливає на його обчислення на процесорі, ще належить з'ясувати як для акторів MEV-Boost, так і для локальних розробників.
5. Спостереження ініціатора за підмережею комітету IL: Ініціатор стежить за підмережею комітету зі списку включень, щоб знати, коли вона готова до створення aggreGate. Тут є два підходи до проектування, і їх варто розглянути далі. Перший підхід - жадібний ініціатор, коли той, хто пропонує, чекає, поки t = 9, збирає якомога більше ІЛ, відправляє їх в ЕЛ, а ЕЛ оновлює свій блок. Другим підходом є селективний пропонент, коли пропонент чекає, поки у нього з'явиться достатній список включень, щоб задовольнити функцію eval, посилає їх до EL, і може зробити це менш ніж за t=9 секунд або навіть раніше. Питання полягає в тому, чи виправдовує другий підхід оптимізацію, щоб дозволити ініціатору випустити список включень aggreGate раніше. Другий підхід може добре підійти тільки для IL з власним виділеним лімітом газу.

Відмова від відповідальності:

1. Ця стаття перепечатана з [ Етрезер]. Усі авторські права належать оригінальному автору [теренс]. Якщо є зауваження до цього повторного видання, будь ласка, зв'яжіться з Gate Навчаннякоманда, і вони оперативно з цим впораються.
2. Відмова відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіат перекладених статей заборонено.