Переслайте оригінальну назву «Роздуми про управління Ethereum після саги 3074»

Анотація: Стаття є заявою Дерека Чіанга, генерального директора ZeroDev, у відповідь на пропозицію V EIP-7702 збалансувати протиріччя між ERC-4337 та EIP-3074. Написана з точки зору засновника проєкту в екосистемі АА, вона об'єктивно висвітлює поточну модель управління Ethereum та її больові точки. Дерек лаконічно зазначає:

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

Підтвердивши роль Віталіка, Дерек описує покращення, які Ethereum повинен внести у свою модель управління, пропонуючи цінну інформацію як для спільнот Ethereum, так і для Bitcoin.

Текст:

Якщо ви раніше не були знайомі з подіями, пов'язаними з абстракцією облікового запису Ethereum (AA), ось короткий підсумок: Кілька тижнів тому основні розробники Ethereum схвалили пропозицію EIP-3074 для включення в наступний хардфорк «Pectra». Ця пропозиція вводить два нові коди операцій у віртуальну машину Ethereum (EVM), що дозволяє зовнішнім обліковим записам Ethereum (EOA) мати майже нативний досвід АА. З тих пір багато членів спільноти ERC-4337, особливо його прихильники, рішуче виступають проти EIP-3074, посилаючись на занепокоєння з приводу потенційних ризиків безпеки та його несумісності з дорожньою картою AA Ethereum. У попередній дорожній карті Ethereum ERC-4337 та подібні пропозиції, такі як 7560 (також відомий як «nativeAA»), були центральними. На початку травня Віталік запропонував EIP-7702 як альтернативу EIP-3074, встановивши баланс між 4337 і 3074, забезпечуючи досвід АА для користувачів EOA, зберігаючи певною мірою сумісність з ERC-4337, а також сумісність з «остаточним рішенням АА» 7560. Наразі основні розробники Ethereum розглядають наслідки EIP-7702, і попередні обговорення та настрої спільноти вказують на те, що EIP-7702, ймовірно, замінить EIP-3074, згаданий раніше. Я дуже задоволений таким результатом: користувачі EOA скоро зможуть випробувати різні продукти в екосистемі ERC-4337 і користуватися більшістю переваг AA. Однак я не можу не відчувати, що міг би бути кращий спосіб досягти цих результатів, як багато хто зазначав останніми тижнями. Я вважаю, що з кращим процесом управління ми могли б заощадити багато енергії та швидше досягти бажаного результату. У цій статті я хотів би:

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

Висновки та роздуми щодо інциденту з EIP-3074

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

• Це нормально, коли обговорення EIP триває кілька років.
• Це нормально, коли затверджений EIP відхиляється після цього.
• У разі виявлення нових проблем схвалення EIP може бути відкликано після затвердження.

Однак все могло бути простіше. Уявімо, якби все розвивалося так: під час обговорення 3074 спільнота 4337 активно взаємодіяла з основними розробниками Ethereum. Якщо ця передумова справедлива, то можливі лише два варіанти:

• Після розгляду відгуків спільноти 4337, пропозиція 3074 схвалюється (і, можливо, змінюється). У цьому випадку спільнота 4337 прийме 3074, а основній команді Ethereum не потрібно буде відкликати 3074.
• Крім того, 3074 ніколи не схвалюється, але спільнота 4337 і основна команда Ethereum спільно пропонують рішення, яке задовольняє всіх, подібно до 7702. Голоси всіх чують, і немає різкого розвороту. Це було б ідеально, так чому ж цього не сталося?

Що пішло не так?

Озираючись назад на весь процес, обидві сторони звинувачують одна одну. Розробники ядра Ethereum (а також автори EIP-3074) вважають, що в цьому винні «прихильники 4337», оскільки вони не брали активної участі в процесі обговорення All Core Developers (ACD). У цьому процесі EIP повинні пройти тривалі обговорення і, зрештою, бути прийнятими та впровадженими командами розробників клієнтів Ethereum, такими як Geth. Дехто стверджує, що в період, коли EIP-3074 розглядався, «4337 прихильників» могли взяти участь і висловити свою думку, замість того, щоб критикувати його після того, як він вже був затверджений. Зрештою, весь процес ACD є прозорим, зустрічі відкриті для всіх, а такі люди, як Тім Бейко, постійно публікують підсумкові твіти після кожного засідання ACD. Отже, якщо «4337 прихильників» так переймалися цією темою, чому вони не брали активної та оперативної участі у відповідних зустрічах?

З іншого боку, члени ядра 4337 вказують, що вони брали участь у засіданнях ACD і виступали проти 3074, наскільки це було можливо, але розробники ядра Ethereum не прислухаються. Що стосується 4337 членів спільноти, то багато хто відчував себе засліпленим — багато хто думав, що 3074 вже мертвий, а деякі навіть не знали, що 3074, швидше за все, буде затверджений. Багато хто вказує на те, що весь процес зустрічей ACD непрозорий і не дружній до тих, хто «серйозний» у спільноті Ethereum, але не може встигати за оновленнями ACD у режимі реального часу. Деякі також вважають, що ACD має активно шукати зворотний зв'язок від зацікавлених сторін (тут мається на увазі спільнота 4337).

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

Першопричина нещасних випадків в управлінні: дорожня карта

Всупереч поширеній думці, основна причина нещасних випадків з управлінням полягає в тому, що ACD не є єдиним органом управління для оновлень протоколу Ethereum; Його замінив інший орган управління. Проблема полягає в тому, що, незважаючи на більший вплив, ніж ACD, на основні питання Ethereum (такі як AA та масштабованість), цей інший орган управління рідко визнається. У цій статті я буду називати цей тип влади «дорожньою картою». Як я зазначу нижче, вся подія помилки в управлінні «3074-4337-7702» є випадком того, що існуюча потужність дорожньої карти Ethereum переважає потужність ACD. Якщо ми говоримо про управління, то, коли ми помічаємо, що нематеріальна сила переважає над матеріальною, ми повинні бути надзвичайно стурбовані, тому що нематеріальні речі часто важко пояснити і не можуть бути легко помічені багатьма людьми, тому вони повинні бути викриті.

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

Будь-хто в спільноті Ethereum, напевно, часто чув термін «дорожня карта», чи то в «дорожній карті ETH2.0», чи в контексті «дорожньої карти АА», пов'язаної з цією подією.

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

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

Давайте поміркуємо ось над цим. Чому основна команда Ethereum відхиляє те, що пропонує Боб? Він просто пропонує, здавалося б, розумний спосіб масштабування, що зробили багато публічних мереж, таких як Solana, Aptos, Sui та інші, досягнувши високого TPS. Причина в тому, що цей вигаданий EIP-1234 суперечить дорожній карті масштабування Ethereum, орієнтованій на зведення. У цій дорожній карті наголошується, що для децентралізації звичайні користувачі повинні мати можливість запускати вузли з низькими витратами. Тому вигаданий EIP-1234 навряд чи буде прийнятий, оскільки він значно збільшить вартість запуску вузлів Ethereum. Я хочу використати цей приклад, щоб проілюструвати, що основні розробники, які беруть участь у процесі управління ACD і приймають рішення про оновлення протоколу, керуються силами вищого рівня, які я називаю «дорожньою картою». В даний час навколо дорожньої карти Ethereum існують «дорожні карти масштабування», «дорожні карти АА», «дорожні карти MEV» і так далі. Вони в сукупності формують загальну дорожню карту Ethereum, і основні розробники повинні приймати рішення на основі цієї основи.

Коли погляди основних розробників не збігаються з дорожньою картою

Оскільки дорожня карта не є формальною частиною процесу управління Ethereum, часто немає гарантії, що основна команда дотримуватиметься її. Крім того, немає формального процесу «затвердження» дорожньої карти, тому не всі дорожні карти мають однаковий рівень «ортодоксальності». Дослідники, які стоять за дорожньою картою Ethereum, повинні наполегливо працювати, щоб просувати свою дорожню карту серед основних розробників і спільноти, щоб отримати «ортодоксальність» і підтримку з боку основної команди розробників Ethereum. Що стосується АА та абстракції облікових записів, сам Віталік неодноразово виступав за дорожню карту АА, орієнтовану на 4337, але в цілому це в основному команда, яка стоїть за 4337, особливо Йоав і Дрор, які виступають за дорожню карту АА, орієнтовану на 4337, на форумах і на зборах ACD.

Однак, незважаючи на ці зусилля, деякі розробники ядра Ethereum все ще рішуче виступають проти дорожньої карти АА, орієнтованої на 4337. Вони вважають, що 7560 (нативна версія 4337, яка буде реалізована клієнтами Ethereum в майбутньому) є занадто складним і не єдиним життєздатним рішенням для «ендшпілю АА». Врешті-решт, ACD вирішила схвалити пропозицію 3074, незважаючи на опір з боку команди 4337, яка вважала, що 3074 зруйнує всю екосистему АА. Після того, як 3074 було схвалено, вся спільнота 4337 різко відреагувала, змусивши основних розробників Ethereum знову вступити в обговорення 3074. Потім дискусія зайшла в глухий кут, і автори 4337 і 3074 не змогли переконати один одного. Віталік в останню хвилину запропонував EIP-7702 як альтернативу 3074, який явно враховує «ендшпіль АА», орієнтований на 4337, таким чином вирішуючи конфлікт і узгоджуючи остаточний результат з дорожньою картою АА.

Роль Віталіка: де-факто технічний директор Ethereum

Незважаючи на те, що Віталік ідентифікує себе як дослідника, наведена вище історія чітко вказує на те, що Віталік володіє повноваженнями управління, відмінними від інших дослідників. Отже, виникає питання: яку роль відіграє Віталік в управлінні Ethereum? Особисто я вважаю, що було б недоречно розглядати Віталіка як де-факто технічного директора дуже великої компанії (до речі, якщо припустити, що Ethereum — це «компанія» без генерального директора, яка б відповідала дійсності). Якщо ви коли-небудь працювали в технологічній компанії зі штатом понад 50 співробітників, ви знаєте, що технічний директор не може брати участь у кожному технічному рішенні. У міру зростання компанії процеси прийняття рішень щодо різних технічних рішень неминуче стають децентралізованими — як правило, кожна сфера продукту/бізнесу компанії має спеціальну команду, яка часто має автономію у прийнятті рішень щодо деталей рішення. Крім того, технічний директор не може бути головним експертом у всіх (або будь-яких) темах. У компанії можуть бути інженери, які краще розбираються в конкретних областях, ніж технічний директор, тому в дискусіях про технічні деталі рішень часто остаточні рішення приймають окремі інженери. Однак технічний директор задає технічне бачення компанії. Виконання бачення залишається за розробниками. Хоча це не ідеальна аналогія, я вважаю, що вона розумно відображає роль Віталіка в екосистемі Ethereum. Віталік не бере участі в кожному технічному рішенні, можливо, не міг. Він також не є провідним експертом у всіх сферах. Але він має величезний вплив на створення дорожньої карти для всіх важливих рішень Ethereum (масштабування, AA, POS...) не тільки завдяки своєму технічному досвіду, але й тому, що він є остаточним суддею щодо того, чи відповідає дорожня карта баченню Ethereum (його баченню).

Кожен успішний продукт починається з бачення

Якщо розгляд Віталіка як технічного директора Ethereum недостатньо суперечливий, ось найбільш суперечлива частина: ми повинні прийняти Віталіка як технічного директора. Як засновник стартапу, я вважаю, що кожен успішний продукт повинен мати послідовне довгострокове бачення — так, Ethereum також є «продуктом», тому що він вирішує реальні проблеми реальних користувачів. Узгоджене бачення має бути створене кількома людьми, наприклад, засновниками стартапу, і, як правило, засновник лише один. Принадність Ethereum полягає в тому, що, незважаючи на те, що це надзвичайно складна система з такою кількістю компонентів, усі ці компоненти плавно об'єднуються, щоб сформувати добре функціонуючий децентралізований комп'ютер, який щодня здійснює транзакції на мільярди доларів. Ми зайшли так далеко не через схеми дизайну якогось комітету, а тому, що Віталік, завдяки своїй далекоглядності та проникливості, активно забезпечив лідерство, дозволивши нам створити сьогоднішній цілісний і витончений Ethereum. Ethereum – це ідея, яку Віталік запропонував у 2015 році, і вона залишається такою. Звичайно, це не для того, щоб применшити внесок інших дослідників та інженерів – сьогодні вони зробили основну частину досягнень Ethereum. Однак це не суперечить, тому що Ethereum є реалізацією бачення Віталіка, на величину більшою, ніж бачення будь-кого іншого. Чесно кажучи, чи можна на це поскаржитися? Коли вас приваблює відкритість, опір цензурі та швидкість інновацій екосистеми Ethereum, ви коли-небудь скаржилися, що це випливає з бачення Віталіка? Можливо, ви не скаржилися, тому що не думали про це таким чином, але тепер, коли ви це зробили, чи не заперечуєте ви проти цього питання?

Як вирішити проблему децентралізації?

Але ви можете запитати, а як же децентралізація? Якщо одна людина має таку переважну владу над Ethereum, як ми можемо сказати, що він децентралізований? Щоб відповісти на це питання, ми повинні повернутися до класичної статті Віталіка про значення децентралізації. Ключові висновки статті полягають у тому, що децентралізація буває трьох видів:

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

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

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

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

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

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

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

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

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

Таким чином, ось повний спосіб мислення управління Ethereum, скорочено VVRC:

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

Разом вони грають такі ролі:

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

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

Як покращити модель управління Ethereum

Тепер, коли у нас є ментальна модель того, як працює процес управління Ethereum, ось кілька ідей щодо покращення процесів управління:

Необхідно збільшити видимість прогресу обговорення для ЕІП, що розглядаються. Уся спільнота не повинна бути «здивована» прийняттям EIP, і несподівані схвалення, такі як EIP-3074, не повинні повторюватися. Поточний «статус» ЕІП на веб-сайті ЕІП не відображає їх статус у процесі ACD. Ось чому в ньому все ще говориться, що EIP-3074 «знаходиться на розгляді», незважаючи на те, що основні розробники проголосували за його схвалення, без жодних ознак того, що він коли-небудь розглядався для затвердження з самого початку. В ідеалі, коли EIP збирається прийняти, Ethereum Foundation має зробити остаточне публічне оголошення в соціальних мережах, щоб підвищити обізнаність спільноти.

Іноді розробники ядра можуть недооцінювати вплив конкретних EIP на подальші проєкти та користувачів, як це було у випадку зі спільнотами 3074 та 4337. У зв'язку з обмеженим часом засідань ACD та необхідністю координації між часовими поясами, на засіданнях часто може виступати лише «відповідний персонал». Тим не менш, було б доцільно час від часу виділяти час для виступів перед членами спільноти, щоб прокоментувати вплив певних пропозицій EIP на подальші проекти після їх затвердження. Якщо дослідники відчувають, що їхня думка не була прийнята основними розробниками, як це було у випадку з 4337, вони можуть запросити членів спільноти підкріпити свої аргументи.

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

Коли ці дві сили стикаються, розробники ядра можуть мати тенденцію прямо перевертати думки дослідників, як це було у випадку з командою 4337. Однак таке перекидання може призвести до конфлікту, оскільки при зіткненні двох сил виникає нестабільність, про що свідчать драматичні події, що відбулися після затвердження EIP-3074.

Так само, зіткнувшись з опором, дослідники можуть відмовитися від співпраці з основними розробниками. На мій погляд, це також одна з причин створення процесу RIP і чому нативний AA (7560) зараз просувається в першу чергу як RIP, а не EIP.

Хоча експерименти з оновленнями протоколу на L2, які є суперечливими для L1, мають свої переваги, ми не можемо розглядати RIP як заміну участі в процесі управління EIP. Дослідники повинні продовжувати співпрацювати з основними розробниками до тих пір, поки цінності обох сторін повністю не збігатимуться з дорожньою картою.

Висновок

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

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

Нарешті, ми представляємо модель VVRC, описуючи модель управління Ethereum: Цінності (Спільнота) ⇒ Бачення (Віталік) ⇒ Дорожня карта (Дослідники) ⇒ Клієнт (Основні розробники). Потім ми пропонуємо різні методи «налагодження» «помилок» цієї моделі.

Управління Ethereum – це «машина для створення машин», і щоб Ethereum працював правильно, ми повинні керувати ним належним чином.

Застереження:

1. Ця стаття передрукована з [极客 Web3]. Переслайте оригінальну назву «Роздуми про управління Ethereum після саги 3074». Усі авторські права належать оригінальному автору [Дерек Чіанг, генеральний директор ZeroDev]. Якщо є заперечення проти цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно впораються з цим.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є жодною інвестиційною порадою.
3. Переклад статті на інші мови здійснює команда Gate Learn. Якщо не зазначено, копіювання, розповсюдження або плагіат перекладених статей заборонено.