Этот документ был мотивирован нашей работой над Спецификация FOCIL consensus 23, где мы поняли, что протокол требует более вдумчивого рассмотрения ограничений ресурсов, так как некоторые детали не были явно указаны в FOCIL Ethereum исследовательский пост 14.

Предварительное условие

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

• Настройка основана на жестком форке Electra. Также имеет смысл пересмотреть это на основе EIP-7732 (ePBS) для сравнения
• Мы предполагаем построение и выпуск отдельного блока, где предложитель не использует MEV-Boost. Это первый ключевой компонент, который нужно правильно настроить, в то время как Builder API является второстепенным вопросом.
• Мы предполагаем, что установка будет осуществлена одиночным стейкером с типичными требованиями к вычислительным мощностям, памяти и пропускной способности, которые вы можете легко использовать на сети Ethereum уже сегодня.

Актеры

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

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

График

Мы предполагаем следующую последовательность событий, в которой комитет IL, предложитель и аттестаторы выполняют некоторые честные действия:

• Слот n-1, t=6: Комитет по включению публикует свои локальные списки включения (ILs) по глобальной теме после изучения содержания блока n-1
• Ячейка n-1, t=9: Подтверждающие узлы и честные проверяющие узлы фиксируют свое представление о локальных ILs
• Слот n, t=0: Предлагатель блока для слота n выпускает блок B, который включает полезную нагрузку, которая должна удовлетворять требованию IL
• Slot n, t=4: Attesters for slot n vote on block B, verifying the IL aggregation by comparing it to their local IL views and confirming whether block B is “valid”
  • Мы перегружаем слово "действительный", когда говорим о блоке, но это может означать "импортируемый", "канонический" или что-то еще. См. открытый вопрос для дополнительного уточнения

Интервал 1: Комитет IL выпускает местный IL

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

Члены комитета IL извлекают список транзакций IL из клиента EL, учитывая заголовок (CL → EL вызов), затем они подписывают локальный IL (транзакции + сводки) и выпускают его в сеть сплетен.

Расчеты ресурсов

• Получение транзакций IL из пула памяти EL → CPU/MEM
• Подписание списка включения → ЦПУ
• Загрузка списка включения в сеть слухов → Пропускная способность (Загрузка)

Актер: Узлы (включая Attesters)

Узлы, следующие за цепочкой, загрузят IL, проверят его на предмет анти-DOS (пока не импортируют его в EL) и перешлют его другим узлам. Узлы также импортируют IL в выбор вилки и отслеживают, какие IL были видны, используя общий кэш. Аттестанты и узлы, следующие за цепочкой, должны иметь одинаковое представление о цепочке.

Ресурсные соображения

• Скачивание IL → Пропускная способность (загрузка)
• Перенаправление IL → Пропускная способность (Отправка)
• Проверка IL для анти-DOS → CPU/MEM
• Кэширование просмотренных и агрегированных ILs → MEM

Актер: Заявитель

Предлагающий для следующего слота активно мониторит сеть передачи слухов IL и собирает и агрегирует локальные IL, затем при срезе агрегации IL (интервал №2) предлагающий обновляет процесс создания блока списком транзакций IL, которые должны быть включены в его блок. Для этого требуется вызов CL на EL.

Рассмотрение ресурсов

• Наследует те же затраты, что и узлы, следующие за цепью

Proposer Edge Case

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

Заключение

Исходя из вышеизложенного, мы можем выявить потенциально ресурсоемкие области и сузить на них фокус:

• Влияние процессора комитета IL: восстановление транзакции IL из EL и подпись: хотя здесь есть требования к ресурсам, предполагается, что это относительно недорого и не является основной проблемой.
• Влияние узлов на пропускную способность: Узлы, загружающие и загружающие IL, могут использовать тонны пропускной способности, особенно в исследовательском сообщении в настоящее время говорится, что размер списка включения является гибким/неограниченным. Это создает потенциальный риск для DOS, так как злонамеренный член комитета IL может наводнить сеть большим количеством транзакций, даже если они недействительны. Узлы по-прежнему будут сплетничать о IL до того, как они импортируют IL. Меры по борьбе с DoS-атаками должны быть тщательно продуманы.

Интервал 2: Узлы блокируют свое представление, предлагающий импорт транзакций IL

Актер: Заявитель

Заявитель обновляет процесс построения блока с помощью списка включенных транзакций. Это вызов CL → EL.

Расчеты ресурсов

• Обновляет процесс построения блока с помощью списка включенных транзакций → CPU/MEM

Актер: Узлы (включая аттестанты)

Просмотр списка включения блокировки. Прекратить принятие локального списка включения с этой точки.

Рассмотрение ресурсов

• Представление локального списка включения заблокировано → Нет

Вывод

• Влияние ЦП предложителя: Импорт IL-транзакций в процесс построения блока может нарушить процесс построения блока, потенциально нагружая ЦП клиента слоя выполнения во время симуляции транзакции. Это может стать сложным в условиях абстрагирования учетной записи, так как транзакции могут аннулировать друг друга. Это следует дополнительно проанализировать.

Интервал 3: Предлагающая сторона выпускает блок

Актер: Заявитель

Заявитель извлекает выполнение нагрузки из клиента EL (CL → EL вызов) и выпускает ее в сеть рассылки блоков маяка. Затем все остальные проверяют блок.

Ресурсные соображения

• Получение полезной нагрузки от клиента EL → CPU/MEM

Актер: узлы

Узлы получают маяк блок и проверяют его. Новые шаги верификации включают проверку списка включения аггрегации и подтверждение того, удовлетворяет ли список включения функции оценки, которая должна быть завершена на CL. Проверка условий IL (можно ли их пропустить из-за конфликтов или нет) будет выполнена на EL.

Ресурсные соображения

• Проверка удовлетворения списка включения на CL → CPU
• Проверка условий списка включений на EL → CPU

Заключение

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

Интервал 4: Комитет аттестаторов

Actor: Attester

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

Ресурсные соображения

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

Вывод

Сегодня нет разницы.

Сводка по учету ресурсов

Как видно из вышесказанного, самые значительные проблемы, связанные с ресурсами, касаются загрузки, скачивания списка включений и потенциального спама с точки зрения узла. Еще одной ключевой проблемой является нагрузка на узлы при проверке и импорте списка включений, а также необходимость обновления процесса создания блоков предлагающего узла для удовлетворения списка включений. Эти аспекты требуют тщательного рассмотрения и разработки для обеспечения эффективности и безопасности.

Открытые вопросы

Исходя из вышеизложенного, мы выделяем несколько открытых вопросов, которые повлияют на то, как будет написана спецификация:

1. Блок, не удовлетворяющий функции оценки: Как следует обрабатывать блок, который не проходит функцию оценки списка включения, и какие конструктивные соображения играют роль в таких условиях?
   • Следует ли его обрабатывать аналогично блобам и нельзя импортировать?
   • Не должно ли оно фильтроваться выбором вилки?
   • Не должно ли это быть действительным в функции перехода состояния?
2. Двусмысленности списка включения: Если член комитета по списку включения отправляет разные версии списка включения на разные узлы, и все они распространяются по сети, каковы последствия этого действия? Как такое поведение может негативно повлиять на инициатора, создающего следующий блок?
3. Предлагающий уже строит на другой голове: Если предлагающий строит на другой голове, чем та, которую отправил комитет включения в список, и, следовательно, ему нужно изменить свою точку зрения на голову, каковы последствия этого действия для валидности блока и поведения предлагающего?
4. Invalidations of transactions in the inclusion list: Local inclusion list transactions can be invalidated in several ways. Even if these transactions are invalidated, the block should still be able to satisfy the evaluation function. Transactions may be invalidated as multiple inclusion lists merge with each other or with transactions in the block. In addition to the usual nonce verification, account abstraction introduces new ways for transactions to be invalidated, as the balance can be drained with a static nonce. The extent to which a block builder needs to perform additional simulation due to transaction invalidation and how much this affects its CPU computation remains to be seen for both MEV-Boost actors and local builders.
5. Наблюдение заявителя о подсети комитета включения: Заявитель контролирует подсеть списка включения, чтобы узнать, когда она будет готова к созданию агрегата. Здесь есть два подхода к проектированию, и стоит рассмотреть их более подробно. Первый подход - жадный заявитель, где заявитель ждет до t=9, собирает как можно больше IL, отправляет их в EL, и EL обновляет свой блок. Второй подход - селективный заявитель, где заявитель ждет, пока у него не будет достаточного списка включения для удовлетворения функции eval, отправляет их в EL и может сделать это менее чем за t=9с или даже раньше. Вопрос заключается в том, оправдывает ли второй подход оптимизацию для разрешения заявителю выпускать список включения агрегата раньше. Второй подход может быть подходящим только для IL с собственным предельным газом.

Оговорка:

1. Эта статья перепечатана из [ethresear]. Все авторские права принадлежат оригинальному автору [теренс]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь с Gate Learnкоманды, и они незамедлительно разберутся с этим.
2. Отказ от ответственности по обязательствам: мнения и взгляды, выраженные в этой статье, являются исключительно мнениями автора и не представляют собой инвестиционного совета.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.