Віталік і Йоав люб'язно переглянув цей пост, але думки мої власні.

Якщо ви не стежили за драмою АА, ось короткий підсумок:

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

Особисто я був дуже задоволений результатом: користувачі EOA скоро зможуть користуватися більшістю переваг АА, використовуючи інструменти та інфраструктуру, створені для ERC-4337.

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

У цьому блозі я хочу:

• Визначте, що пішло не так у процесі.
• Запропонуйте ментальну модель для осмислення Ethereum управління.
• Запропонуйте покращення, щоб уникнути подібних збоїв в управлінні в майбутньому.

Чому цей процес зробив людей нещасними

Вся ця сага зробила багатьох людей нещасними з кількох причин:

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

У цьому немає нічого поганого:

• Це нормально, коли дискусія триває роками.
• Це нормально, коли EIP отримує відсіч після того, як його затвердять.
• Можна скасувати схвалення 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, такі як АА та масштабування.

У цій статті я буду називати цю владу «дорожніми картами».

Вся ця сага 3074/7702, як я буду стверджувати, не більше і не менше, ніж приклад того, як сила дорожніх карт переважає над силою ACD. І якщо ми говоримо про управління, то кожного разу, коли ми помічаємо, що невидима сила переважає над видимою силою, ми повинні бути дуже стурбовані, бо те, що є невидимим, є непідзвітним, а отже, має бути висловлене на світло.

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

Будь-хто в Ethereum-спільноті, мабуть, часто стикався з терміном «дорожня карта», наприклад, у «дорожній карті, орієнтованій на зведення», «дорожній карті ETH 2.0» або в цій дискусії «@yoav/AA-roadmap-May-2024">дорожня карта АА".

Пошук «дорожньої карти» на Ethereum Magicians

Щоб проілюструвати мою думку, уявімо зустріч ACD, на якій основні розробники обговорюють, як масштабувати Ethereum:

• Core Dev Bob: Я підтримка EIP 1234, який пропонує нам прискорити час блоку 10 разів, збільшити розмір блоку в 10 разів і Падіння 100X.
• Інші основні розробники: ... Ви з глузду з'їхали?

Давайте на секунду подумаємо. Чому основні розробники просто збили те, що сказав Боб? Він просто запропонував цілком законну форму масштабування. Solana та багато інших L1 роблять це, з чудовим ефектом масштабування.

Причина, звичайно, полягає в тому, що цей уявний EIP суперечить власній дорожній карті масштабування Ethereum "Rollup-centric", яка, серед іншого, говорить, що має вирішальне значення для децентралізації блокчейну, щоб звичайні користувачі могли керувати вузлом, і тому про уявну EIP не може бути й мови, оскільки це значно збільшило б бар'єр для запуску вузла.

На цьому прикладі я хотів проілюструвати, що основні розробники, які беруть участь у процесі ACD і приймають рішення про протокол оновлення, керуються вищою силою, яку я називаю дорожніми картами. Є дорожня карта масштабування, дорожня карта АА, дорожня карта MEV, що завгодно — і разом вони формують Ethereum дорожню карту, на якій основні розробники базують свої рішення.

Коли розробники ядра не узгоджуються з дорожньою картою

Оскільки дорожні карти не є формальною частиною управління, немає гарантії, що основні розробники дотримуються їх. Зокрема, оскільки не існує формального процесу «затвердження» дорожньої карти, не всі дорожні карти сприймаються як такі, що мають однакову легітимність. Дослідники, які стоять за дорожніми картами, повинні старанно відстоювати свої дорожні карти перед основними розробниками та ширшою спільнотою, ордер отримати легітимність і, отже, підтримку з боку основних розробників.

У випадку з АА, сам Віталік наполягав на розробці дорожньої карти АА, орієнтованої на 4337, на @vbuterin/рахунок_abstraction_roadmap">multiple випадках, але в цілому в основному це була команда 4337, зокрема Йоав і Дрор, які відстоюють дорожню карту АА, орієнтовану на 4337, на конференціях, онлайн-форумах і зустрічах ACD.

Однак, незважаючи на ці зусилля, деякі розробники ядра виступили проти дорожньої карти АА, орієнтованої на 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-meaning-of-decentralization-a0c92b76a274">ця класична стаття про значення децентралізації, написана Віталіком. Ключовий висновок статті полягає в тому, що існує три види децентралізації:

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

З огляду на ці визначення, Ethereum явно є архітектурно децентралізованим, і, ймовірно, справедливо буде сказати, що він також логічно децентралізований, враховуючи відсутність міцного зв'язку між різними його компонентами (наприклад, консенсус проти виконання).

З точки зору політичної децентралізації, хороша новина полягає в тому, що жодна людина чи організація не може закрити Ethereum, навіть Віталік. Однак можна стверджувати, що Ethereum не така політично децентралізована, як можна було б подумати, враховуючи помітну роль, яку відіграє Віталік у визначенні свого бачення і, таким чином, у визначенні дорожніх карт.

Однак, на мою думку, якщо ми хочемо, щоб Ethereum продовжували впроваджувати інновації, ми повинні прийняти Віталіка як де-факто CTO, навіть якщо це означає пожертвувати певною політичною децентралізацією.

Якщо Ethereum коли-небудь «закостеніє» в майже незмінний блокчейн, такий як Біткойн, то Віталік може піти на пенсію. Але перш ніж ми дійдемо до цього фіналу, дуже важливо, щоб існував авторитет, якого поважають усі сторони, якому довіряють приймати рішення щодо технічних рішень не лише на основі технічних переваг, а й на основі того, чи відповідають вони баченню Ethereum.

Без такої постаті, як Віталік, можливі лише два результати, обидва яскраво проілюстровані цією сагою 3074 року:

• Ethereum управління може розчинитися в нескінченних глухих кутах, де жодна зі сторін не бажає йти на компроміс і ніхто не може досягти прогресу, як видно з того, як дебати 3074 зайшли в глухий кут, поки не прийшов Віталік.
• Або Ethereum може стати монстром Франкенштейна з незв'язними конструкціями, на що вказує те, наскільки близько ми були до того, щоб 3074 і 4337 служили двома паралельними стеками АА, які в значній мірі несумісні.

Роль спільноти

Ми дуже близькі до того, щоб мати повну ментальну модель Ethereum управління, але є одне кричуще упущення в нашій дискусії — спільнота.

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

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

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

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

Отже, ось повна ментальна модель управління Ethereum, яку я називаю цінностями ⇒ бачення ⇒ дорожніми картами ⇒ клієнтською моделлю, або VVRC для шорт:

• V == Цінності == Спільнота
• V == Бачення == Віталік
• Р == Дорожні карти == Дослідники C
• == Клієнти == Основні розробники

Разом вони працюють так:

• Спільнота гуртується навколо певних цінностей.
• Віталік формулює бачення, яке відповідає цим цінностям.
• Дослідники розробляють дорожні карти відповідно до бачення.
• Core розробники впроваджують клієнтів на основі дорожніх карт.

Погано малює новий 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: цінності (спільнота) ⇒ бачення (Віталік) ⇒ дорожні карти (дослідники) ⇒ клієнти (core devs). Потім ми пропонуємо різні способи виправлення «багів», які іноді призводять до того, що процес відхиляється від цієї моделі на практиці.

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

Відмова від відповідальності:

1. Ця стаття передрукована з [zerodev]. Усі авторські права належать оригінальному автору [derek]. Якщо є заперечення проти цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно впораються з цим.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є жодною інвестиційною порадою.
3. Переклад статті на інші мови здійснює команда Gate Learn. Якщо не зазначено, копіювання, розповсюдження або плагіат перекладених статей заборонено.