Хардфорк Pectra планируется запустить в марте 2025 года. Обновление Pectra включает в себя 11 технических протоколов (EIP), а именно:
EIP-2537: Предварительная компиляция операций на кривой BLS12-381
EIP-2935: Сохранение исторических хэшей блоков в состоянии
EIP-6110: Предоставление депозитов валидаторов на цепи
EIP-7002: Исполнительный уровень вызывает выход
EIP-7251: Добавлено значение MAX_EFFECTIVE_BALANCE
EIP-7549: Индекс комитета перемещен из проверки
EIP-7623: Увеличение расходов на передачу данных
EIP-7685: Запрос общего уровня исполнения
EIP-7691: увеличение пропускной способности BLOB-объектов
EIP-7702: установка кода учетной записи EOA
EIP-7840: добавление плана BLOB-объектов в файл конфигурации EL
Технические протоколы, связанные с залогом
EIP-6110: Предварительная компиляция операций на кривой BLS12-381
Упростить процесс участия пользователей в залоге, существенно сократив время ожидания.
Пользователь участвует в залоге, внедряя 32 ETH на уровне исполнения и регистрируясь в журнале событий (Event Log); затем уровень консенсуса анализирует журнал событий, чтобы определить, участвовал ли кто-то в залоге, после чего пользователь, участвующий в залоге, становится валидатором.
Однако сначала участники проверки на уровне согласия должны определить, для какого момента времени они достигли согласия, в противном случае они обнаружат, что некоторые проверяющие видят 5 новых внесенных вкладов, а другие видят только 3, поэтому участники проверки на уровне согласия должны проголосовать за блок (eth1data) на уровне выполнения, чтобы убедиться, что все видят одинаковый блок уровня выполнения.
Однако при первоначальном проектировании для предотвращения возникновения серьезных ошибок на уровне исполнения, приводящих к разделению цепи, исполнительный блок (eth1data), на который ссылаются, будет представлять собой блок исполнения, сформированный около 10 часов назад, чтобы обеспечить достаточное время для реакции и решения проблем разработчиками консенсусного уровня в случае серьезных ошибок. Однако это также означает, что участникам стейкинга придется ждать более 10 часов, чтобы их участие вступило в силу.
!
△ CL в блоке 10900000 eth1data, в котором записан хэш блока, являющегося блоком исполнения 21683339, появившийся за 10 часов до него.
После выполнения технического протокола EIP-6110 данные о залоге пользователя на контракте непосредственно станут частью исполнительного уровня, а поскольку блоки уровня согласия сами по себе будут включать блоки исполнения (но не eth1data), то валидаторам уровня согласия уже не придется задумываться о том, "одинаковы ли исполнительные блоки, на которые они ссылаются", - им всего лишь нужно, чтобы более двух третей валидаторов уровня согласия проголосовали за подтверждение блока уровня согласия, и все согласуются на том, что они видят один и тот же блок исполнения. Следовательно, после участия пользователя в залоге, это начнет действовать через приблизительно 13 минут после завершения обработки блока исполнения, и клиент уровня согласия также сможет избавиться от сложной логики, связанной с обработкой данных о залоге.
EIP-7002: Сохранение хэша предыдущего блока в состоянии
Может использоваться для улучшения процесса вывода стейкинга или обеспечения займами и доходов, снижая риски валидаторов.
Для участия в стейкинге вам понадобятся два ключа: ключ валидатора и удостоверение о снятии средств.
Ключ проверки используется для проверки работы валидатора, удостоверение вывода используется для проверки выхода валидатора из ставки, гарантийный депозит и доход будут перечислены на адрес, из которого можно вывести, кроме того, в настоящее время выход из ставки обязательно должен выполняться с помощью ключа проверки.
Если потерять ключ валидатора, то невозможно будет выполнять работу валидатора и выйти из залога; если потерять удостоверение о снятии, то будет потеряна вся залоговая сумма и доход. Кроме того, некоторые пользователи могут использовать услуги сторонних сторон, таких как Lido, для залога; при использовании этих платформ пользователи должны самостоятельно хранить удостоверение о снятии, в то время как ключ валидатора хранится и выполняется работа валидатора по поручению поставщика услуг.
По протоколу EIP-7002 пользователь может вызвать 'контракт снятия' (развернутый на 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) для выхода из залога (Exit) или частичного снятия залога и дохода (Partial Withdrawal), что может снизить связанные с использованием сторонних услуг по залогу возможные риски. Если пользователь участвует в залоге самостоятельно, но потерял Ключ валидатора, он также может выйти из залога.
Параметры запроса включают в себя validator_pubkey и amount : validator_pubkey - это открытый ключ валидатора, amount - это сумма для снятия.
Учетные данные для вывода средств, которые инициировали запрос, должны быть учетными данными для вывода средств валидатора_pubkey валидатора.
При вызове контракта Withdraw для инициирования запроса необходимо приложить плату за газ (ETH). Плата за газ вычисляется на основе текущего количества запросов на вывод, поэтому если количество запросов большое, плата за газ увеличится.
Если учетные данные на вывод являются контрактом, то можно сначала перейти к контракту на вывод, получить текущую сумму комиссии, а затем отправить запрос и приложить комиссию; но если учетные данные на вывод являются учетной записью EOA, то нельзя получить точную комиссию, можно только заранее провести симуляцию вне цепи и заплатить избыточную комиссию (не вернется), чтобы гарантировать успешное выполнение запроса.
Примечание: если ваш Сертификат Вывода все еще в формате открытого ключа BLS, не забудьте сначала переключиться и преобразовать его в формат адреса EL.
EIP-7251: Добавьте MAX_EFFECTIVE_BALANCE
Возможность значительного увеличения верхнего предела суммы залога для уменьшения количества валидаторов, при этом валидаторы, не достигшие предела, могут автоматически получать доход от залога.
Пользователь, желающий стать валидатором, должен предоставить MAX_EFFECTIVE_BALANCE ETH (в настоящее время MAX_EFFECTIVE_BALANCE составляет 32 ETH). Если у пользователя есть 1024 ETH для ставки, он может участвовать в ставке 32 раза, запустить 32 валидатора и запустить 32 узла валидатора. Активное участие пользователей в ставках привело к тому, что в настоящее время уже есть около 1 миллиона валидаторов и их количество продолжает расти. Это не только увеличивает объем данных состояния на уровне согласия, но также значительно увеличивает нагрузку на уровне p2p сети согласия, поскольку каждый слот (каждые 12 секунд) требует непрерывной передачи и агрегации подписей нескольких десятков тысяч валидаторов в сети p2p.
После внедрения технического протокола EIP-7251 минимальный лимит стейкинга (MIN_ACTIVATION_BALANCE) по-прежнему составляет 32 ETH, но верхний предел (MAX_EFFECTIVE_BALANCE) будет значительно увеличен до 2048 ETH, вы можете стейкать любое количество ETH в пределах 32 ~ 2048, вы можете получать вознаграждения за стейкинг, больше не нужно регулярно выводить доход и продолжать стейкать новые ETH после накопления 32 ETH.
В настоящее время существующим валидаторам не нужно сначала выходить из стейкинга, а затем объединяться и снова присоединяться к стейкингу, но они могут напрямую использовать новый «контракт для слияния депозитов» (развернутый в 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) на уровне исполнения, а Кринденциал вывода средств валидатора вызовет контракт, чтобы инициировать запрос на слияние депозита.
Параметры запроса на объединение депозитов включают source_pubkey и target_pubkey: оба ключа - это ключи валидатора, исходный валидатор будет объединен с целевым валидатором.
Учетные данные для вывода, которые инициируют запрос, должны быть учетными данными для вывода средств исходного верификатора.
При вызове контракта объединения депозитов для инициирования запроса необходимо приложить комиссию (ETH), стоимость комиссии будет рассчитываться в зависимости от текущего количества запросов, и если запросов много, комиссия будет увеличиваться.
Если учетные данные для вывода пользователя являются контрактом, то можно сначала вызвать контракт по слиянию депозита, чтобы получить текущую сумму комиссии, а затем отправить запрос и приложить комиссию; но если учетные данные для вывода являются учетной записью EOA, то невозможно точно получить комиссию, можно только заранее смоделировать цепочку и оплатить избыточную комиссию (не возвращается), чтобы гарантировать успешное выполнение запроса.
Примечание: Если ваши учетные данные для вывода средств имеют формат открытого ключа BLS, вам необходимо сначала переключить его на формат адреса EL.
EIP-7685: Общий запрос уровня выполнения
Создайте формальный информационный конвейер EL-> CL, чтобы пользователи и сервисы стейкинга могли отправлять запросы непосредственно на уровень консенсуса.
Пользователи могут отправлять запросы непосредственно с уровня исполнения на уровень консенсуса, а сервисы стейкинга (такие как Lido) могут работать более децентрализованно. В качестве примера можно привести запрос EIP-7002 на вывод средств из стейкинга и запрос EIP-7251 на объединение депозитов. Без этого технического протокола пользователям Lido пришлось бы доверять поставщику услуг узлов Lido для выполнения вывода из стейкинга или слияния депозита на уровне консенсуса. С помощью этого технического протокола пользователи Lido могут отправлять запросы непосредственно через контракт управления на уровне исполнения.
Эти запросы будут отличаться типом запроса, инициируемым различными контрактами, и, наконец, все эти запросы будут записаны в блоки памяти уровня исполнения, так что уровень согласия может непосредственно получить эту информацию через блоки памяти уровня исполнения, необходимости в отдельной логике разбора.
EIP-6110, EIP-7002 и EIP-7251 все основаны на стандарте, определенном в EIP-7685, для разработки запросов:
EIP-6110 Добавление запроса на стейкинг: Тип запроса=0, через депозитный контракт
Технический протокол для улучшения пользовательского опыта
EIP-7702: установка кода учетной записи EOA
Позволяет счет EOA произвольно превращаться в счет контракта, существенно улучшая опыт использования.
У учетной записи EOA есть некоторые недостатки в использовании, включая:
Необходимо записывать и хранить приватный ключ или мнемоническую фразу, а порог регистрации нового пользователя высок.
Счет EOA может выполнить только одну операцию за одну транзакцию, например, если вы хотите обменять USDT на ETH на Uniswap, вам сначала нужно отправить транзакцию для утверждения USDT, а затем отправить другую транзакцию для обмена.
Контроль разрешений, которые не могут быть уточнены, например, передача некоторых операций по счету третьей стороне для работы от имени пользователя, пользователь должен лично обрабатывать каждый заказ и подписывать транзакцию для каждой операции.
Механизма восстановления нет, поэтому вы можете хранить приватный ключ или мнемоническую фразу только самостоятельно, и если вы его потеряете, вы никогда не сможете вернуть активы аккаунта.
Если это учетная запись смарт-контракта (например, Safe), то вышеперечисленные проблемы можно решить:
Пользователи могут использовать закрытый ключ в чипе безопасности мобильного телефона (или компьютера) для подписи авторизации, без необходимости запоминать какой-либо закрытый ключ или мнемонические слова, или использовать электронную почту для подписи авторизации, или другие различные методы авторизации.
Можно объединить несколько операций в одну транзакцию, чтобы выполнить их одновременно. Сложные операции DApp теперь можно выполнить с одним разрешением на подпись и одной транзакцией.
Можно иметь очень детальное управление правами, пользователи могут предоставлять разрешения третьим лицам для управления своими учетными записями, но в то же время указывать "с какими контрактами можно взаимодействовать", "какие операции нельзя выполнять", "на перемещение активов можно использовать не более столько-то активов" или "количество операций в неделю не должно превышать столько-то раз" и т. д.
Вы можете добавить механизм восстановления, а также вы можете перенести активы аккаунта на новый аккаунт через механизм восстановления при утере мнемонической фразы или мобильного телефона или электронной почты.
Предложение EIP-7702 дает учетным записям EOA возможность стать контрактными учетными записями. Пользователь подписывает преобразованное сообщение закрытым ключом EOA, который включает в себя «Идентификатор сети», «Измененный адрес контракта» и «Значение одноразового номера EOA»:
Chain ID：используется для предотвращения повторного использования подписи цепи A в цепи B. Однако если Chain ID установлено на 0, это означает, что вы хотите превратиться в каждую цепь.
Адрес контракта, в который вы хотите преобразоваться: если вы укажете адрес контракта Safe, то ваш счет EOA будет преобразован в контракт Safe; если вы укажете пустой адрес (адрес (0)), это означает отмену преобразования и возврат к обычному счету EOA.
Значение Nonce для EOA: используется для предотвращения повторного воспроизведения подписи. Если значение Nonce увеличивается, то оригинальная подпись станет недействительной.
Однако следует обратить внимание на несколько моментов:
Приватный ключ EOA можно продолжать использовать так же.
Даже если учетная запись EOA пользователя станет контрактом, он все равно может продолжать использовать ее в исходном виде. Например, если ваша учетная запись EOA станет контрактом Safe, то вы сможете использовать интерфейс Safe, проходить процесс Safe-сделок и продолжать подписывать сделки с помощью исходного кошелька EOA. Однако это также означает, что безопасность учетной записи все еще ограничена этим приватным ключом.
Это остается безопасностью закрытого ключа EOA
Даже если учетная запись пользователя EOA станет многоадресной, пока у него не потеряны приватные ключи EOA, безопасность его учетной записи всегда будет зависеть от безопасности приватных ключей EOA: он все равно должен хорошо хранить свои приватные ключи или мнемонические слова, его учетная запись не станет такой же безопасной, как мультиподписная.
Хранилище учетной записи EOA не отформатировано
Когда учетная запись EOA превращается в контракт и записывает данные в свое хранилище, эти данные, записанные в хранилище, не форматируются из-за того, что учетная запись EOA превратилась в другой контракт или отменила свое преобразование, если явно не выполнено действие удаления данных, поэтому разработчики должны обратить внимание на то, что хранилище не должно читать данные, оставленные предыдущими преобразованными контрактами, можно ознакомиться с ERC-7201.
Процесс EIP-7702 не включает инициализацию
Обычно у контрактов требуется инициализационный этап, во время развертывания контракта синхронно записывается информация о владельце контракта (например, открытый ключ или адрес), чтобы избежать украденного развертывания (Frontrun), что приведет к потере владения контрактом. Обычно это выполняется заводским контрактом, развертывающим контракт, но потому что EIP-7702 непосредственно изменяет контракт, а не развертывающий контракт на EOA, злоумышленник может украсть подпись пользователя и отправить транзакцию на цепочку, чтобы изменить контракт на контролируемый злоумышленником, поэтому разработчики должны обратить внимание на EIP-7702. Возможные методы защиты, такие как проверка подписи учетной записи EOA в инициализирующей функции, таким образом, даже если произойдет украденное развертывание, злоумышленнику не удастся сгенерировать подпись этой учетной записи EOA для завершения инициализации.
Кошелек должен проверить запрос на изменение
Кошелек должен надлежащим образом защищать пользователей, блокируя запросы от зловредных веб-сайтов DApp на подписание транзакции на изменение личности и предупреждать пользователей об этом. В противном случае, если пользователь подпишет зловредную транзакцию на изменение личности, это приведет к мгновенному переходу активов. Вот некоторые примеры реализации контрактов на изменение личности:
Модифицированная учетная запись Safe Ithaca
Учетная запись Ithaca
Протокол технологии DApp
EIP-2537: Прекомпилятор операций с кривыми BLS12-381
Уменьшите затраты и сделайте его более осуществимым для приложений доказательства с нулевым разглашением на основе кривых BLS.
В EIP-2537 добавлено несколько новых контрактов предварительной компиляции для обеспечения недорогих операций с кривыми BLS, что делает более осуществимой разработку приложений доказательства с нулевым разглашением на основе кривых BLS.
EIP-2935: Сохранение исторических хэшей блоков в состоянии
Это позволяет разработчикам или узлам считывать хэш прошлых блоков памяти непосредственно из хранилища системного контракта.
Если разработчику необходимо доказать содержимое предыдущего блока памяти, например, если мошеннический вызов Optimismtic Rollup хочет доказать, что транзакция существует в 1000 предыдущих блоках памяти, он не может сказать об этом напрямую.
«Поверьте мне, 1000 блоков памяти действительно существовали раньше», он должен был дать показания, но прямых доказательств того, что «1000 предыдущих блоков памяти содержали это содержимое», не было, поэтому он должен был доказать транзакцию в «цепочке» блоков памяти, блок за блоком, пока она не достигнет 1000 предыдущих блоков, а затем доказать, что транзакция существовала в блоке.
!
△ Каждый блок указывает на родительский блок, поэтому вы можете доказать наличие любого блока в истории.
Предположим, что в настоящее время это блок памяти с номером 10000, и вызов мошенничества хочет предоставить доказательство того, что блок памяти с номером 9000 имеет транзакцию X, претендент должен начать с хэша блока памяти 10000, сначала доказать хэш родительского блока памяти 9999, соединенного с блоком памяти 10000, а затем доказать блок памяти 9998... До блока памяти 9000 содержимое блока памяти 9000 предполагается содержать транзакцию X.
После EIP-2935 будет существовать системный контракт (развертывается на 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC), который будет хранить в своем хранилище до 8192 хешей предыдущих блоков памяти. Каждый раз, когда появляется новый блок памяти, этот системный контракт автоматически обновляется, записывая хеш предыдущего блока памяти в системный контракт (перезаписывает хеши 8192 предыдущих блоков памяти).
Таким образом, в примере с мошенническим вызовом Optimismtic Rollup, претенденту не нужно возвращаться к предыдущему блоку памяти, чтобы доказать по одному блоку памяти за раз, но он может напрямую доказать, что в текущем состоянии цепочки блока памяти 10000 значение определенного хранилища (соответствующего блоку памяти 9000) системного контракта является хеш-значением блока памяти 9000. Если диапазон превышает 8192, например, блок памяти 1000, то максимум еще один шаг для доказательства хеш-значения блока памяти 1808 (= 10000 - 8192), а затем доказательства хеш-значения блока памяти 1000 в системном контракте в текущем состоянии цепочки блока памяти 1808.
Это также прокладывает путь для будущего клиента без сохранения состояния: в будущем легким узлам больше не нужно будет хранить заголовки блоков всех исторических блоков памяти, а нужно будет только попросить кого-то другого предоставить доказательство с помощью метода доказательства из предыдущего примера с вызовом мошенничества, когда необходимо использовать хэш блока памяти в истории или содержимое блока памяти.
EIP-7623: Увеличение стоимости calldata
Увеличьте затраты на публикацию данных с помощью calldata, чтобы освободить достаточно безопасного пространства для увеличения лимита газа блока и ограничения BLOB-объектов.
В связи с растущим спросом на выпуск данных для накопительных пакетов, после введения BLOB-объектов в EIP-4844, позволяющих накопительным пакетам размещать данные очень дешевым способом, увеличение количества BLOB-объектов стало обновлением, которого сообщество с нетерпением ждет.
!
△ Все больше и больше валидаторов высказываются в поддержку увеличения лимита газа блока.
Тем не менее, увеличение лимита газа блока или количества больших двоичных объектов окажет большее давление на p2p-сеть Ethereum, поскольку объем передаваемых данных станет больше, что сделает злоумышленников более эффективными, если только стоимость публикации данных не увеличится.
После выпуска протокола EIP-7623 стоимость calldata увеличится в 2.5 раза с исходных значений «Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas» до «Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas».
Если злоумышленник использует всю предельную газовую лимит блока (30M) для размещения мусорных данных, размер данных в блоке будет около 1,79 МБ (30M / 16), что сравнимо с средним размером блока около 100 КБ; если газовый лимит блока увеличится до 40M, злоумышленник сможет создать блок размером примерно 2,38 МБ. При увеличении стоимости calldata в 2,5 раза эффективность злоумышленника снизится до 0,72 МБ для максимальных 30M и 0,95 МБ для максимальных 40M, что позволит безопасно увеличить предельный газовый лимит блока и количество Blob. Однако этот протокол технической сети также не хочет воздействовать на обычных пользователей, которые не использовали calldata для публикации данных, поэтому он вычисляет общее количество газа для сделки двумя способами и выбирает наибольшее количество.
Исходный метод расчета использования газа транзакцией рассчитывается по старой стоимости calldata: то есть calldata вычисляется по схеме "Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas", и добавляется газ, затраченный на выполнение транзакции, и газ, потребленный контрактом развертывания.
Просто рассчитайте количество газа calldata, но используйте для расчета новую стоимость: то есть calldata вычисляется по схеме "Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas", но не включает в себя газ, израсходованный исполнением или газ, израсходованный развертыванием контракта, поэтому для пользователей, которые вообще "не используют calldata для публикации данных" (например, идут на Uniswap для обмена), он является основным Gas Потребление является частью выполнения, и даже если calldata вычисляется по новой стоимости, оно не превысит потребление газа выполнением, поэтому обычные пользователи не будут затронуты.
Реальное влияние будет на меньшие по размеру объединения, поскольку большие двоичные объекты имеют фиксированный размер и фиксированную плату, поэтому небольшие объединения неэффективны для использования больших двоичных объектов, и более экономично использовать calldata, но после EIP-7623 стоимость этих небольших накопительных пакетов увеличится в 2,5 раза, и им, возможно, придется переключиться на использование больших двоичных объектов или найти способ объединить усилия для совместного использования большого двоичного объекта.
EIP-7691: Увеличение пропускной способности Blob
Увеличьте количество больших двоичных объектов и добавьте больше места для публикации данных в накопительные пакеты. *
EIP-7691 увеличивает количество Blob с "Цель: 3 Blob, Макс.: 6 Blob" до "Цель: 6 Blob, Макс.: 9 Blob", предоставляя больше места для публикации данных Rollup.
Примечание: Кроме того, на рынке комиссий Blob есть некоторые дизайнерские настройки, такие как недостаточная мгновенность регулирования комиссий и слишком низкий минимум комиссий, но это не является проблемой, которую нужно решать в этом техническом протоколе.
Другие технические протоколы
EIP-7549: перемещение индекса комитета за пределы проверки
Настройте содержимое голосования за проверяющих, чтобы выборы были более удобными для агрегации и снижения давления на p2p сеть.
Валидаторы случайным образом распределяются по группам комитетов и парам для каждой эпохи
При голосовании по блокам памяти голоса валидаторов в каждом комитете могут быть агрегированы вместе, что уменьшает количество голосов, прошедших в P2P-сети, но голоса валидатора будут содержать информацию о количестве комитетов, к которым принадлежит валидатор, а это значит, что голоса разных комитетов не могут быть агрегированы, даже если все они голосуют на одном блоке памяти.
EIP-7549 удаляет информацию о принадлежности валидатора к первому комитету из контента голосования, чтобы валидаторы из разных комитетов могли быть агрегированы вместе, когда контент голосования одинаков, что еще больше уменьшает количество голосов, проходящих в P2P-сети, и снижает давление на P2P-сеть.
EIP-7840: добавление плана Blob в файл настройки EL
Создайте файл конфигурации для параметров BLOB-объектов на уровне выполнения, избавив узел уровня выполнения от необходимости запрашивать у узла уровня консенсуса параметры, связанные с BLOB-объектами.
Параметры, связанные с BLOB-объектами, в настоящее время хранятся в узлах уровня консенсуса, но в некоторых случаях узлам уровня выполнения по-прежнему требуются эти параметры (например, RPC eth_feeHistory), поэтому они должны запрашивать узлы уровня консенсуса.
EIP-7840 создает файл конфигурации для параметров, связанных с BLOB-объектами, на уровне выполнения, и узлы на уровне выполнения могут напрямую считывать параметры, связанные с BLOB-объектами, через этот файл конфигурации, не запрашивая у узлов уровня консенсуса.
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Введение в хардфорк Ethereum Pectra
Автор: NIC Lin, Medium
Хардфорк Pectra планируется запустить в марте 2025 года. Обновление Pectra включает в себя 11 технических протоколов (EIP), а именно:
Технические протоколы, связанные с залогом
EIP-6110: Предварительная компиляция операций на кривой BLS12-381
Упростить процесс участия пользователей в залоге, существенно сократив время ожидания.
Пользователь участвует в залоге, внедряя 32 ETH на уровне исполнения и регистрируясь в журнале событий (Event Log); затем уровень консенсуса анализирует журнал событий, чтобы определить, участвовал ли кто-то в залоге, после чего пользователь, участвующий в залоге, становится валидатором.
Однако сначала участники проверки на уровне согласия должны определить, для какого момента времени они достигли согласия, в противном случае они обнаружат, что некоторые проверяющие видят 5 новых внесенных вкладов, а другие видят только 3, поэтому участники проверки на уровне согласия должны проголосовать за блок (eth1data) на уровне выполнения, чтобы убедиться, что все видят одинаковый блок уровня выполнения.
Однако при первоначальном проектировании для предотвращения возникновения серьезных ошибок на уровне исполнения, приводящих к разделению цепи, исполнительный блок (eth1data), на который ссылаются, будет представлять собой блок исполнения, сформированный около 10 часов назад, чтобы обеспечить достаточное время для реакции и решения проблем разработчиками консенсусного уровня в случае серьезных ошибок. Однако это также означает, что участникам стейкинга придется ждать более 10 часов, чтобы их участие вступило в силу.
!
△ CL в блоке 10900000 eth1data, в котором записан хэш блока, являющегося блоком исполнения 21683339, появившийся за 10 часов до него.
После выполнения технического протокола EIP-6110 данные о залоге пользователя на контракте непосредственно станут частью исполнительного уровня, а поскольку блоки уровня согласия сами по себе будут включать блоки исполнения (но не eth1data), то валидаторам уровня согласия уже не придется задумываться о том, "одинаковы ли исполнительные блоки, на которые они ссылаются", - им всего лишь нужно, чтобы более двух третей валидаторов уровня согласия проголосовали за подтверждение блока уровня согласия, и все согласуются на том, что они видят один и тот же блок исполнения. Следовательно, после участия пользователя в залоге, это начнет действовать через приблизительно 13 минут после завершения обработки блока исполнения, и клиент уровня согласия также сможет избавиться от сложной логики, связанной с обработкой данных о залоге.
EIP-7002: Сохранение хэша предыдущего блока в состоянии
Может использоваться для улучшения процесса вывода стейкинга или обеспечения займами и доходов, снижая риски валидаторов.
Для участия в стейкинге вам понадобятся два ключа: ключ валидатора и удостоверение о снятии средств.
Ключ проверки используется для проверки работы валидатора, удостоверение вывода используется для проверки выхода валидатора из ставки, гарантийный депозит и доход будут перечислены на адрес, из которого можно вывести, кроме того, в настоящее время выход из ставки обязательно должен выполняться с помощью ключа проверки.
Если потерять ключ валидатора, то невозможно будет выполнять работу валидатора и выйти из залога; если потерять удостоверение о снятии, то будет потеряна вся залоговая сумма и доход. Кроме того, некоторые пользователи могут использовать услуги сторонних сторон, таких как Lido, для залога; при использовании этих платформ пользователи должны самостоятельно хранить удостоверение о снятии, в то время как ключ валидатора хранится и выполняется работа валидатора по поручению поставщика услуг.
По протоколу EIP-7002 пользователь может вызвать 'контракт снятия' (развернутый на 0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA) для выхода из залога (Exit) или частичного снятия залога и дохода (Partial Withdrawal), что может снизить связанные с использованием сторонних услуг по залогу возможные риски. Если пользователь участвует в залоге самостоятельно, но потерял Ключ валидатора, он также может выйти из залога.
Примечание: если ваш Сертификат Вывода все еще в формате открытого ключа BLS, не забудьте сначала переключиться и преобразовать его в формат адреса EL.
EIP-7251: Добавьте MAX_EFFECTIVE_BALANCE
Возможность значительного увеличения верхнего предела суммы залога для уменьшения количества валидаторов, при этом валидаторы, не достигшие предела, могут автоматически получать доход от залога.
Пользователь, желающий стать валидатором, должен предоставить MAX_EFFECTIVE_BALANCE ETH (в настоящее время MAX_EFFECTIVE_BALANCE составляет 32 ETH). Если у пользователя есть 1024 ETH для ставки, он может участвовать в ставке 32 раза, запустить 32 валидатора и запустить 32 узла валидатора. Активное участие пользователей в ставках привело к тому, что в настоящее время уже есть около 1 миллиона валидаторов и их количество продолжает расти. Это не только увеличивает объем данных состояния на уровне согласия, но также значительно увеличивает нагрузку на уровне p2p сети согласия, поскольку каждый слот (каждые 12 секунд) требует непрерывной передачи и агрегации подписей нескольких десятков тысяч валидаторов в сети p2p.
После внедрения технического протокола EIP-7251 минимальный лимит стейкинга (MIN_ACTIVATION_BALANCE) по-прежнему составляет 32 ETH, но верхний предел (MAX_EFFECTIVE_BALANCE) будет значительно увеличен до 2048 ETH, вы можете стейкать любое количество ETH в пределах 32 ~ 2048, вы можете получать вознаграждения за стейкинг, больше не нужно регулярно выводить доход и продолжать стейкать новые ETH после накопления 32 ETH.
В настоящее время существующим валидаторам не нужно сначала выходить из стейкинга, а затем объединяться и снова присоединяться к стейкингу, но они могут напрямую использовать новый «контракт для слияния депозитов» (развернутый в 0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) на уровне исполнения, а Кринденциал вывода средств валидатора вызовет контракт, чтобы инициировать запрос на слияние депозита.
Примечание: Если ваши учетные данные для вывода средств имеют формат открытого ключа BLS, вам необходимо сначала переключить его на формат адреса EL.
EIP-7685: Общий запрос уровня выполнения
Создайте формальный информационный конвейер EL-> CL, чтобы пользователи и сервисы стейкинга могли отправлять запросы непосредственно на уровень консенсуса.
Пользователи могут отправлять запросы непосредственно с уровня исполнения на уровень консенсуса, а сервисы стейкинга (такие как Lido) могут работать более децентрализованно. В качестве примера можно привести запрос EIP-7002 на вывод средств из стейкинга и запрос EIP-7251 на объединение депозитов. Без этого технического протокола пользователям Lido пришлось бы доверять поставщику услуг узлов Lido для выполнения вывода из стейкинга или слияния депозита на уровне консенсуса. С помощью этого технического протокола пользователи Lido могут отправлять запросы непосредственно через контракт управления на уровне исполнения.
Эти запросы будут отличаться типом запроса, инициируемым различными контрактами, и, наконец, все эти запросы будут записаны в блоки памяти уровня исполнения, так что уровень согласия может непосредственно получить эту информацию через блоки памяти уровня исполнения, необходимости в отдельной логике разбора.
EIP-6110, EIP-7002 и EIP-7251 все основаны на стандарте, определенном в EIP-7685, для разработки запросов:
（0x00000000219ab540356cbb839cbe05303d7705fa）инициировать запрос.
Запрос отправлен (0x0c15F14308530b7CDB8460094BbB9cC28b9AaaAA).
(0x00431F263cE400f4455c2dCf564e53007Ca4bbBb) Инициирование запроса.
Технический протокол для улучшения пользовательского опыта
EIP-7702: установка кода учетной записи EOA
Позволяет счет EOA произвольно превращаться в счет контракта, существенно улучшая опыт использования.
У учетной записи EOA есть некоторые недостатки в использовании, включая:
Если это учетная запись смарт-контракта (например, Safe), то вышеперечисленные проблемы можно решить:
Предложение EIP-7702 дает учетным записям EOA возможность стать контрактными учетными записями. Пользователь подписывает преобразованное сообщение закрытым ключом EOA, который включает в себя «Идентификатор сети», «Измененный адрес контракта» и «Значение одноразового номера EOA»:
Однако следует обратить внимание на несколько моментов:
Даже если учетная запись EOA пользователя станет контрактом, он все равно может продолжать использовать ее в исходном виде. Например, если ваша учетная запись EOA станет контрактом Safe, то вы сможете использовать интерфейс Safe, проходить процесс Safe-сделок и продолжать подписывать сделки с помощью исходного кошелька EOA. Однако это также означает, что безопасность учетной записи все еще ограничена этим приватным ключом.
Даже если учетная запись пользователя EOA станет многоадресной, пока у него не потеряны приватные ключи EOA, безопасность его учетной записи всегда будет зависеть от безопасности приватных ключей EOA: он все равно должен хорошо хранить свои приватные ключи или мнемонические слова, его учетная запись не станет такой же безопасной, как мультиподписная.
Когда учетная запись EOA превращается в контракт и записывает данные в свое хранилище, эти данные, записанные в хранилище, не форматируются из-за того, что учетная запись EOA превратилась в другой контракт или отменила свое преобразование, если явно не выполнено действие удаления данных, поэтому разработчики должны обратить внимание на то, что хранилище не должно читать данные, оставленные предыдущими преобразованными контрактами, можно ознакомиться с ERC-7201.
Обычно у контрактов требуется инициализационный этап, во время развертывания контракта синхронно записывается информация о владельце контракта (например, открытый ключ или адрес), чтобы избежать украденного развертывания (Frontrun), что приведет к потере владения контрактом. Обычно это выполняется заводским контрактом, развертывающим контракт, но потому что EIP-7702 непосредственно изменяет контракт, а не развертывающий контракт на EOA, злоумышленник может украсть подпись пользователя и отправить транзакцию на цепочку, чтобы изменить контракт на контролируемый злоумышленником, поэтому разработчики должны обратить внимание на EIP-7702. Возможные методы защиты, такие как проверка подписи учетной записи EOA в инициализирующей функции, таким образом, даже если произойдет украденное развертывание, злоумышленнику не удастся сгенерировать подпись этой учетной записи EOA для завершения инициализации.
Кошелек должен надлежащим образом защищать пользователей, блокируя запросы от зловредных веб-сайтов DApp на подписание транзакции на изменение личности и предупреждать пользователей об этом. В противном случае, если пользователь подпишет зловредную транзакцию на изменение личности, это приведет к мгновенному переходу активов. Вот некоторые примеры реализации контрактов на изменение личности:
Протокол технологии DApp
EIP-2537: Прекомпилятор операций с кривыми BLS12-381
Уменьшите затраты и сделайте его более осуществимым для приложений доказательства с нулевым разглашением на основе кривых BLS.
В EIP-2537 добавлено несколько новых контрактов предварительной компиляции для обеспечения недорогих операций с кривыми BLS, что делает более осуществимой разработку приложений доказательства с нулевым разглашением на основе кривых BLS.
EIP-2935: Сохранение исторических хэшей блоков в состоянии
Это позволяет разработчикам или узлам считывать хэш прошлых блоков памяти непосредственно из хранилища системного контракта.
Если разработчику необходимо доказать содержимое предыдущего блока памяти, например, если мошеннический вызов Optimismtic Rollup хочет доказать, что транзакция существует в 1000 предыдущих блоках памяти, он не может сказать об этом напрямую.
«Поверьте мне, 1000 блоков памяти действительно существовали раньше», он должен был дать показания, но прямых доказательств того, что «1000 предыдущих блоков памяти содержали это содержимое», не было, поэтому он должен был доказать транзакцию в «цепочке» блоков памяти, блок за блоком, пока она не достигнет 1000 предыдущих блоков, а затем доказать, что транзакция существовала в блоке.
!
△ Каждый блок указывает на родительский блок, поэтому вы можете доказать наличие любого блока в истории.
Предположим, что в настоящее время это блок памяти с номером 10000, и вызов мошенничества хочет предоставить доказательство того, что блок памяти с номером 9000 имеет транзакцию X, претендент должен начать с хэша блока памяти 10000, сначала доказать хэш родительского блока памяти 9999, соединенного с блоком памяти 10000, а затем доказать блок памяти 9998... До блока памяти 9000 содержимое блока памяти 9000 предполагается содержать транзакцию X.
После EIP-2935 будет существовать системный контракт (развертывается на 0x0F792be4B0c0cb4DAE440Ef133E90C0eCD48CCCC), который будет хранить в своем хранилище до 8192 хешей предыдущих блоков памяти. Каждый раз, когда появляется новый блок памяти, этот системный контракт автоматически обновляется, записывая хеш предыдущего блока памяти в системный контракт (перезаписывает хеши 8192 предыдущих блоков памяти).
Таким образом, в примере с мошенническим вызовом Optimismtic Rollup, претенденту не нужно возвращаться к предыдущему блоку памяти, чтобы доказать по одному блоку памяти за раз, но он может напрямую доказать, что в текущем состоянии цепочки блока памяти 10000 значение определенного хранилища (соответствующего блоку памяти 9000) системного контракта является хеш-значением блока памяти 9000. Если диапазон превышает 8192, например, блок памяти 1000, то максимум еще один шаг для доказательства хеш-значения блока памяти 1808 (= 10000 - 8192), а затем доказательства хеш-значения блока памяти 1000 в системном контракте в текущем состоянии цепочки блока памяти 1808.
Это также прокладывает путь для будущего клиента без сохранения состояния: в будущем легким узлам больше не нужно будет хранить заголовки блоков всех исторических блоков памяти, а нужно будет только попросить кого-то другого предоставить доказательство с помощью метода доказательства из предыдущего примера с вызовом мошенничества, когда необходимо использовать хэш блока памяти в истории или содержимое блока памяти.
EIP-7623: Увеличение стоимости calldata
Увеличьте затраты на публикацию данных с помощью calldata, чтобы освободить достаточно безопасного пространства для увеличения лимита газа блока и ограничения BLOB-объектов.
В связи с растущим спросом на выпуск данных для накопительных пакетов, после введения BLOB-объектов в EIP-4844, позволяющих накопительным пакетам размещать данные очень дешевым способом, увеличение количества BLOB-объектов стало обновлением, которого сообщество с нетерпением ждет.
!
△ Все больше и больше валидаторов высказываются в поддержку увеличения лимита газа блока.
Тем не менее, увеличение лимита газа блока или количества больших двоичных объектов окажет большее давление на p2p-сеть Ethereum, поскольку объем передаваемых данных станет больше, что сделает злоумышленников более эффективными, если только стоимость публикации данных не увеличится.
После выпуска протокола EIP-7623 стоимость calldata увеличится в 2.5 раза с исходных значений «Zero Byte: 4 Gas, Non-Zero Byte: 16 Gas» до «Zero Byte: 10 Gas, Non-Zero Byte: 40 Gas».
Если злоумышленник использует всю предельную газовую лимит блока (30M) для размещения мусорных данных, размер данных в блоке будет около 1,79 МБ (30M / 16), что сравнимо с средним размером блока около 100 КБ; если газовый лимит блока увеличится до 40M, злоумышленник сможет создать блок размером примерно 2,38 МБ. При увеличении стоимости calldata в 2,5 раза эффективность злоумышленника снизится до 0,72 МБ для максимальных 30M и 0,95 МБ для максимальных 40M, что позволит безопасно увеличить предельный газовый лимит блока и количество Blob. Однако этот протокол технической сети также не хочет воздействовать на обычных пользователей, которые не использовали calldata для публикации данных, поэтому он вычисляет общее количество газа для сделки двумя способами и выбирает наибольшее количество.
Реальное влияние будет на меньшие по размеру объединения, поскольку большие двоичные объекты имеют фиксированный размер и фиксированную плату, поэтому небольшие объединения неэффективны для использования больших двоичных объектов, и более экономично использовать calldata, но после EIP-7623 стоимость этих небольших накопительных пакетов увеличится в 2,5 раза, и им, возможно, придется переключиться на использование больших двоичных объектов или найти способ объединить усилия для совместного использования большого двоичного объекта.
EIP-7691: Увеличение пропускной способности Blob
EIP-7691 увеличивает количество Blob с "Цель: 3 Blob, Макс.: 6 Blob" до "Цель: 6 Blob, Макс.: 9 Blob", предоставляя больше места для публикации данных Rollup.
Примечание: Кроме того, на рынке комиссий Blob есть некоторые дизайнерские настройки, такие как недостаточная мгновенность регулирования комиссий и слишком низкий минимум комиссий, но это не является проблемой, которую нужно решать в этом техническом протоколе.
Другие технические протоколы
EIP-7549: перемещение индекса комитета за пределы проверки
Настройте содержимое голосования за проверяющих, чтобы выборы были более удобными для агрегации и снижения давления на p2p сеть.
Валидаторы случайным образом распределяются по группам комитетов и парам для каждой эпохи
При голосовании по блокам памяти голоса валидаторов в каждом комитете могут быть агрегированы вместе, что уменьшает количество голосов, прошедших в P2P-сети, но голоса валидатора будут содержать информацию о количестве комитетов, к которым принадлежит валидатор, а это значит, что голоса разных комитетов не могут быть агрегированы, даже если все они голосуют на одном блоке памяти.
EIP-7549 удаляет информацию о принадлежности валидатора к первому комитету из контента голосования, чтобы валидаторы из разных комитетов могли быть агрегированы вместе, когда контент голосования одинаков, что еще больше уменьшает количество голосов, проходящих в P2P-сети, и снижает давление на P2P-сеть.
EIP-7840: добавление плана Blob в файл настройки EL
Создайте файл конфигурации для параметров BLOB-объектов на уровне выполнения, избавив узел уровня выполнения от необходимости запрашивать у узла уровня консенсуса параметры, связанные с BLOB-объектами.
Параметры, связанные с BLOB-объектами, в настоящее время хранятся в узлах уровня консенсуса, но в некоторых случаях узлам уровня выполнения по-прежнему требуются эти параметры (например, RPC eth_feeHistory), поэтому они должны запрашивать узлы уровня консенсуса.
EIP-7840 создает файл конфигурации для параметров, связанных с BLOB-объектами, на уровне выполнения, и узлы на уровне выполнения могут напрямую считывать параметры, связанные с BLOB-объектами, через этот файл конфигурации, не запрашивая у узлов уровня консенсуса.