Пересылка оригинального заголовка: Объяснение хардфорка Prague/Electra (Pectra)

представить

В нашей предыдущей статье мы подробно рассмотрели жизненный цикл валидаторов Ethereum, обсудив несколько аспектов, связанных с предстоящим хардфорком Electra. Теперь пришло время сосредоточиться на предстоящих изменениях в обновлениях Electra и Prague и подробно их объяснить.

История хардфорков Ethereum 2.0 «Proof-of-Stake» сложна. Она началась с добавления сигнального слоя к существующему выполнению слоя, запуская согласование Proof-of-Stake на сигнальном слое, сохраняя при этом Proof-of-Work на выполнении слоя (хардфорки Phase0 и Altair). PoS затем был полностью активирован на хардфорке Bellatrix (хотя выводы не были включены). Впоследствии хардфорк Capella позволил выводы, завершив жизненный цикл валидатора. Наиболее последний хардфорк, Deneb (часть обновления Dencun(Deneb/Cancun)), внес незначительные изменения в параметры сигнальной цепи, такие как временное окно для включения свидетельств, обработка добровольных выходов и предельный предел валидаторов. Основные изменения в Dencun касались выполнения слоя, вводя инновации, такие как транзакции блобов, газ блобов, KZG обязательства для блобов и устаревание операции SELFDESTRUCT.

Теперь хардфорк Prague/Electra представляет собой значительные обновления как исполнительного, так и консенсусного уровней. В качестве аудиторов проекта Lido, наше внимание в основном сосредоточено на изменениях в консенсусе и стейкинге в этом хардфорке. Однако мы не можем проигнорировать изменения на уровне исполнения в Prague, поскольку они включают критические функции, влияющие на сеть Ethereum и валидаторов. Давайте подробнее рассмотрим эти изменения.

Общий обзор уровня Pectra

Electra представляет множество функций для слоя маяка. Основные обновления включают в себя:

• Разрешение валидаторам иметь эффективный баланс от 32 до 2048 ETH (вместо фиксированных 32 ETH).
• Предоставление валидаторам возможности инициировать выходы с вторичными "снятием" учетными данными (без необходимости активного ключа валидатора).
• Изменение способа обработки депозитов Eth1 слоем маяка (отказ от анализа событий из контракта депозита).
• Добавление новой общей среды выполнения для обработки запросов от обычных контрактов Eth1 на уровне маяка (аналогично тому, как управлялись депозиты до Electra).

Между тем, Прага вносит изменения в исполнительный уровень, такие как:

• Новый предварительно скомпилированный контракт, поддерживающий кривую BLS12-381 для проверки доказательств zkSNARK (помимо популярной кривой BN254).
• Новый системный контракт для хранения и доступа к 8192 историческим хэшам блоков (полезно для безсостоятельных клиентов).
• Увеличение затрат газа на calldata для уменьшения размера блока и стимулирования проектов перейти к calldata-интенсивным операциям (например, rollups) к blobs, которые были представлены в Dencun.
• Поддержка большего числа блобов на каждом блоке Eth1, вместе с API для чтения этих чисел.
• Позволяя внешне управляемым аккаунтам (EOA) иметь свой собственный учетный код, значительно расширяется спектр возможностей, которыми обладают EOA, такие как выполнение мультиколлов или делегирование выполнения другим адресам.

Давайте сослаться на соответствующие предложения по улучшению Ethereum (EIP), чтобы облегчить дальнейшее обсуждение:

• EIP-7251: Увеличить MAX_EFFECTIVE_BALANCE
• EIP-7002: Выходы, которые можно вызвать из слоя выполнения
• EIP-6110: Поставка депозитов валидатора на цепи
• EIP-7549: Перемещение индекса комитета за пределы утверждения
• EIP-7685: Запросы общего назначения слоя выполнения
• EIP-2537: Прекомпиляция для операций на кривой BLS12-381
• EIP-2935: Сохранение исторических хэшей блоков в состоянии
• EIP-7623: Увеличение стоимости calldata
• EIP-7691: увеличена пропускная способность блоба
• EIP-7840: Добавить расписание blob в файлы конфигурации EL
• EIP-7702: Установить код учетной записи EOA

Некоторые из этих EIP в первую очередь касаются слоя консенсуса (бикон), в то время как другие относятся к слою исполнения. Некоторые охватывают оба слоя, так как определенные операции, такие как депозиты и выводы, требуют синхронизированных изменений в слоях консенсуса и исполнения. Из-за этой взаимозависимости разделение Электры и Праги невозможно, поэтому мы рассмотрим каждый EIP последовательно и укажем затронутый компонент Ethereum в каждом случае.

EIP-7251: Увеличение MAX_EFFECTIVE_BALANCE

Ссылка: EIP-7251

С момента первого хардфорка фазы 0, внедренного для подготовки Ethereum к Proof-of-Stake, и до Электра, максимальный эффективный баланс валидатора был зафиксирован на уровне 32 ETH. Активация валидатора требует как минимум spec.min_activation_balance (32 ETH). После активации валидатор начинает с этого максимального эффективного баланса, но может снизить свой эффективный баланс до spec.ejection_balance (16 ETH) и будет исключен при достижении этого порога. Эта "минимальная" логика остается неизменной в Электре, но теперь spec.max_effective_balance увеличился до 2048 ETH. В результате валидатор может внести депозит от 32 до 2048 ETH для активации, при этом все суммы в этом диапазоне вносят свой вклад в их эффективный баланс. Это изменение означает переход от "проверки-32ETH-стейк" к "proof-of-stake" :)

Этот переменный эффективный баланс теперь будет использован:

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

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

Другой эффект связан со снижениями. Все штрафы за снижение пропорциональны эффективному балансу валидатора:

• «Немедленные» и «отложенные» штрафы за снижение больше для валидаторов с более высокой ставкой.
• Штрафы за снижение для сниженных валидаторов, наряду с валидаторами с большими ставками, также больше, поскольку 'сниженная' доля общей ставки становится больше.
• Сообщавший о валидаторе с более высоким эффективным балансом заявитель получает большую долю урезанных ставок.

Electra также предлагает изменения в доли штрафов, определяя долю баланса валидаторов, которая будет сокращена и передана доносчику.

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

Ограничения на "перемены" валидатора также изменяются из-за увеличения эффективных балансов. В "пре-Электра" Ethereum валидаторы обычно имеют одинаковый эффективный баланс, и предел оттока определен как "не более 1/65536 (spec.churn_limit_quotient) от общей ставки может выйти за одну эпоху." Это создает "фиксированное" количество выходов валидаторов с одинаковой ставкой. Однако в "пост-Электра" возможен сценарий, когда выходят только несколько "китов", так как они представляют значительную часть общей ставки.

Еще одним соображением является ротация множества ключей валидатора на одном экземпляре валидатора. Крупные валидаторы в настоящее время вынуждены запускать тысячи ключей валидаторов на одном экземпляре, чтобы разместить большие ставки, разделяя их на 32 части ETH. С Electra такое поведение больше не является обязательным. С финансовой точки зрения это изменение не имеет большого значения, поскольку вознаграждения и вероятности линейно масштабируются в зависимости от суммы ставки. Таким образом, 100 валидаторов по 32 ETH эквивалентны одному валидатору с 3200 ETH. Кроме того, несколько активных ключей валидатора могут иметь одинаковые учетные данные для вывода Eth1, что позволяет выводить все вознаграждения на один адрес ETH и позволяет избежать затрат на газ, связанных с консолидацией вознаграждений. Однако управление большим количеством ключей влечет за собой дополнительные административные расходы.

Возможность consolидации балансов валидаторов добавляет еще один тип запроса на уровне исполнения. Ранее у нас были депозиты и выводы. Теперь появится еще один тип: запрос на consolидацию. Он объединит двух валидаторов в один. В этот запрос на операцию будут включены публичный ключ исходного валидатора и целевой публичный ключ, и он будет обрабатываться аналогично депозитам и выводам. Consolидации также будут иметь ожидаемые запросы и ограничения на оборот баланса, как и депозиты и выводы.

Подводя итоги:

• Для небольших соло-валидаторов Electra вводит возможность автоматически увеличивать свой эффективный баланс (и вознаграждения). Раньше любой излишек выше 32 ETH можно было только вывести, но после Electra этот излишек в конечном итоге внесет свой вклад в их эффективный баланс. Однако эффективный баланс может увеличиваться только кратно spec.effective_balance_increment (1 ETH), то есть увеличение происходит только после достижения следующей «границы в 1 ETH».
• Для крупных отдельных валидаторов Electra предлагает значительное упрощение управления, позволяя объединить несколько активных ключей валидатора в один. Хотя это и не меняет игру, управление единственным стейком 1x2048 безусловно проще, чем управление 64x32 стейками.
• Для провайдеров жидкой ставки, которые собирают небольшие ставки от пользователей и распределяют их между валидаторами, Electra добавляет большую гибкость в схемы распределения ставок, но в то же время требует серьезной перестройки учета валидаторов, который в настоящее время основан на фиксированном эффективном балансе в 32 ETH.

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

После Electra распределение долей значительно изменится. Большие валидаторы будут чаще участвовать в предложениях блоков и комитете синхронизации, получать большие штрафы в случае сокращения и иметь большее влияние на отложенные сокращения, очереди активации и очереди выхода. Хотя это может создать проблемы при агрегации данных, консенсус Ethereum обеспечивает минимальное количество нелинейных вычислений. Единственный нелинейный компонент использует sqrt(total_effective_balance) для расчета базового вознаграждения, которое применяется равномерно ко всем валидаторам. Это означает, что вознаграждения и сокращения валидаторов все равно можно оценить на базе "за 1 ETH" (или, более точно, на увеличение spec.effective_balance_increment, которое потенциально может измениться в будущем).

Для получения более подробной информации обратитесь к нашей предыдущей статье о поведении валидаторов.

EIP-7002: Выходы, инициируемые слоем выполнения

Ссылка: EIP-7002

У каждого валидатора в Ethereum есть две пары ключей: активный ключ и ключ для вывода. Активный общедоступный BLS-ключ служит основным идентификатором валидатора в цепочке маяка, и эту пару ключей используют для подписи блоков, аттестаций, штрафов, агрегатов синхронизационного комитета и (до этого EIP) добровольных выходов (для инициирования выхода валидатора из согласия после задержки). Вторая пара ключей («условия вывода») может быть либо другой парой BLS-ключей, либо обычным учетным записью Eth1 (закрытый ключ и адрес). Теперь для вывода на адрес ETH требуется сообщение о выводе, подписанное активным закрытым ключом BLS. Этот EIP меняет это.

На практике владельцы этих двух (активного и средств для вывода) пар ключей могут быть разными. Активный ключ валидатора отвечает за обязанности валидации: запуск серверов, поддержание их в рабочем состоянии и т. д., в то время как средства для вывода обычно контролируются владельцем доли, который получает вознаграждение и отвечает за средства. В настоящее время владелец доли, который контролирует только учетные данные для вывода, не может инициировать выход валидатора и может только вывести вознаграждение. Такая ситуация позволяет владельцу активного ключа валидатора эффективно удерживать баланс валидатора как «заложник». Валидаторы могут «предварительно подписать» сообщения о выходе и передать их владельцам доли, но это обходное решение не является идеальным. Более того, как вывод, так и выход в настоящее время требуют взаимодействия с валидатором слоя маяка с использованием специализированных API.

Оптимальным решением является разрешение владельцам долей выполнять операции по выходу и снятию средств с использованием обычного вызова смарт-контракта. Это включает стандартную проверку подписи Eth1, что существенно упрощает операции.

Этот EIP позволяет владельцам стейков вызывать выводы и выходы через стандартную транзакцию с их ETH-адреса на специальный смарт-контракт (аналогично существующему процессу депозита, который использует контракт "Депозит"). Процесс вывода (или выхода, если достаточно стейка удалено) работает следующим образом:

• Владелец доли отправляет запрос на вывод (запрос «in») контракту «Withdrawals» системы.
• Контракт взимает определенную комиссию (в ETH) для смягчения возможных атак гриферов и работает аналогично EIP-1559, с увеличением комиссий, когда очередь запросов загружена.
• Контракт сохраняет запрос на вывод/выход "in" в своем хранилище.
• Когда блок предлагается слою маяка, из хранилища извлекаются ожидающие запросы на вывод "in".
• Слой маяка обрабатывает запросы "in", взаимодействуя с балансом активного валидатора, планируя вывод валидатора и формируя запросы на вывод "out".
• Запросы на вывод "out" обрабатываются на уровне исполнения, и владелец стейка получает свои ETH.

Пока депозиты были операциями, запущенными в блоках Eth1, а затем «перемещенными» на слой Beacon с использованием очереди «ожидающих» депозитов, выводы следовали другой схеме. Они были запущены на слое Beacon (через CLI), а затем «перемещены» в блоки Eth1. Теперь обе схемы будут работать с использованием одной общей структуры (описанной ниже): создание запросов на уровне Eth1, обработка очереди «ожидающих» депозитов/выводов/консолидаций и обработка на уровне Beacon. Для «выводных» операций, таких как выводы, очередь вывода также обрабатывается, и результаты «распределяются» в блоках Eth1.

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

В результате данное EIP «завершает» операции стейкинга путем их полной миграции на уровень Eth1, значительно снижает риски безопасности инфраструктуры и повышает децентрализацию инициатив по соло-стейкингу.

EIP-6110: Поставка депозитов валидатора на цепочке

Ссылка: EIP-6110

В настоящее время депозиты реализуются через события в системе «Депозит» контракта (о чем подробно говорилось в предыдущей статье). Контракт принимает учетные данные ETH и валидатора, генерирует событие «Deposit()», и эти события позже анализируются и преобразуются в запросы на депозит на уровне маяка. У этой системы есть множество недостатков: она требует голосования за eth1data на уровне beacon chain, что добавляет значительные задержки. Кроме того, уровень маяка должен запрашивать уровень выполнения, что создает дополнительную сложность. Эти вопросы подробно обсуждаются в EIP. Более простой метод, устраняющий многие из этих проблем, включает в себя прямое включение запросов на депозит в блоках Eth1 в указанном месте. Этот механизм отражает процесс обработки вывода средств, описанный в предыдущем EIP.

Предлагаемые изменения в этом EIP обещают быть многообещающими. Теперь обработка eth1data может быть полностью удалена, устраняя необходимость в голосовании или длительных задержках между событиями на стороне Eth1 и включением депозита в биконный слой (в настоящее время около 12 часов). Также удаляется логика для снимков договоров о депозите. Этот EIP оптимизирует обработку депозитов и выравнивает ее с описанной выше схемой обработки вывода.

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

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

EIP-7685: Запросы общего назначения слоя выполнения

Reference: EIP-7685

Этот EIP, вероятно, следовало бы представить до трех предыдущих EIP, связанных с депозитом/выводом/консолидацией, поскольку он заложил им основу. Однако он представлен здесь, чтобы подчеркнуть растущую потребность в общих механизмах для последовательного перемещения специализированных данных между блоками (уровнями) Eth1 (исполнение) и Beacon (консенсус) цепочки. Этот EIP влияет на оба уровня, что делает обработку запросов, вызванных обычными транзакциями ETH, более эффективной. В настоящее время мы наблюдаем:

• События депозитов в блоках Eth1 "перемещаются" из блоков Eth1 в блоки Beacon для обработки.
• Запросы на вывод средств в блоках Beacon (с помощью CLI) «перемещаются» в блоки Eth1 для обработки.
• Необходимость обработки консолидаций валидаторов, которые также являются запросами Eth1->Beacon.

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

Этот EIP устанавливает рамки для по крайней мере трех основных случаев: депозиты, выводы и консолидации. Вот почему более ранние EIP ввели поля типа WITHDRAWAL_REQUEST_TYPE и DEPOSIT_REQUEST_TYPE, а теперь консолидации добавят еще одно, CONSOLIDATION_REQUEST_TYPE. Кроме того, этот EIP, вероятно, будет включать общие механизмы для обработки лимитов для таких запросов (константы ссылки: PENDING_DEPOSITS_LIMIT, PENDING_PARTIAL_WITHDRAWALS_LIMIT, PENDING_CONSOLIDATIONS_LIMIT).

Хотя подробные технические характеристики этой структуры пока не доступны, она обязательно будет включать основные типы запросов, механизмы целостности (например, хеширование и Merkle-изация запросов) и обработку очереди ожидания с ограничением скорости.

Этот EIP имеет архитектурное значение, позволяя Eth1 инициировать критические действия в слое Beacon через унифицированный каркас. Для конечных пользователей и проектов это означает, что все запросы, инициированные на уровне Eth1, будут доставлены и обработаны на уровне Beacon намного эффективнее.

EIP-2537: Предварительная компиляция для операций с кривой BLS12-381

Ссылка: EIP-2537

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

Математические операции над эллиптическими кривыми, такими как BLS12-381 (и ее аналог: BN-254), в настоящее время используются для двух основных целей:

• Подписи BLS, где используется специальная операция, называемая "парирование", для проверки этих подписей. Подписи BLS широко используются валидаторами, потому что они позволяют агрегировать несколько подписей в одну. Валидаторы полагаются на подписи BLS, основанные на кривой BLS12-381 (хотя их также можно реализовать с использованием любой кривой, поддерживающей парирование, такой как BN254).
• Проверка доказательств zkSNARK, где используются пары для проверки доказательств. Кроме того, обязательства KZG к блобам (введенные жестким форком Dencun) также используют пары для проверки обязательств блобов.

Если вы хотите проверить подпись BLS или доказательство zkSNARK в смарт-контракте, вы должны вычислить эти «пары», которые требуют больших вычислительных ресурсов. У Ethereum уже есть предварительно скомпилированный контракт для операций с кривой BN254 (EIP-196 и EIP-197). Тем не менее, кривая BLS12-381 (которая в настоящее время признана более безопасной и гораздо более широко используемой сегодня) не была реализована в виде прекомпиляции. Без такой предварительной компиляции реализация пар и других операций с кривыми в смарт-контрактах требует больших вычислений, как показано здесь, и потребляет огромное количество газа (от ~10^5 до 10^6 газа).

Этот EIP открывает дверь для множества потенциальных приложений, особенно в области обеспечения недорогой проверки BLS-подписей, основанных на кривой BLS12-381. Это позволяет реализовать пороговые схемы для различных целей. Как уже упоминалось ранее, валидаторы Ethereum уже используют BLS12-381-подписи. С помощью этого EIP стандартные смарт-контракты теперь могут выполнять эффективную проверку агрегированных подписей валидаторов. Это может упростить доказательства консенсуса и мосты между сетями, так как BLS-подписи широко используются в блокчейнах. Пороговые BLS-подписи по себе позволяют создавать множество эффективных пороговых схем для голосования, децентрализованной генерации случайных чисел, мультиподписей и т. д.

Дешевая проверка доказательства zkSNARK в свою очередь откроет множество приложений. Многие решения на основе zkSNARK в настоящее время сталкиваются с высокими затратами на проверку доказательства, что делает некоторые проекты практически невозможными. Этот EIP имеет потенциал изменить это.

EIP-2935: Сохранение исторических хэшей блоков в состоянии

Ссылка: EIP-2935

Этот EIP предлагает хранить 8192 (~27.3 часа) исторических хэшей блоков в состоянии блокчейна, обеспечивая расширенную историю для бессостоятельных клиентов (таких как rollups) и смарт-контрактов. Он предлагает сохранить текущее поведение операции BLOCKHASH, сохраняя ограничение в 256 блоках, в то время как вводится новый системный контракт, разработанный специально для хранения и извлечения исторических хэшей. Этот контракт выполняет операцию set(), когда уровень выполнения обрабатывает блок. Его метод get(), доступный любому, извлекает необходимый хэш блока из кольцевого буфера.

В настоящее время можно ссылаться на исторические хеши блоков в рамках EVM, но доступ ограничен 256 последними блоками (~50 минут). Однако есть случаи, когда доступ к более старым данным блоков является важным, например, для кросс-цепных приложений (которые требуют доказательства данных из предыдущих блоков) и для бессостоятельных клиентов, которым периодически нужен доступ к более ранним хешам блоков.

Этот EIP расширяет временной горизонт, доступный для rollups и кросс-цепных приложений, позволяя им получать доступ к историческим данным напрямую в EVM без необходимости собирать их внешне. В результате эти решения становятся более надежными и устойчивыми.

EIP-7623: Увеличение стоимости calldata

Ссылка: EIP-7623

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

Способность вводить большие доказуемые двоичные данные в блокчейн является необходимой для rollups. Обновление Dencun (Deneb-Cancun) внесло значительное новшество для таких случаев использования — blob-транзакции (EIP-4844). У blob-транзакций есть свои собственные «blob» комиссии за газ, и хотя их тела хранятся временно, их криптографические доказательства (KZG обязательства), вместе с их хэшами, интегрируются в слой консенсуса. Таким образом, blobs обеспечивают более эффективное решение для rollups по сравнению с использованием calldata для хранения данных.

Поощрение роллапов к переходу их данных к блобам можно достичь, используя подход "палка и морковка". Уменьшенные комиссии за газ для блобов выступают в качестве "морковки", в то время как этот EIP функционирует как "палка", увеличивая затраты на calldata, тем самым отговаривая от избыточного хранения данных в транзакциях. Этот EIP дополняет следующий EIP-7691 (Увеличение пропускной способности блоба), который увеличивает максимальное количество блобов, разрешенных на блок.

EIP-7691: Увеличение пропускной способности Blob

Ссылка: EIP-7691

В предыдущем жестком форке Dencun были введены блобы, и начальные значения максимального и целевого количества "блобов" на блок были консервативными оценками. Это было связано с тем, что сложно предсказать, как сеть p2p будет обрабатывать распространение больших двоичных объектов между узлами-валидаторами. Начальная конфигурация доказала свою работоспособность, и настал подходящий момент для тестирования новых значений. Ранее целевые/максимальные значения количества блобов на блок были установлены на 3/6. Сейчас эти ограничения увеличены до 6/9 соответственно.

При совмещении с предыдущим EIP-7623 (Увеличение стоимости calldata) это изменение еще более мотивирует rollups переносить свои данные из calldata в блобы. Продолжается поиск оптимальных параметров блобов.

EIP-7840: добавление расписания BLOB-объектов в файлы конфигурации EL

Ссылка: EIP-7840

Этот EIP предлагает добавить целевое и максимальное количество «пер-блочных» блобов (обсуждалось ранее) и значения baseFeeUpdateFraction в файлы конфигурации Ethereum Execution Layer (EL). Это также позволяет клиентам извлекать эти значения через API узла. Эта функция особенно полезна для задач, таких как оценка комиссий за газ для блобов.

EIP-7702: Установить код учетной записи EOA

Ссылка: EIP-7702

Это очень значительное EIP, которое принесет крупные изменения для пользователей Ethereum. Как мы знаем, EOA (Внешний Собственный Счет) не может иметь какого-либо кода, но может предоставить подпись транзакции (tx.origin). В отличие от этого, у смарт-контракта есть байт-код, но он не может предложить "свою" прямую подпись. Любое взаимодействие от пользователя, требующее дополнительной, автоматической и проверяемой логики, в настоящее время может быть достигнуто только путем вызова внешнего контракта для выполнения необходимых действий. Однако в таких случаях внешний контракт становится msg.sender для последующих контрактов, делая вызов "вызовом от контракта, а не пользователя".

Этот EIP вводит новый тип транзакций SET_CODE_TX_TYPE=0x04 (ранее у нас были старые транзакции 0x1, более новые транзакции 0x02 из обновлений Berlin и EIP-1559, а также транзакции 0x03 BLOB-объектов, введенные в Dencun). Этот новый тип транзакции позволяет установить код для счета EOA. По сути, это позволяет EOA выполнять внешний код «в контексте своей собственной учетной записи EOA». С внешней точки зрения это выглядит так, как будто во время транзакции EOA «заимствует» код из внешнего контракта и выполняет его. Технически это стало возможным благодаря добавлению специальных кортежей данных авторизации в «кодовое» хранилище адреса EOA (до этого EIP это хранилище «кода» всегда было пустым для EOA).

В настоящее время в этом EIP предлагается включить новый тип транзакции 0x04, включающий в себя массив:

authorization_list = [[chain_id, address, nonce, y_parity, r, s], …]

где каждый элемент позволяет учетной записи использовать код из указанного адреса (из последнего допустимого элемента авторизации). Обработка такой транзакции устанавливает код данного EOA в специальное значение 0xef0100 || адрес (23 байта), где адрес указывает на контракт с желаемым кодом для выполнения, || обозначает конкатенацию, а 0xef0100 представляет собой специальное магическое значение, которое обычные смарт-контракты не могут содержать (в соответствии с EIP-3541). Это магическое значение гарантирует, что этот EOA не может быть рассмотрен как обычный контракт или к нему могут быть сделаны вызовы в таком качестве.

Когда этот EOA инициирует транзакцию, указанный адрес будет использоваться для вызова соответствующего кода в контексте этого EOA. Хотя полные детали реализации этого EIP пока неизвестны, но это определенно принесет значительные изменения.

Одним из основных последствий является возможность делать мультиколлы напрямую из EOA. Мультиколлы - это текущий тренд в DeFi, многие протоколы предлагают эту функцию как мощный инструмент (примеры включают Uniswap V4, Balancer V3 или Euler V2). С помощью этого EIP мультиколлы теперь могут быть сделаны напрямую из EOAs.

Например, эта новая функция решает общую проблему в DeFi: неэффективность approve() + anything(), требующую двух отдельных транзакций. Этот EIP позволяет использовать общую логику «предварительного подтверждения», что позволяет выполнять действия, такие как approve(X) + deposit(X), в одной транзакции.

Другим преимуществом, предоставленным возможностью делегировать выполнение транзакций "от имени" EOA, является концепция спонсорства. Спонсорство часто обсуждается и является очень желанными функциями для привлечения новых пользователей в Ethereum.

Программируемая логика, связанная с EOA, открывает множество возможностей, таких как внедрение ограничений безопасности, установка лимитов расходов, обеспечение требований KYC и многое другое.

Естественно, это изменение также вызывает множество вопросов дизайна. Одной из проблем является использование chain_id, который определяет, может ли одна и та же подпись быть действительной на нескольких сетях на основе ее включения или исключения из подписи. Другим сложным вопросом является использование адреса целевого кода по сравнению с встраиванием фактического байткода. Оба подхода имеют уникальные особенности и ограничения. Кроме того, использование nonce играет ключевую роль в определении, являются ли разрешения «многоразовыми» или «одноразовыми». Эти элементы влияют на функциональные возможности и вопросы безопасности, включая такие аспекты, как массовая аннулирование подписей и удобство использования. Виталик поднял эти вопросы в обсуждении (здесь), которые стоит дальше изучить.

Важно отметить, что эти изменения повлияют на один из механизмов безопасности Ethereum, tx.origin. Для получения дополнительной информации об осуществлении этого EIP требуются дополнительные сведения, но похоже, что поведение require(tx.origin == msg.sender) изменится. Эта проверка была наиболее надежным способом обеспечения того, что msg.sender является EOA, а не контрактом. Другие методы, такие как проверка EXTCODESIZE (для проверки, является ли он контрактом), часто завершаются неудачно и могут быть обойдены (например, путем вызова из конструктора или развертывания кода по заранее определенному адресу после транзакции). Эти проверки использовались для предотвращения рекурсии и атак flashloan, но они далеки от идеала, так как они также мешают интеграциям с внешними протоколами. После этого EIP даже надежная проверка require(tx.origin == msg.sender) кажется устаревшей. Протоколы должны адаптироваться, удаляя такие проверки, поскольку различие между "EOA" и "контрактом" больше не будет применяться — теперь у каждого адреса потенциально может быть связанный код.

Традиционное разделение EOA и смарт-контрактов продолжает размываться. Этот EIP приближает Ethereum к дизайнам, подобным TON, где каждая учетная запись по сути является исполняемым кодом. Это развитие естественно, поскольку взаимодействия с протоколами становятся все более сложными, что делает необходимым использование программной логики для улучшения UX для конечных пользователей.

Заключение

Обновление Прага/Электра (Пектра) запланировано на март 2025 года. Самые значительные запланированные изменения включают:

• эффективный стейк вариативных валидаторов, до 2048 ETH, что значительно изменит распределение стейков, графики валидаторов и упростит управление для крупных провайдеров стейкинга за счет консолидации меньших стейков
• улучшенное взаимодействие слоя выполнения согласования, оптимизация обмена данными между блоками выполнения Eth1 и блоками цепочки Beacon. Это значительно упростит депозиты, активации, выводы и выходы, ускоряя эти процессы и заложив основу для дальнейшего взаимодействия между слоями согласования и выполнения
• поддержка более дешевой подписи BLS и проверки zkSNARK напрямую в смарт-контрактах через новый предварительный расчет BLS12-381, дружественный для пар
• продолжая поощрять rollups к принятию blob-транзакций вместо calldata путем увеличения порогов blob-транзакций и повышения стоимости calldata
• предоставление EOA возможности действовать в качестве программируемых учетных записей, наделяя их такими функциями, как множественные вызовы, спонсорство и другие расширенные функции;

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

Отказ:

1. Эта статья воспроизведена с [ TechFlow]. Перешлите оригинальное название: Объяснение хардфорка Prague/Electra (Pectra). Авторские права принадлежат автору оригинала [MixBytes (Миксбайты)]. Если у вас есть возражение против перепечатки, пожалуйста, свяжитесьКоманда Gate Learn, и команда обработает это как можно скорее в соответствии с соответствующими процедурами.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, представляют только личные взгляды автора и не являются инвестиционным советом.
3. Другие языковые версии статьи переводятся командой gate Learn. Если не указано иное, переведенная статья не может быть скопирована, распространена или подвергнута плагиату.