Обновление Pectra является следующей важной вехой для сети Ethereum, которая, как ожидается, будет реализована в первом квартале 2025 года. Это обновление состоит из двух основных компонентов: обновления Prague (уровень выполнения) и обновления Electra (уровень протокола).
В отличие от предыдущих крупных обновлений, у Pectra нет какой-то одной важной цели; Вместо этого он фокусируется на многочисленных технологических улучшениях и оптимизациях. Это контрастирует с обновлением Dencun (которое значительно снизило комиссию L2) и обновлением Shapella (которое позволило выводить ETH в стейкинге, завершая переход Ethereum на Proof of Stake (PoS)).
Недавно разработчики ядра Ethereum (ACD, All Core Developers) обсудили возможность разделения обновления Pectra на две фазы во время конференц-звонка. Согласно этому предложению:
Этот поэтапный подход направлен на то, чтобы обеспечить управляемость масштаба и сложности каждого обновления, оставляя при этом достаточно времени для тщательного тестирования и доработки различных технологий.
Это предложение вводит предварительно скомпилированные операции на кривой BLS12-381, что значительно повышает эффективность таких операций, как проверка подписи BLS. По сравнению с существующими предварительно скомпилированными операциями BN254, BLS12-381 обеспечивает более высокий уровень безопасности (более 120 бит, в то время как BN254 обеспечивает только 80 бит). Это усовершенствование включает в себя не только базовые операции с кривыми, но и интеграцию множественного возведения в степень, закладывая основу для эффективного агрегирования открытых ключей и подписей.
Это предложение предлагает хранить хэши последних 8 192 блоков в системном контракте, в первую очередь для поддержки выполнения клиентов без сохранения состояния. Таким образом, клиенты без отслеживания состояния могут легко получить доступ к необходимой исторической информации, сохраняя при этом совместимость с существующим кодом операции BLOCKHASH. Это изменение упрощает механизм хранения истории хэшей блоков и обеспечивает новый подход к доступу к историческим данным.
Это предложение напрямую интегрирует процесс депозитов валидаторов в блочную структуру уровня исполнения Ethereum. Это изменение перекладывает ответственность за включение и проверку депозитов с уровня консенсуса на уровень исполнения, устраняя необходимость в том, чтобы уровень консенсуса голосовал за депозиты (или eth1data). Генерируя список депозитов путем анализа событий журнала контрактов по депозитным транзакциям, этот метод не только повышает безопасность и эффективность обработки депозитов, но и улучшает пользовательский опыт. Кроме того, это упрощает проектирование клиентского программного обеспечения и снижает общую сложность системы.
Этот предложение представляет новый механизм, который позволяет валидаторам вывести свои учетные данные через слой выполнения (0x01) для запуска операций вывода и выхода. Конкретно, сообщение о выводе прикрепляется к блоку слоя выполнения, а затем обрабатывается слоем консенсуса. Этот подход предоставляет валидаторам более гибкие варианты выхода, при этом поддерживая безопасность и последовательность системы.
Это предложение направлено на увеличение максимального эффективного баланса (MAX_EFFECTIVE_BALANCE) для валидаторов Ethereum при сохранении минимального баланса стейкинга в 32 ETH. Это изменение предлагает несколько преимуществ:
Это предложение предлагает удалить поле индекса комитета из подписанных доказательств, чтобы обеспечить агрегацию тех же консенсусных голосов. Основная цель этого изменения - повышение эффективности клиентов Casper FFG путем уменьшения среднего количества парных операций, необходимых для проверки правил консенсуса. Хотя все типы клиентов могут получить выгоду от этого улучшения, ожидается, что это обеспечит наиболее значительное улучшение производительности для ZK-цепочек, которым необходимо доказать консенсус Casper FFG.
Это предложение определяет общую структуру хранения и обработки запросов, запускаемых смарт-контрактами. Конкретная реализация добавляет поле как в заголовок выполнения, так и в тело для хранения информации о запросе, тем самым предоставляя эти запросы уровню консенсуса и позволяя ему обрабатывать каждый запрос. Этот механизм предназначен в первую очередь для удовлетворения растущего спроса на контроль валидаторов со стороны смарт-контрактов и для обеспечения основы для более сложных ончейн-взаимодействий в будущем.
Предложение Виталика Бутерина и других разработчиков, EIP-7702, направлено на оптимизацию абстракции учетной записи в Ethereum. Это предложение вводит новый тип транзакции, который позволяет внешним управляемым учетным записям (EOAs) устанавливать код учетной записи через механизм авторизации. Это улучшение поддерживает несколько новых функций:
Приняв новую структуру транзакции, это предложение не только улучшает функциональность и удобство использования EOAs, но также обеспечивает хорошую совместимость и масштабируемость для будущих технологий абстракции учетной записи.
Хотя обновление Pectra не имеет заметной основной цели, оно еще больше повысит функциональность, безопасность и эффективность сети Ethereum за счет ряда технических улучшений и оптимизаций. По мере реализации планов обновления мы можем увидеть новые EIP, которые будут включены или скорректированы.
Ссылки
[1]EIP-2537: https://eips.ethereum.org/EIPS/eip-2537
[2]EIP-2935: https://eips.ethereum.org/EIPS/eip-2935
[3]EIP-6110: https://eips.ethereum.org/EIPS/eip-6110
[4]EIP-7002: https://eips.ethereum.org/EIPS/eip-7002
[5]ЭИП-7251: https://eips.ethereum.org/EIPS/eip-7251
[6]EIP-7549: https://eips.ethereum.org/EIPS/eip-7549
[7]EIP-7685: https://eips.ethereum.org/EIPS/eip-7685
[8]EIP-7702: https://eips.ethereum.org/EIPS/eip-7702
[9]EIP-7547: https://eips.ethereum.org/EIPS/eip-7547
[10]ЭИП-7623: https://eips.ethereum.org/EIPS/eip-7623
[11]ЭИП-7742: https://eips.ethereum.org/EIPS/eip-7742
[12]EIP-7600: метаданные об хардфорке Pectra:https://eips.ethereum.org/EIPS/eip-7600
[13] Ethereum Core Developer Consensus Layer Meeting #197:https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-197/
Эта статья воспроизведена сdwong], исходный заголовок «Интерпретация Ethereum Pectra: следующее крупное обновление», авторское право принадлежит оригинальному автору [dwong], если у вас есть какие-либо возражения против перепечатки, пожалуйста, свяжитесь с нами Команда Gate Learn, команда обработает это как можно скорее в соответствии с соответствующими процедурами.
Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, представляют только личные взгляды автора и не являются инвестиционными советами.
Другие языковые версии статьи переведены командой Gate Learn и не упоминаются в Gate.io, переведенная статья не может быть воспроизведена, распространена или скопирована.
Обновление Pectra является следующей важной вехой для сети Ethereum, которая, как ожидается, будет реализована в первом квартале 2025 года. Это обновление состоит из двух основных компонентов: обновления Prague (уровень выполнения) и обновления Electra (уровень протокола).
В отличие от предыдущих крупных обновлений, у Pectra нет какой-то одной важной цели; Вместо этого он фокусируется на многочисленных технологических улучшениях и оптимизациях. Это контрастирует с обновлением Dencun (которое значительно снизило комиссию L2) и обновлением Shapella (которое позволило выводить ETH в стейкинге, завершая переход Ethereum на Proof of Stake (PoS)).
Недавно разработчики ядра Ethereum (ACD, All Core Developers) обсудили возможность разделения обновления Pectra на две фазы во время конференц-звонка. Согласно этому предложению:
Этот поэтапный подход направлен на то, чтобы обеспечить управляемость масштаба и сложности каждого обновления, оставляя при этом достаточно времени для тщательного тестирования и доработки различных технологий.
Это предложение вводит предварительно скомпилированные операции на кривой BLS12-381, что значительно повышает эффективность таких операций, как проверка подписи BLS. По сравнению с существующими предварительно скомпилированными операциями BN254, BLS12-381 обеспечивает более высокий уровень безопасности (более 120 бит, в то время как BN254 обеспечивает только 80 бит). Это усовершенствование включает в себя не только базовые операции с кривыми, но и интеграцию множественного возведения в степень, закладывая основу для эффективного агрегирования открытых ключей и подписей.
Это предложение предлагает хранить хэши последних 8 192 блоков в системном контракте, в первую очередь для поддержки выполнения клиентов без сохранения состояния. Таким образом, клиенты без отслеживания состояния могут легко получить доступ к необходимой исторической информации, сохраняя при этом совместимость с существующим кодом операции BLOCKHASH. Это изменение упрощает механизм хранения истории хэшей блоков и обеспечивает новый подход к доступу к историческим данным.
Это предложение напрямую интегрирует процесс депозитов валидаторов в блочную структуру уровня исполнения Ethereum. Это изменение перекладывает ответственность за включение и проверку депозитов с уровня консенсуса на уровень исполнения, устраняя необходимость в том, чтобы уровень консенсуса голосовал за депозиты (или eth1data). Генерируя список депозитов путем анализа событий журнала контрактов по депозитным транзакциям, этот метод не только повышает безопасность и эффективность обработки депозитов, но и улучшает пользовательский опыт. Кроме того, это упрощает проектирование клиентского программного обеспечения и снижает общую сложность системы.
Этот предложение представляет новый механизм, который позволяет валидаторам вывести свои учетные данные через слой выполнения (0x01) для запуска операций вывода и выхода. Конкретно, сообщение о выводе прикрепляется к блоку слоя выполнения, а затем обрабатывается слоем консенсуса. Этот подход предоставляет валидаторам более гибкие варианты выхода, при этом поддерживая безопасность и последовательность системы.
Это предложение направлено на увеличение максимального эффективного баланса (MAX_EFFECTIVE_BALANCE) для валидаторов Ethereum при сохранении минимального баланса стейкинга в 32 ETH. Это изменение предлагает несколько преимуществ:
Это предложение предлагает удалить поле индекса комитета из подписанных доказательств, чтобы обеспечить агрегацию тех же консенсусных голосов. Основная цель этого изменения - повышение эффективности клиентов Casper FFG путем уменьшения среднего количества парных операций, необходимых для проверки правил консенсуса. Хотя все типы клиентов могут получить выгоду от этого улучшения, ожидается, что это обеспечит наиболее значительное улучшение производительности для ZK-цепочек, которым необходимо доказать консенсус Casper FFG.
Это предложение определяет общую структуру хранения и обработки запросов, запускаемых смарт-контрактами. Конкретная реализация добавляет поле как в заголовок выполнения, так и в тело для хранения информации о запросе, тем самым предоставляя эти запросы уровню консенсуса и позволяя ему обрабатывать каждый запрос. Этот механизм предназначен в первую очередь для удовлетворения растущего спроса на контроль валидаторов со стороны смарт-контрактов и для обеспечения основы для более сложных ончейн-взаимодействий в будущем.
Предложение Виталика Бутерина и других разработчиков, EIP-7702, направлено на оптимизацию абстракции учетной записи в Ethereum. Это предложение вводит новый тип транзакции, который позволяет внешним управляемым учетным записям (EOAs) устанавливать код учетной записи через механизм авторизации. Это улучшение поддерживает несколько новых функций:
Приняв новую структуру транзакции, это предложение не только улучшает функциональность и удобство использования EOAs, но также обеспечивает хорошую совместимость и масштабируемость для будущих технологий абстракции учетной записи.
Хотя обновление Pectra не имеет заметной основной цели, оно еще больше повысит функциональность, безопасность и эффективность сети Ethereum за счет ряда технических улучшений и оптимизаций. По мере реализации планов обновления мы можем увидеть новые EIP, которые будут включены или скорректированы.
Ссылки
[1]EIP-2537: https://eips.ethereum.org/EIPS/eip-2537
[2]EIP-2935: https://eips.ethereum.org/EIPS/eip-2935
[3]EIP-6110: https://eips.ethereum.org/EIPS/eip-6110
[4]EIP-7002: https://eips.ethereum.org/EIPS/eip-7002
[5]ЭИП-7251: https://eips.ethereum.org/EIPS/eip-7251
[6]EIP-7549: https://eips.ethereum.org/EIPS/eip-7549
[7]EIP-7685: https://eips.ethereum.org/EIPS/eip-7685
[8]EIP-7702: https://eips.ethereum.org/EIPS/eip-7702
[9]EIP-7547: https://eips.ethereum.org/EIPS/eip-7547
[10]ЭИП-7623: https://eips.ethereum.org/EIPS/eip-7623
[11]ЭИП-7742: https://eips.ethereum.org/EIPS/eip-7742
[12]EIP-7600: метаданные об хардфорке Pectra:https://eips.ethereum.org/EIPS/eip-7600
[13] Ethereum Core Developer Consensus Layer Meeting #197:https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-197/
Эта статья воспроизведена сdwong], исходный заголовок «Интерпретация Ethereum Pectra: следующее крупное обновление», авторское право принадлежит оригинальному автору [dwong], если у вас есть какие-либо возражения против перепечатки, пожалуйста, свяжитесь с нами Команда Gate Learn, команда обработает это как можно скорее в соответствии с соответствующими процедурами.
Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, представляют только личные взгляды автора и не являются инвестиционными советами.
Другие языковые версии статьи переведены командой Gate Learn и не упоминаются в Gate.io, переведенная статья не может быть воспроизведена, распространена или скопирована.