Объяснение управления базовым протоколом Эфириума

Презентация Никсо Рокиша (Nixo Rokish) из Фонда Ethereum на ETHBoulder, объясняющая управление базовым протоколом Эфириума, как координируются хардфорки, распространенные заблуждения о том, кто контролирует Эфириум, и как участвовать в процессе управления.

Эта стенограмма является доступной копией оригинальной стенограммы видео (opens in a new tab), опубликованной EthBoulder. Она была слегка отредактирована для удобства чтения.

Введение (0:12)

Спасибо всем шести моим друзьям, которые пришли. Хорошо. Сегодня я расскажу вам об управлении базовым протоколом Эфириума. Меня зовут Никсо. Я руковожу командой поддержки протокола в Фонде Ethereum (EF). Среди всех наших задач одна из главных — сделать процесс управления более понятным и простым для всех остальных участников, потому что Эфириум включает в себя гораздо больше людей, чем просто его основные разработчики.

Вот план выступления. Мы поговорим о том, что такое управление базовым протоколом. Мы обсудим заблуждения и то, как в настоящее время функционирует управление Эфириумом. Мы коснемся того, как оно соотносится с другими децентрализованными системами управления, почему это должно волновать разработчиков, и рассмотрим практические способы участия.

Итак, что такое управление базовым протоколом? Я запускаю узел. Это означает, что у меня есть оборудование, компьютер дома, на котором я запускаю программное обеспечение Эфириума. Когда я настраивал это ПО Эфириума, мне нужно было выбрать клиенты, которые будут его запускать. Эфириум в своем роде уникален тем, что у него есть несколько клиентов для обеспечения разнообразия клиентов. Смысл этого в том, что если один клиент выйдет из строя, если в клиенте появится ошибка, вся сеть не упадет. Есть и другие блокчейны, у которых есть другие клиенты. Однако Эфириум — единственный, который устроен так, что действительно защищает нас от ошибок. Например, если вы посмотрите на Solana, у Solana есть другой клиент, кажется, он называется GTO, но его используют только 20–21%. Поэтому, если основной клиент выйдет из строя, цепь остановится. И мы видели, как другие сети падали. Именно поэтому Эфириум является самым устойчивым и безопасным блокчейном.

Возникает вопрос: как вносить изменения в Эфириум, когда приходится координировать работу с таким количеством разных клиентов? Сначала мы проведем различие между хардфорком и софтфорком. Софтфорк не требует такой координации, как хардфорк. Эфириум в основном работает с хардфорками. Хардфорк — это, по сути, когда все клиенты создают новую версию Эфириума и решают в заранее заданное время запустить эту новую версию. Это все еще Эфириум, но в нем появились новые функции. У него другие возможности. И все операторы узлов, такие как я, которые запускают узлы дома, или профессиональные операторы, должны принять эту новую версию Эфириума. Они должны обновить свой узел, чтобы включить в него это новое программное обеспечение.

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

В прошлом году произошла одна очень спорная ситуация. Возможно, вы о ней слышали. Она называлась EOF. Это EVM Object Format. Это был набор функций, который планировалось включить в хардфорк Фусака — Пектра, Фусака, кажется, в оба — но его разделили. И одной из многих причин, по которой его исключили из этого форка, стал пост Виталика о возможности перехода Эфириума на RISC-V. Многие из тех, кто читал это, подумали: хорошо, если мы перейдем на RISC-V, функции, которые мы рассматриваем в EOF, будут встроены в RISC-V по умолчанию. Так зачем нам добавлять эту сложность в протокол? Зачем тратить на это все ресурсы разработчиков клиентов? Это потеряет смысл, если мы в итоге перейдем на RISC-V.

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

Заблуждения (5:23)

Это подводит нас к заблуждениям, и мы рассмотрим некоторые из них. Первое: Виталик решает, что войдет в протокол Эфириума. Вытекающее из этого второе: Фонд Ethereum контролирует всё. И третье: всё это кулуарные сделки — решения принимают инсайдеры и «старички» (OGs).

Итак, первое: Виталик решает. Я просто выбрал часть заброшенных EIP, автором которых является Виталик. Это означает, что Виталик сел, написал предложение и сказал: «Я хочу, чтобы эти вещи вошли в Эфириум», но никто не согласился — эти предложения просто лежат без движения. Он не смог внедрить их в протокол. Так что далеко не всё, что он предлагает, автоматически включается.

Вытекающее из этого заблуждение: Фонд Ethereum контролирует всё. Я приведу конкретный пример ситуации, которая, на мой взгляд, этому противоречит. В 2024 году было много разговоров о лимите газа. Причина в том, что в 2022 году во время Слияния мы подняли лимит газа до 30 миллионов. Это максимальный объем вычислений, разрешенный в блоке. А потом мы какое-то время его не трогали, потому что это не было узким местом, из-за которого люди говорили бы: «Вот почему я не перехожу на Эфириум» или «Это ограничивает мой текущий вариант использования Эфириума».

А в конце 2023 — начале 2024 года появился нарратив о том, что наступает Solana. Что она собирается оставить Эфириум не у дел. И люди начали думать о том, что может сделать Эфириум для ускорения. Одной из идей было: давайте прокачаем этот показатель газа. В то время Фонд Ethereum и разработчики клиентов отвечали в духе: «У нас есть другие заботы. Но спасибо». Однако пришли два человека, Эрик Коннор (Eric Connor) и Мариано Конти (Mariano Conti), и сказали: «Нет, мы повышаем лимит газа». Лимит газа — это параметр, контролируемый валидаторами. Поэтому они могли просто начать общаться с валидаторами, профессиональными операторами, и говорить: «Эй, поднимите свой лимит газа».

И в какой-то момент это получило такое распространение, что Фонд Ethereum и разработчики клиентов сказали: «О, нам нужно обратить на это внимание. Мы должны убедиться, что то, что они делают, безопасно, и что значение, до которого они в итоге его поднимут, будет безопасным для сети». Поэтому им пришлось перераспределить свои ресурсы. Незермайнд придумал эту среду тестирования. Фонд Ethereum проделал кучу работы в Берлине. Все разработчики клиентов проводили бенчмаркинг. И мне это нравится, потому что это вынудило Фонд Ethereum действовать при определении приоритетов.

И мне нравится этот глупый твит, который я здесь заскриншотил, потому что какое-то случайное новостное издание называет Эрика Коннора и Мариано Конти основными разработчиками (core devs). Они не основные разработчики. Эрик Коннор был стейкером и участником сообщества. Мариано Конти был бывшим разработчиком приложений MakerDAO. Но их просто назвали основными разработчиками, потому что разработка Эфириума действительно выходит за рамки того, как работает традиционное программное обеспечение, и поэтому они увидели, что изменяется базовый параметр, и подумали: «О, это, должно быть, основные разработчики». Это не так. Так что это просто пример того, как участники сообщества приходят и говорят: «Мы хотим видеть это изменение», и добиваются его.

Всё это кулуарные сделки, инсайдеры, «старички» — я немного лучше понимаю, почему существует это заблуждение, потому что вы, по сути, приходите на эти звонки по управлению, а там присутствует сотня человек. Кажется, что они все очень комфортно себя чувствуют в происходящем. Вы же потеряны. Вы понятия не имеете, как принимаются эти решения. Вы думаете: «Уже моя очередь говорить?» И кажется, что люди слушают одних и тех же 10 человек при принятии этих решений.

Меритократия и статистика участия (10:18)

Но правда в том, что разработка Эфириума — это в большей степени меритократия, чем я когда-либо видел в разработке большинства программного обеспечения. Все эти люди на скриншоте — это один из трех случайных звонков ACD, который я решил заскриншотить — никого из этих людей не назначали сюда. Все они — просто люди, которые пришли. Это разработчики, которые провели много времени с этим протоколом. Это те, кого люди признали талантливыми разработчиками в этой сфере, постоянно принимающими правильные решения, и никто из них не был назначен на эту роль.

Я присоединился к Фонду Ethereum чуть больше года назад. Я собрал эту статистику. Она охватывает период только до марта 2025 года. То есть меньше года. Среднее количество участников All Core Dev (звонков всех основных разработчиков) — это звонки по управлению — составляет 98 человек. То есть в среднем на этих звонках присутствует 98 человек. Максимальное количество участников на одном звонке с тех пор составило 153. Кажется, это было в тот день, когда мы определяли дату запуска Пектра в мейннете. А общее количество уникальных участников составило 567 только за последний год. Мне очень нравится этот показатель, потому что он показывает, что на эти звонки каждый раз приходят не одни и те же 100 человек. Это разработчики приложений, исследователи; кто-то слышит о какой-то обсуждаемой функции, приходит, чтобы высказать свое несогласие с ней или поддержать ее, а затем больше не приходит на другие звонки.

Как работает процесс управления (11:52)

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

После этого они выбирают второстепенные функции. То есть более мелкие вещи, которые не обязательно должны быть основными функциями, определяющими форк. И все это время у нас работают сети для разработчиков, ориентированные на конкретные функции. Сеть для разработчиков — это как тестовая сеть — частная тестовая сеть для разработчиков, чтобы они могли протестировать эти функции и убедиться, что они действительно работают в Эфириуме. А затем в какой-то момент происходит заморозка функций (feature freeze). Итак, мы обсудили основные функции, обсудили второстепенные функции, запустили эти сети для разработчиков для конкретных функций, которые обычно являются главными в форке. И это заморозка функций со звездочкой, потому что на этом этапе мы решили, что больше не будем добавлять никаких функций в этот форк. Мы собираемся запустить все функции вместе, убедиться, что все хорошо, что ничего не сломается. Но если что-то начинает тормозить процесс, если форк задерживается, если он слишком сложный, на этом этапе функции все еще могут быть исключены.

Итак, после ряда сетей для разработчиков — их может быть две, а может быть и 10 — все клиенты в какой-то момент решают, что всё стабильно. Мы доверяем тому, что происходит сейчас. Мы в хорошем положении. Давайте начнем думать о том, чтобы выпустить это в основную сеть Ethereum. Они выпускают релизы клиентов, а затем наступает 30-дневный период, когда команда безопасности Фонда Ethereum объявляет программу вознаграждения за найденные ошибки (bug bounty). Они заказывают аудиты безопасности. А затем, в конце этого 30-дневного периода, мы запускаем форк в тестовых сетях. Это тестовые сети, о которых вы, возможно, слышали — например, Holesky. Здесь разработчики приложений могут протестировать свои продукты до того, как форк будет запущен. И обычно на каждую из них отводится минимум 14 дней, просто чтобы убедиться, что все в порядке. Мы не ожидаем никаких серьезных проблем, потому что до этого всё прошло через сети для разработчиков для конкретных функций и общие сети для разработчиков, но исторически случалось, что это ломало некоторые из этих тестовых сетей. Так что это своего рода последний шанс найти и устранить все эти ошибки.

А затем, как только общедоступная тестовая сеть становится стабильной, выбирается дата запуска в мейннете. После этого дается 30-дневный буфер. Этот 30-дневный буфер существует, потому что L2-решения и протоколы просили об этом, чтобы подготовиться к форку. Так что это минимум 30 дней, а затем происходит форк.

Структура звонков и координация (15:01)

В течение всего этого времени проходит серия основных звонков. Все это публичные звонки, которые транслируются в прямом эфире на YouTube. Основные из них — ACDE и ACDC. Буква E означает уровень исполнения (execution layer) — это такие вещи, как транзакции, развертывание смарт-контрактов, управление мемпулом. ACDC — это уровень консенсуса (consensus layer) — то есть вещи, связанные с валидаторами, такие как управление валидаторами, слэшинг. И они чередуются по четвергам. То есть каждый четверг проходит звонок ACD: один из них — ACDE, а следующий — ACDC, и так далее.

Звонки ACDE и ACDC сосредоточены на форке, который мы делаем в данный момент, и на форках, которые мы планируем на будущее. Звонки ACDT — это более глубокое погружение в детали. На них разработчики клиентов обсуждают ошибки, которые они не могут обойти, или детали реализации, которые необходимо решить в связи с форком, над которым они сейчас работают. Прямо сейчас следующий готовящийся форк — это Гламстердам. Поэтому на этих звонках ACDT преобладают разговоры об ePBS и списках доступа на уровне блоков, которые войдут в Гламстердам. И это узкотехнические звонки.

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

Развивающийся процесс (15:29)

Я хочу донести до всех одну вещь: этот процесс отнюдь не статичен. Процесс, который я вам только что описал, существует меньше года. Эфириум существует уже 10 лет. Но он постоянно меняется, и причина, по которой он постоянно меняется, заключается в том, что никто им не руководит. И этот процесс как бы эволюционирует, чтобы найти наиболее эффективный способ работы. Я говорю «эффективный», но репутация управления Эфириумом такова, что оно считается очень застойным, через него трудно что-либо продвинуть, оно запутанное — и это потому, что когда решения принимают от 100 до 500 человек, я, честно говоря, поражен, что это вообще работает.

Итак, Тим (Tim) опубликовал пост в апреле 2025 года под названием «Реконфигурация All Core Devs», который в итоге стал предложением о том, как все работает прямо сейчас. И причина этого в том, что до этого у нас был своего рода связный нарратив о том, на чем нам следует сосредоточиться в Эфириуме. Было Слияние, которое стало огромным начинанием. Все были очень взволнованы. Большинство людей были очень взволнованы. Майнеры — нет. А затем, после Слияния, появились снятия средств. Мы не хотели, чтобы ETH людей были заблокированы в контракте, и чтобы распространялся FUD о том, что они никогда не смогут вывести оттуда свои ETH. Поэтому нам нужно было выпустить это как можно быстрее. А затем был прото-данкшардинг, а потом появилась Пектра, и Пектра была своего рода смесью различных несвязанных EIP и не имела связного нарратива. И она стала такой большой, потому что люди просто пихали туда всё подряд из-за отсутствия сплоченности, так что ее пришлось разделить на два разных форка, потому что команды тестировщиков сказали: «Объем слишком велик. Мы не можем все это протестировать».

И поэтому стимулом для Тима сделать это было: окей, нам нужно придумать способ, чтобы эти форки оставались максимально сфокусированными и связными. И главное предложение (headliner) стало своего рода ответом на это. Смысл заключался в том, чтобы выпускать обновления так, чтобы в приоритете было понимание всеми того, о чем этот форк, чтобы им не приходилось впихивать туда 25 разных EIP.

Другой скриншот наверху — это Тим, предлагающий определения для стадий включения этих EIP. И мысль, которую я хочу донести, заключается в том, что иногда можно услышать, как люди говорят, что этот процесс слишком бюрократичен. Но на самом деле происходит следующее: люди приходят в этот процесс управления и спрашивают: «Как мне внедрить EIP?», а люди, которые находятся там уже 10 лет, отвечают: «Ну, ты просто берешь и делаешь». И люди такие: «Это ужасно». И поэтому эти вещи описывают происходящее, чтобы облегчить участие в этом процессе людям со стороны, потому что если вы просто приходите сюда и говорите: «У меня есть один EIP, меня не волнует управление Эфириумом, я просто хочу внедрить этот один EIP» — вам нужна рубрика, вам нужен контрольный список, вам нужна очень четкая пошаговая инструкция о том, как внедрить этот EIP. Так что большинство этих вещей скорее описывают, как работает процесс, чем создают бюрократические правила, которым люди должны следовать, чтобы усложнить внедрение EIP.

Третья вещь — это коммиты с течением времени на Forkcast. Forkcast — это продукт моей команды, созданный Вольфрамом Марком (Wolfram Mark), парнем из моей команды, который сделал его в середине прошлого года, когда моя команда была сформирована в ее нынешнем виде. И он стал таким каноническим ресурсом, который люди используют для взаимодействия с форком, чтобы увидеть, что входит в форк и как это на них влияет. Всем этим вещам меньше двух лет. Так что я просто хочу сказать, что этот процесс сильно меняется. Он совсем не статичен. Это не какая-то застывшая бюрократия, в которую трудно пробиться.

Сопоставимые системы управления (20:21)

Я хотел бы вкратце коснуться наиболее похожих децентрализованных систем управления, которые я могу сравнить с управлением Эфириумом. И мысль, которую я пытаюсь здесь донести, заключается в том, что это устойчиво — хотя и удивительно, что от 100 до 500 человек могут принимать решения, это устойчиво в реальном мире. Мы действительно видим примеры того, как это работает.

IETF — это Инженерный совет Интернета (Internet Engineering Task Force). Это управляемый добровольцами орган по стандартизации, который создал TCP/IP, HTTP. Это организация, которая несет наибольшую ответственность за то, что сегодня у нас есть свободный интернет. Ядро Linux — это основа операционной системы Linux. Это программное обеспечение с открытым исходным кодом, на котором работают интернет-серверы, телефоны Android, суперкомпьютеры. Разница в том, что у них есть своего рода модель «великодушного диктатора» в лице Линуса Торвальдса (Linus Torvalds). Но даже при этом у них более 17 000 контрибьюторов, что просто поражает воображение.

На что это не похоже: на другие блокчейны, в которых есть ончейн-голосование токенами. Эфириум специально избегает любых механизмов голосования, потому что, на мой взгляд, это открывает пути для захвата контроля и как бы лишает стимула делать систему меритократией, где люди просто доверяют тем, кто пишет лучший код. А еще есть L2-решения. У них есть мультисиги. У них есть советы по безопасности. Это больше похоже на назначаемые должности, которые принимают эти решения. И у этого есть свои компромиссы. Это более централизованно. Зато движется быстрее.

Почему это важно для разработчиков (22:38)

Так почему же разработчиков волнует управление? Потому что разработчики — это буквально те, для кого создан Эфириум. Эфириум создан не для основных разработчиков. Он создан не для валидаторов. Иногда эти люди путаются в этом. Основные разработчики Эфириума и валидаторы служат Эфириуму, который служит разработчикам и пользователям.

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

Как принять участие (24:40)

Итак, как вам принять участие или внедрить свою функцию? Это довольно общий совет, но я думаю, что он лучший. Громко заявляйте о своих болевых точках. Заходите в Twitter, пишите посты в блогах, ищите решения для своих болевых точек. Размышляйте о вещах, которые могли бы вам помочь. Если вы найдете других людей с такими же болевыми точками, как правило, вы сможете найти EIP, который существует для решения этой проблемы, или попросить кого-нибудь помочь вам написать EIP, который это сделает.

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

Я просто оставлю вам несколько ресурсов. Forkcast.org — это место, куда вы можете зайти и посмотреть, что входит в форк, как это влияет на определенных заинтересованных лиц. Так, если вы разработчик приложений, там есть раздел для разработчиков приложений. Если вы разработчик кошельков, разработчик клиента уровня консенсуса, там есть разделы о том, как все это влияет на вас. YouTube — это место, куда загружаются все видео с этих звонков. Они также встроены на страницу forkcast.org/calls, где есть краткие содержания, указания спикеров, так что ориентироваться в этих звонках проще. Каталог EIP, форум Ethereum Magicians, где вы можете пообщаться с другими людьми о потенциальных решениях или EIP, которые вы хотите написать. И очень скоро у моей команды появится сайт поддержки протокола. Он выглядит потрясающе. Но он еще не готов к публикации. Моя электронная почта также указана там — nixo@ethereum.org (opens email client). На этом всё.