Виталик и Йоав любезно просмотрел этот пост, но мое мнение является моим собственным.

Если вы не следили за драмой АА, вот краткий обзор:

• Несколько недель назад EIP-3074, предложение, которое принесло бы пользователям ЭОА многие преимущества АА, было одобрено основными разработчиками для включения в «Пектру», следующую сложную форк Ethereum.
• С тех пор многие в сообществе ERC-4337, особенно сами авторы 4337, были решительно выступали против 3074 на основании @yoav/3074-implications"> проблемы централизации и ее несовместимость с Ethereum@yoav/AA-roadmap-May-2024">AA roadmap, которая сосредоточена вокруг 4337 и его двоюродного брата 7560 (также известного как "родной AA").
• На прошлой неделе Виталик предложил EIP-7702 в качестве альтернативы 3074. В основном он достигает той же цели — приносит пользователям EOA множество преимуществ AA — но таким образом, чтобы он был более совместим с 4337 сегодня, а также с «эндшпилем AA», которым является 7560.
• В настоящее время основные разработчики обсуждают EIP-7702, но предварительные обсуждения и настроения сообщества предполагают, что EIP-7702, скорее всего, заменит EIP-3074 в Pectra.

Лично я был очень доволен результатом: пользователи EOA скоро смогут воспользоваться большинством преимуществ AA, используя инструменты и инфраструктуру, созданные для ERC-4337.

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

В этом посте я хочу:

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

Почему процесс сделал людей несчастными

Вся эта сага сделала многих людей несчастными по нескольким причинам:

• Потребовались годы, чтобы 3074 был одобрен.
• Только после того, как 3074 был окончательно одобрен, разработчики ядра получили огромное количество отказов от сообщества 4337.
  • С другой стороны, сами авторы 4337 неоднократно высказывали свои опасения по поводу 3074 разработчикам ядра, но безрезультатно.
• Теперь мы находимся на пути к отмене утверждения 3074 и замене его другим EIP (7702).

Итак, ни в одном из вышеперечисленных пунктов нет ничего плохого:

• Это нормально, когда дискуссия длится годами.
• EIP может получать push-уведомления после утверждения.
• Можно отменить утверждение EIP после его утверждения, если обнаружены новые проблемы.

Тем не менее, мы, вероятно, можем согласиться с тем, что все могло бы пойти более гладко. Представьте, если бы это выглядело так:

• Сообщество 4337 активно вовлекало основных разработчиков в обсуждение 3074. Теперь возможен только один из двух исходов:
  • Либо 3074 был одобрен (и, возможно, изменен) после учета отзывов сообщества 4337 в счет, и в этом случае сообщество 4337 поддержало бы 3074, и мы бы не отменили 3074.
  • Или 3074 так и не был одобрен, но сообщество 4337 и основные разработчики работали вместе, чтобы создать предложение, которое всех устраивает, а-ля 7702.

Голос каждого слышен, и нет никаких драматических разворотов. Это было бы неплохо — так почему же этого не произошло?

Что пошло не так?

Размышляя об этом процессе, обе стороны дебатов указывают пальцем друг на друга.

Основные разработчики (и авторы EIP-3074) считали, что это вина «4337 человек» в том, что они не участвовали активно в процессе All Core Devs (ACD), где EIP обсуждаются в течение лонг времени, прежде чем они будут окончательно приняты клиентскими командами и, таким образом, внедрены в Протокол.

Утверждается, что в любой момент этого обсуждения «4337 человек» могли прийти и выразить свою озабоченность, а не ждать, пока 3074 уже не будет одобрен. В конце концов, процесс ACD хорошо задокументирован, встречи открыты для всех, и есть такие люди, как Тим Бейко, которые активно публикуют резюме в Твиттере после каждого заседания ACD. Итак, если 4337 человек так сильно заботились об этой проблеме, почему они не потратили время на то, чтобы принять в ней участие?

С другой стороны, команда АА (4337 авторов) отметила, что они посещали собрания ACD и при каждом удобном случае отказывались от 3074, но разработчики ядра не слушали. Что касается сообщества 4337, то оно в основном чувствовало себя застигнутым врасплох — большинство людей были под впечатлением, что 3074 мертв, и даже не знали, что 3074 активно рассматривается для включения.

Многие люди также считали, что процесс ACD был слишком непрозрачным и недружелюбным для участия людей, которые имеют «реальную работу» и не могут позволить себе идти в ногу со всеми обновлениями ACD. Некоторые также высказали мнение, что ACD должен активно искать обратную связь от соответствующих заинтересованных сторон, в данном случае от сообщества 4337.

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

Основная причина

Реальная причина сбоя управления заключалась в том, что, вопреки распространенному мнению, ACD НЕ является единственным органом управления для Протокол обновлений, и в данном случае он был переопределен другим органом управления.

Проблематично то, что другая власть управления редко признается, несмотря на то, что она имеет даже большее влияние, чем ACD, на наиболее важные вопросы Ethereum, такие как AA и масштабирование.

В этой статье я назову эту власть «дорожными картами».

Вся эта сага о 3074/7702, как я покажу, является не более и не менее, чем примером того, как сила дорожных карт подавляет мощь ACD. И если мы говорим об управлении, то каждый раз, когда мы замечаем, что невидимая сила подавляет видимую силу, мы должны быть очень обеспокоены, потому что то, что невидимо, не поддается учету, и поэтому должно быть выявлено.

Что такое дорожная карта?

Кто-либо в Ethereum сообществе, должно быть, часто сталкивался с термином «дорожная карта», например, в «дорожной карте, ориентированной на свертку», «дорожной карте ETH 2.0» или в этих дебатах «@yoav/AA-roadmap-May-2024">the AA roadmap".

Поиск «дорожной карты» на Ethereum Magicians

Чтобы проиллюстрировать мою точку зрения, давайте представим себе собрание ACD, на котором основные разработчики обсуждают, как масштабировать Ethereum:

• Core Dev Bob: Я поддержка EIP 1234, в котором предлагается, чтобы мы ускорить время блока 10 раз, увеличить размер блока в 10 раз и Падение комиссию 100X.
• Другие основные разработчики: ... Вы с ума сошли?

Давайте на секунду задумаемся. Почему разработчики ядра просто отвергли то, что сказал Боб? Он просто предложил очень законную форму масштабирования. Solana и многие другие L1 делают это с большим эффектом масштабирования.

Причина, конечно же, в том, что эта воображаемая EIP идет вразрез с собственной дорожной картой масштабирования Ethereum "rollup-centric", в которой, среди прочего, говорится, что для децентрализации блокчейна крайне важно, чтобы обычные пользователи могли запускать узел, и поэтому о воображаемом EIP не может быть и речи, поскольку он значительно увеличил бы барьер для запуска узла.

Что я хотел проиллюстрировать этим примером, так это то, что основные разработчики, которые участвуют в процессе ACD и принимают решения об обновлениях протоколов, руководствуются высшей силой, которую я называю дорожными картами. Есть дорожная карта масштабирования, дорожная карта AA, дорожная карта MEV, вы называете это - и все вместе они образуют дорожную карту Ethereum, на которой основные разработчики основывают свои решения.

Когда основные разработчики не соответствуют дорожной карте

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

В случае с AA сам Виталик настаивал на дорожной карте AA, ориентированной на 4337, на @vbuterin/счет_abstraction_roadmap">несколько раз <a href="https://www.youtube.com/watch?v=iLf8qpOmxQc&t=2461s">, но в целом это была в основном команда 4337, в частности Йоав и Дрор, которые отстаивали дорожную карту 4337, ориентированную на 4337, на конференциях, онлайн-форумах и встречах ACD.

Однако, несмотря на эти усилия, некоторые основные разработчики выступили против дорожной карты AA, ориентированной на 4337. Они посчитали, что 7560, нативная версия 4337, которую в конечном итоге должны были внедрить клиенты, является чрезмерно сложной и не единственным жизнеспособным кандидатом на роль «эндшпиля АА». В конце концов, ACD решил одобрить 3074, несмотря на возражения команды 4337, что это фрагментирует экосистему AA, создав альтернативу и @yoav/3074-implications"> менее децентрализованный стек технологий AA.

Однако, как только 3074 была одобрена, последовала сильная реакция со стороны всего сообщества 4337, что вынудило основных разработчиков вновь принять участие в дебатах по 3074. Затем дебаты зашли в тупик, где ни авторы 4337, ни авторы 3074 не могли убедить друг друга, пока Виталик не вмешался в одиннадцатый час и не предложил EIP-7702 в качестве альтернативы 3074, которая явно совместима с ориентированным на 4337 «эндшпилем АА», и тем самым подтолкнул конфликт в пользу дорожной карты АА.

Роль Виталика

Несмотря на то, что Виталик ведет себя как исследователь, эта сага ясно показывает, что Виталик обладает качественно иной властью управления, чем другие исследователи. Поэтому напрашивается вопрос — какую роль играет Виталик в управлении Ethereum?

Лично мне полезно думать о Виталике как о CTO очень, очень большой компании.

(Кстати, в этой компании нет генерального директора.)

Если вы работали в какой-либо технологической компании, в которой, скажем, более 50 человек, вы знаете, что технический CTO не может участвовать в каждом техническом решении. В определенном масштабе технические решения неизбежно становятся децентрализованными — как правило, для каждой области продукта компании существует подкоманда, и подкоманда в основном свободна принимать свои собственные решения относительно конкретных деталей реализации.

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

CTO, однако, определяет техническое видение компании. Реализация видения остается на усмотрение разработчиков.

Хотя это не идеальная аналогия, я думаю, что она достаточно точно отражает роль Виталика в экосистеме. Виталик не участвует во всех технических решениях — он не может этого делать. Он также не является ведущим экспертом во всех областях. Но он оказывает огромное влияние на разработку дорожных карт для всех критически важных аспектов Ethereum (масштабирование, AA, Proof-of-Stake...) не только из-за своего технического опыта, но и потому, что он является окончательным судьей того, соответствует ли дорожная карта видению Ethereum — его видению.

Каждый успешный продукт начинается с видения

Если мое мнение о том, что Виталик является CTO Ethereum, недостаточно спорно для вас, то вот самая спорная часть: мы должны принять Виталика как CTO.

Мое мнение как основателя стартапа заключается в том, что за каждым успешным продуктом — и да, Ethereum является «продуктом» в том смысле, что он решает реальные проблемы для реальных людей — должно быть последовательное видение. И последовательное видение обязательно должно быть задано небольшим количеством людей, например, основателями стартапа, и часто только одним основателем.

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

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

И, по правде говоря, можете ли вы жаловаться? Когда вас привлекла экосистема Ethereum ее открытостью, сопротивлением цензуре и темпами инноваций — вы жаловались, что все началось с видения Виталика? Может быть, вы этого не сделали, потому что не думали об этом в таком ключе, но теперь, когда вы это сделали, вы действительно возражаете?

Как насчет децентрализации?

Но, скажете вы, а как же децентрализация? Если один человек обладает такой подавляющей властью над Ethereum, как мы можем утверждать, что он децентрализован?

Чтобы ответить на этот вопрос, мы должны вернуться к @VitalikButerin/the-sense-of-decentralization-a0c92b76a274">эта классическая статья о смысле децентрализации, написанная, кхм, кхм, Виталиком. Ключевой вывод статьи заключается в том, что существует три типа децентрализации:

• Архитектурная децентрализация: сколько узлов может быть скомпрометировано, прежде чем система перестанет функционировать?
• Логическая децентрализация: могут ли подсистемы системы развиваться независимо друг от друга, сохраняя при этом функционирование системы? Или они должны быть тесно скоординированы?
• Политическая децентрализация: сколько людей или организаций в конечном итоге контролируют эту систему?

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

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

Тем не менее, я считаю, что если мы хотим, чтобы Ethereum продолжал внедрять инновации, мы должны принять Виталика в качестве де-факто CTO, даже если это означает пожертвовать некоторой политической децентрализацией.

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

Без такой фигуры, как Виталик, возможны только два исхода, оба ярко проиллюстрированы этой сагой 3074:

• Управление Ethereum может превратиться в бесконечные тупики, где ни одна из сторон не желает идти на компромисс, и никто не сможет добиться какого-либо прогресса, как видно из того, как дебаты 3074 зашли в тупик, пока не пришел Виталик.
• Или Ethereum может превратиться в монстра Франкенштейна с непоследовательными конструкциями, на что указывает то, насколько мы были близки к тому, чтобы 3074 и 4337 служили двумя параллельными стеками AA, которые в значительной степени несовместимы.

Роль сообщества Мы

очень близки к тому, чтобы иметь полную ментальную модель Ethereum управления, но есть одно вопиющее упущение в нашем обсуждении до сих пор — сообщество.

Если Виталик определяет видение, за которым следуют дорожные карты, определяемые исследователями, которые, в свою очередь, реализуются основными разработчиками — какую роль играет сообщество? Неужели не ничего??

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

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

Модель управления Ethereum VVRC

Итак, вот полная ментальная модель управления Ethereum, которую я называю ценностями ⇒ видением ⇒ дорожными картами ⇒ клиентами, или VVRC для шорт:

• V == Ценности == Сообщество
• V == Видение == Виталик
• Р == Дорожные карты == Исследователи
• C == Клиенты == Основные разработчики

Вместе они работают следующим образом:

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

Плохо нарисован новым GPT-4o.
Она отказалась рисовать слово «Виталик» из-за «контентной политики».

Конечно, реальность намного более запутанная, чем может охватить любая простая модель. Например, core devs в реальности — это единственные люди, которые могут «голосовать» за любые решения, в силу реализации клиентов. Виталик и другие исследователи выполняют только консультативную роль, и иногда их вклад не принимается основными разработчиками, поэтому 3074 был одобрен.

Тем не менее, я думаю, что модель VVRC разумно отражает то, как работает управление Ethereum в счастливом случае, и мы должны «отладить» процесс, чтобы он не потерпел неудачу, как это было с 3074.

Как мы можем улучшить управление Ethereum

Теперь, когда у нас есть ментальная модель того, как должно работать Ethereum управление, вот несколько идей по улучшению процесса управления, чтобы мы могли избежать хлыстовой травмы, которую мы испытали с 3074/7702.

• Необходимо обеспечить большую прозрачность для EIP, которые активно рассматриваются для включения. Сообщество в целом никогда не должно быть «застигнуто врасплох» тем, что EIP принимается, как это было в случае с 3074.
  • Вопреки тому, что можно было бы ожидать, "статус" EIP на сайте не отражает его статус в процессе ACD. Вот почему он по-прежнему говорит, что 3074 находится в «Обзоре», хотя основные разработчики уже проголосовали за его одобрение, и было еще меньше признаков того, что он когда-либо рассматривался для включения в первую очередь.
  • В идеале EF должен громко и ясно заявить об этом в социальных сетях, когда EIP вот-вот будет принят, чтобы повысить осведомленность сообщества.
• Иногда основные разработчики могут недооценивать влияние, которое тот или иной EIP оказывает на последующие проекты и пользователей, как в случае с 3074 и сообществом 4337. Поскольку собрания ACD ограничены по времени и должны координироваться в разных часовых поясах, понятно, что на них должен выступать только «релевантный человек». Тем не менее, возможно, имеет смысл время от времени выделять время для членов сообщества, чтобы они могли прокомментировать последующее влияние определенных предложений EIP.
  • Если исследователи чувствуют, что их вклад не принимается основными разработчиками, как это было в случае с командой 4337, они могут привлечь членов сообщества, чтобы укрепить свои аргументы.
• Важно отметить, что между основными разработчиками и исследователями должно быть взаимное признание того, что они оба обладают властью управления, хотя и с разными сильными сторонами. «Клиентская власть» основных разработчиков — это единственная власть, которая действительно может «голосовать» за счет реализации клиентов. «Сила дорожной карты» исследователей обычно пользуется большей общественной поддержкой благодаря тому, что исследователи активно говорят и пишут о своих дорожных картах.
  • Когда две силы противоречат друг другу, у основных разработчиков может возникнуть соблазн просто переубедить исследователей, например, когда основные разработчики преодолели возражения команды 4337. Тем не менее, переопределение как таковое может привести к хлыстовой травме, поскольку власти нестабильны, когда они находятся в конфликте, как видно из последовавшей драмы после утверждения 3074.
  • Точно так же, сталкиваясь с сопротивление, у исследователей может возникнуть соблазн просто отказаться от взаимодействия с основными разработчиками, что является одной из причин, почему был создан процесс RIP и почему нативный AA (7560) теперь в основном продвигается как RIP, а не EIP. Несмотря на то, что есть реальные преимущества в том, чтобы помочь L2 экспериментировать с обновлениями протоколов, которые слишком противоречивы для L1, мы не можем рассматривать RIP как замену взаимодействию с процессом управления EIP. Исследователи должны продолжать взаимодействовать с основными разработчиками до тех пор, пока они не будут полностью согласованы с дорожными картами.

Заключение

Сага 3074/7702 проливает свет на то, как на самом деле работает Ethereum управление — что помимо явной власти управления, которой является процесс EIP/ACD, управляемый основными разработчиками, существует также неявная сила управления дорожными картами, управляемыми исследователями. Когда эти силы становятся несогласованными, мы видим тупиковые ситуации и хлысты, и может потребоваться другая сила — Виталик — чтобы склонить чашу весов в ту или иную сторону.

Затем мы приводим доводы в пользу того, что Виталик представляет собой особую силу, которая является «видением» Ethereum, которое является основой легитимности для любых дорожных карт. Мы сравниваем Виталика с CTO в крупной компании и признаем, что его роль в качестве псевдо-CTO необходима Ethereum, чтобы поддерживать темп инноваций, не вырождаясь в систему Франкенштейна с непоследовательными конструкциями.

Наконец, мы представляем ментальную модель для размышлений о Ethereum управлении как о VVRC: ценности (сообщество) ⇒ видение (Виталик) ⇒ дорожные карты (исследователи) ⇒ клиенты (основные разработчики). Затем мы предлагаем различные способы исправления «ошибок», которые иногда приводят к отклонению процесса от этой модели на практике.

Ethereum управление — это «машина, которая строит машину» — чтобы сделать Ethereum правильно, мы должны правильно управлять ею. Таким образом, 3074 стал бесценным примером того, когда управление пошло не так, и я надеюсь, что смог извлечь из него несколько полезных уроков, чтобы мы могли улучшить управление Ethereum в будущем.

Отказ от ответственности:

1. Эта статья перепечатана из [zerodev]. Все авторские права принадлежат оригинальному автору [derek]. Если у вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они оперативно разберутся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, принадлежат исключительно автору и не являются какими-либо инвестиционными рекомендациями.
3. Переводом статьи на другие языки занимается команда Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.