Исходное название: «Обновление собрания разработчиков Ethereum Core 014».
Первоисточник: Обновление AllCoreDevs.
Автор оригинала: Тим Бейко
Оригинальная компиляция: Ethereum.cn.
Добро пожаловать на новое издание AllCoreDevs (Конференция разработчиков Ethereum Core) — последнее в 2022 году.
обзор
Содержание обновления Shanghai/Capella было завершено: вывод средств, EOF и некоторые незначительные изменения... при условии, что они не задерживают вывод средств.
Пространство BLOB-объектов уже на подходе: EIP-4844 будет в центре следующего обновления Эфириума, и скоро начнется церемония его вызова.
С технической стороны предпринимаются усилия по координации процессов обновления уровня исполнения и уровня консенсуса. Мы также наблюдаем активные дискуссии о более эффективном учете вклада сообщества в этот процесс.
Гильдия протоколов опубликовала промежуточный пилотный отчет и примерный план по увеличению числа сопровождающих первого уровня и улучшению их поддержки в 2023 году.
Модернизация Шанхая/Капеллы
На недавнем мероприятии AllCoreDevs команда клиента достигла консенсуса относительно окончательного объема обновления Shanghai/Capella. Хотя название обновления может быть предметом дискуссий, команда ясно представляет его масштабы. Главной особенностью обновления является введение вывода средств Beacon Chain для стейкеров. Команда клиента не хочет идти на компромисс с развертыванием этой функции как можно быстрее, поэтому другие функции обновления должны быть готовы одновременно, иначе они рискуют отказаться от них.
В спецификации Shanghai Executive Layer перечислены все включенные EIP:
EIP-3540: Формат объекта EVM (EOF) v1
EIP-3651: снизить стоимость газа для доступа к адресам COINBASE.
EIP-3670: EOF — проверка кода
EIP-3855: добавлен код операции PUSH 0.
EIP-3860: Ограничить размер инициального кода и ввести измерение газа.
EIP-4200: EOF — статический относительный переход
EIP-4750: EOF — функции импорта
EIP-4895: Отключение цепочки маяков во время работы системы
EIP-5450: EOF — проверка стека
Хотя список длинный, его можно разделить на три части: незначительные улучшения, форматы объектов EVM и отзыв. Далее мы представим их один за другим:
Незначительные улучшения
EIP-3651: Теплая COINBASE (снижение стоимости газа для доступа к адресам COINBASE)
Этот EIP исправляет ошибку в EIP-2929, где стоимость газа для доступа к определенным полям данных была изменена в зависимости от того, находились ли данные уже в памяти клиента (WARM) или их необходимо было получить с диска (COLD).
EIP-2929 устанавливает WARM для двух фрагментов данных в памяти клиента в начале каждой транзакции: адрес отправки и адрес получения. EIP-3651 добавляет в этот список третий адрес — адрес COINBASE (т. е. FeeRecipient), поскольку это также адрес, который клиент имеет в памяти при обработке блочных транзакций.
EIP-3855: инструкция PUSH 0 (новый код операции PUSH 0)
Как следует из названия, EIP-3855 представляет код операции, который помещает в стек значение 0. Ввод 0 часто используется для заполнения значений в EVM, этот код операции обеспечит более эффективный и дешевый способ сделать это.
EIP-3860: Ограничить и измерить начальный код (ограничить размер начального кода и ввести измерение газа)
Этот EIP добавляет ограничение на размер инициализационного кода и вводит измерение газа в зависимости от его длины. Его верхний предел размера добавляет инвариант к EVM, что упрощает понимание и предложение модификаций.
Вводит накладные расходы в размере 2 газа на 32 байта для initcode, которые используются для оплаты анализа jumpdest, который клиент должен выполнить перед выполнением, который не указан в счетчике газа.
формат объекта
Большая часть EIP, включенная в обновление Shanghai, на самом деле является частью одной функции: формата объекта EVM (EOF). Работа была разбита на 5 различных EIP, чтобы помочь разработчикам клиентов понять каждую отдельную модификацию, но чтобы обеспечить обзор более высокого уровня, разработчики выпустили унифицированную спецификацию. EIP этих пяти EOF:
EIP-3540: формат объекта EVM, версия 1.
EIP-3670: EOF — проверка кода
EIP-4200: EOF — статический относительный переход
EIP-4750: EOF — функции импорта
EIP-5450: EOF — проверка стека
Стоит отметить, что первым шагом EOF было лондонское обновление EIP-3541, в котором для контракта EOF был зарезервирован префикс 0xEF 00. Объем EOF модернизации Шанхая также изменился за последние несколько месяцев.
В феврале команда клиента согласилась рассмотреть возможность обновления в Шанхае, включив в него два самых маленьких EIP EOF: EIP 3540 и 3670. Все они будут служить строительными блоками, но не обеспечат полную функциональность без внедрения EIP 4200, 4750 и 5450. Хотя расширение EOF возможно, обратная несовместимость может потребовать новой версии. Поскольку контракты до EOF или EOF с определенной версией всегда должны быть исполняемыми, каждая новая версия EOF означает, что разработчики клиентов должны поддерживать новый набор правил выполнения EVM параллельно со старыми правилами.
До EOF клиенты единовременно поддерживали только один набор правил EVM. База кода также поддерживает предыдущие правила EVM, которые изменяются при каждом обновлении сети, но как только они достигают головы блокчейна, должны применяться только самые последние правила. После развертывания EOF клиент будет поддерживать два параллельных набора правил EVM, чтобы они могли выполнять код в контрактах EOF и без EOF. Другими словами, увеличение количества версий EOF увеличивает количество параллельных, а не последовательных наборов правил EVM, которые необходимо поддерживать.
С этой целью за последние несколько месяцев клиентские команды стали отдавать предпочтение подходу «большого EOF». Таким образом, хотя им придется реализовать более крупные наборы модификаций, версия EOF прослужит дольше и уменьшит количество «параллельных EVM», которые необходимо поддерживать. Поэтому разработчики рассмотрели «большой EOF» и в итоге включили его в обновление «Шанхай».
Тем не менее, более крупные функции, очевидно, труднее реализовать и протестировать, и команда не хочет, чтобы EOF серьезно задерживал вывод цепочек маяков. Поэтому, если внедрение EOF не будет завершено к январю и они не смогут быстро взаимодействовать друг с другом, команда клиента соглашается переместить EOF из Шанхая для обновления.
Учитывая этот контекст, давайте теперь кратко представим каждый EOF EIP:
EIP-3540: Формат объекта EVM (EOF) v1 (формат объекта EVM, версия 1)
Этот EIP вводит «контейнер» в контракт EOF. Он добавляет теги, чтобы различать части кода и данных контракта, и предотвращает развертывание контрактов EOF, которые не соответствуют формату. Это гарантирует, что любой контракт EOF в цепочке будет иметь действительный формат, что упрощает взаимодействие с этими контрактами, а также их статический анализ.
EIP-3670: EOF — проверка кода (EOF — проверка кода)
Основываясь на контейнере, представленном в 3540, EIP-3670 гарантирует, что код в контракте EOF действителен, или предотвращает его развертывание.
Это означает, что неопределенные коды операций не могут быть развернуты в контрактах EOF, что дает дополнительное преимущество, заключающееся в уменьшении количества версий EOF, которые необходимо добавить. Если добавляется новый код операции, правила проверки можно просто изменить, чтобы включить его и гарантировать, что ни один развернутый контракт EOF не ссылается на него в своем разделе кода.
EIP-4200: EOF — Статические относительные переходы (EOF — Статические относительные переходы)
В EIP-4200 представлены первые коды операций, специфичные для EOF: RJUMP, RJUMPI и RJUMPV, которые кодируют пункты назначения как непосредственные значения со знаком. Эти новые коды операций JUMP могут использоваться компиляторами для оптимизации накладных расходов на газ, поскольку они устраняют необходимость в анализе jumpdest во время выполнения, который требуется для существующих кодов операций JUMP и JUMPI.
EIP-4750: EOF — Функции (функции, представленные EOF)
EIP-4750 идет на шаг дальше, чем 4200: он запрещает использование кодов операций JUMP и JUMPI и добавляет альтернативы для функций, которые невозможно скопировать. Это реализуется путем введения определенных разделов функций в байт-код EOF. Эти функции могут переходить из новых кодов операций JUMPF, CALLF и RETF соответственно и использовать их для вызова и возврата.
EIP-5450: EOF — проверка стека (EOF-Stack Validation)
Наконец, EIP-5450 добавляет еще одну проверку контрактов EOF, на этот раз для стека. Этот EIP предотвращает развертывание кода контрактами EOF, который в некоторых случаях может привести к переполнению стека. Благодаря этому EIP клиенты могут сократить количество проверок при выполнении контрактов EOF, поскольку они имеют лучшие гарантии в отношении исключений, связанных со стеком.
Как эксперт, не связанный с EVM и очень сосредоточенный на самой EIP, я мало что могу сказать по этому поводу! Если читатели хотят узнать больше об EOF, я рекомендую соответствующие твиты, опубликованные Lightclients из команды Geth и Лео из команды Solidity.
Снятие цепочки маяков
И последнее, но не менее важное: основная часть «Шапеллы» (примечание переводчика: собирательное название Шанхая/Капеллы) — это отвод маяковой цепи. Эта часть изменения описана в спецификации уровня консенсуса и EIP-4895. Сейчас существует слегка устаревшая метаспецификация, связывающая эти изменения воедино.
На высоком уровне механика вывода средств выглядит следующим образом:
Предлагая блок, валидатор линейно сканирует индекс валидатора, чтобы найти первые 16 валидаторов с учетными данными 0x01, которые должны соответствовать одному из следующих условий:
Иметь баланс выше 32 ETH (т.е. иметь начисленные вознаграждения валидатора)
Могут быть изъяты (т. е. полностью вышли из набора валидаторов)
Баланс больше 32 ETH (то есть вознаграждение валидатора получено)
Он является выводным (выводимым, то есть полностью вышел из набора валидаторов)
На основе них валидатор создаст список вывода средств, который будет включен в его ExecutionPayload. Каждый элемент в этом списке содержит следующее:
Валидатор создаст список вывода средств из этих валидаторов и упакует его в свою ExecutionPayload. Каждый элемент списка содержит следующее:
WithdrawalIndex: Индекс всех совершенных транзакций вывода средств. Это помогает отличить вывод одной и той же суммы с одного и того же адреса и одного и того же валидатора.
ValidatorIndex: индекс валидатора, на котором был поднят баланс.
ExecutionAddress: ETH-адрес уровня исполнения, на который должны быть отправлены выплаты.
Сумма: сумма, отправленная на ExecutionAddress. Эта сумма измеряется в gwei (не wei).
Клиенты уровня исполнения будут осуществлять эти выплаты после выполнения транзакций при создании или обработке блоков. Другими словами, снятие средств обрабатывается аналогично регистрации вознаграждений за доказательство работы и не конкурирует с пользовательскими транзакциями за пространство в блоке.
Стоит отметить и другие детали:
При обработке вывода средств нет разницы в приоритете/порядке между «полными средствами» и «частичными средствами». Полные выводы происходят, когда валидатор покидает команду выхода, тогда как частичные выводы происходят периодически, то есть когда выполняется линейное сканирование набора валидаторов и сканируется порядковый номер определенного валидатора.
Для обработки вывода средств валидаторы должны использовать учетные данные 0x01, которые представлены адресами ETH. При подключении цепочки маяков к сети разрешены только учетные данные пары ключей BLS 0x00. Чтобы инициировать вывод средств, валидатору с учетными данными 0x00 необходимо будет подписать сообщение BLSToExecutionChange. Они будут активированы при обновлении Капеллы. Для подписи этого сообщения будут использоваться различные инструменты, и валидаторы могут рассчитывать на поддержку и учебные пособия по этим инструментам.
Сканирование валидаторов производится по блокам. Если после сканирования подмножества набора валидаторов не будет обработано 16 выводов средств, валидатор прекратит сканирование, а следующий валидатор начнет работу с последнего сканированного индекса валидатора.
Как обычно, будет несколько тестовых сетей и тестовых сетей для разработчиков (возможно, даже несколько новых тестовых сетей!), где валидаторы смогут запустить весь процесс и устранить любые недостатки до того, как основная сеть заработает.
Шанхай/Капелла — не единственное обновление, которое прогрессирует! Команда разработчиков все еще с нетерпением ждет следующего обновления.
Обновление в Канкуне
Поскольку содержимое Шанхайского обновления уже заполнено, многие EIP (CFI), которые рассматривались для обновления, не смогли войти в Шанхайское обновление. Команда клиента начинает обсуждение того, какие EIP следует рассмотреть для следующего обновления: обновление в Канкуне (имя уровня консенсуса будет определено позднее)
Что касается уровня консенсуса, EIP-4844 стал первым EIP, включенным в спецификацию после обновления Capella. (Пока) не существует спецификации для исполнительного уровня, которая могла бы реализовать эту схему, но команда исполнительного уровня согласилась пойти по аналогичному пути и сосредоточить EIP-4844 при следующем обновлении.
В соответствии с соглашением об обновлениях с использованием названий городов, где проводился Devcon, был создан cancun.md, в обновление официально включен EIP-4844.
Это решение произошло в последнюю минуту последней встречи AllCoreDevs в 2022 году, поэтому времени работать над другими предложениями не было. EIP, которые вошли в обновление CFI в Шанхае, но не были включены в конце, были перемещены в список CFI для обновления в Канкуне. На форуме Ethereum Magicians также был открыт пост для обсуждения кандидатов EIP в Канкуне. Всерьез обсуждения масштабов модернизации в Канкуне должны начаться в начале следующего года.
Церемония КЗГ
Еще одна вещь, которую стоит ожидать в связи с обновлением Канкуна, — это церемония KZG Ceremony, которая является требованием EIP-4844.
Этот ритуал будет генерировать случайность, необходимую для проверки достоверности данных большого двоичного объекта. Чтобы это считалось безопасным, только один участник должен быть честным. Другими словами, если все участники, кроме одного, вступают в сговор, весь процесс является криптографически безопасным.
Церемония начнется в январе и будет открыта для всех в течение нескольких месяцев. Планируется, что эта церемония соберет 10 000 участников и станет крупнейшей церемонией такого рода на сегодняшний день! Если хотите не пропустить, подписывайтесь на Трента Ван Эппса в Твиттере!
Процесс обновления после слияния
Как упоминалось в предыдущем обновлении, после слияния важным вопросом является координация процесса обновления Ethereum на уровне исполнения и уровне консенсуса. С точки зрения высокого уровня, уровень исполнения использует Yellow Paper и EIP для описания изменений, а уровень консенсуса использует исполняемые спецификации Python.
Преимущество процесса исполнительного уровня заключается в том, что EIP хорошо известен сообществу и отформатирован таким образом, чтобы четко демонстрировать обоснование предложения. Желтые книги с большим количеством математического содержания в сочетании с EIP и необходимостью возвращать спецификации в контекст каждого EIP затрудняют понимание и расширение спецификаций исполнительного уровня.
Проблема со слоем консенсуса обратная: он имеет четкую и понятную спецификацию в едином репозитории, но изменения не ощутимы и предложения зарываются в другие публичные PR в репозитории.
С введением спецификации исполнительного уровня Ethereum мы надеемся сократить этот разрыв со стороны исполнительного уровня. И, приложив некоторые усилия, мы, возможно, сможем внедрить EIP в процесс уровня консенсуса!
Тем не менее, по мере обсуждения и окончательного определения объема обновления в Шанхае стало ясно, что может отсутствовать еще одна часть процесса: предоставление сообществу возможности выразить свои относительные предпочтения в отношении изменений и участвовать в обсуждениях всего объема обновления (а не отдельные EIP) Обсудите это на месте и сделайте это частью решений собрания AllCoreDevs и уровня консенсуса.
Пока неясно, как это будет выглядеть – буду рад предложениям! — но по мере того, как число заинтересованных сторон, активно участвующих в изменениях протокола, росло, а также количество областей, затронутых изменениями уровня 1, стало ясно, что нам что-то нужно.
К счастью, нам не нужно начинать с нуля. Ethereum Magicians существует уже много лет, и его офлайн-встречи, специальные групповые встречи или собрания сообщества могут стать хорошей отправной точкой для расширения.
Ожидайте большего прогресса на этом фронте в начале 2023 года!
Соглашение о обновлении гильдии
Поскольку пилотная версия протокольной гильдии (PG) уже находится на полпути, они выпустили отчет, чтобы посмотреть, как обстоят дела, и обдумать, каковы следующие шаги проекта.
Напоминаем, что PG — это механизм финансирования без разрешения для разработчиков клиентов Ethereum Layer 1, исследователей протоколов и поддерживающих участников (таких как вы).
Этот механизм ориентирован на человека, а не на организацию. Короче говоря, каждый участник имеет право на долю токенов гильдии, взвешенную в зависимости от того, как долго он вносил свой вклад в Ethereum. Добавление и удаление участников осуществляется в истинном стиле Ethereum — на основе набора стандартов и примерного консенсуса внутри PG. Затем этот список будет помещен в цепочку с использованием контракта разделения 0xSplit. Затем донор может отправить средства непосредственно на адрес получателя или по договору о передаче прав, по которому средства переводятся на адрес получателя.
Промежуточный отчет пилотного проекта кратко изложен в этом твите. Вот некоторые основные моменты
Пилотный проект собрал $9,7 млн от таких организаций, как Lido, Uniswap, ENS, NounsDAO и MolochDAO, а также от постоянных доноров от частных лиц (спасибо Tetranode!) — спасибо всем, кто сделал это возможным!
На момент запуска у PG было 90 участников, а сейчас их 128, и между ними распределено 5 миллионов долларов.
В среднем каждый участник получил 39 000 долларов США, при этом наименьшая сумма составила 13 000 долларов США, а самая высокая - 79 000 долларов США.
Архитектура PG меняется и будет поддерживать L2 и устранит необходимость в мультиподписях для обновления весов.
Эти ранние результаты показывают, что PG работает по плану: механизм распределения корзины токенов среди самоинкубирующейся, растущей группы участников протокола. Этот проект не был бы тем, чем он является сегодня, без щедрой поддержки пилотных доноров.
Заглядывая в будущее, сейчас самое время расширить сферу деятельности PG и реализовать весь ее потенциал: предоставить сопровождающим Ethereum конкурентоспособное вознаграждение с поправкой на риск. Проще всего здесь сделать пожертвование проекту в пользу PG с самого начала, как сказал Дэнни Райан в твите, посвященном запуску PG.
Большая часть пожертвований в рамках пилотного проекта поступила от крупных проектов с большими объемами финансирования. Если Гильдия протоколов сможет убедить эти проекты делать пожертвования в пользу PG с первого дня, когда их токены все еще действительно «бесполезны», тогда сопровождающие Ethereum смогут извлечь выгоду из всей восходящей траектории этих успешных проектов.
Когда задействовано достаточное количество проектов, стимулы могут удержать лучшие таланты в соглашениях об обслуживании, а не отвлекать их.
Чтобы поддержать этот и многие другие виды пожертвований, PG потребуется технологический пересмотр. Следующая версия будет поддерживать уровни L1 и L2 и еще больше сократит объем управления внутри цепочки.
Если вы представляете проект, который хотел бы сделать пожертвование в пользу Протокольной гильдии, свяжитесь со мной — мои личные сообщения открыты!
Следовать за
Вот и завершается 2022 год... Какой необыкновенный год! Три месяца назад нас даже не объединили! Теперь, когда у Ethereum доказательство доли спокойно работает в фоновом режиме, фокус сместился на будущие транзакции.
Поскольку все возвращаются в январе, вы можете ожидать:
Shanghai/Capella обновила тестовую сеть для разработчиков и теневой форк
Церемония KZG прошла онлайн
Дискуссии вокруг Канкуна и того, как должен развиваться процесс обновления сети, чтобы лучше учитывать предпочтения сообщества
Пилотный протокол гильдии завершится, и мы объявим пост-пилотную структуру.