Оригінальний автор: Дерек Чанг, генеральний директор компанії ZeroDev
Faust, веб3 для гіків
Короткий огляд: це нещодавно опублікована думка голови ZeroDev Дерека Чанга про пропозицію V про EIP-7702 для балансування протирічь між ERC-4337 та EIP-3074. Через особистий досвід засновника проекту в екосистемі AA, стаття об’єктивно вказує на поточну модель управління Ethereum та її проблеми, чітко вказуючи:
Одним з конфліктів у галузі управління Ethereum є розбіжність думок між дослідниками, які визначають шлях розвитку, та командами розробників клієнтів, таких як Geth, а Віталік, виступаючи у ролі, схожій на CTO, став остаточним арбітром.
Derek після позитивної оцінки ролі Віталіка вказав, які покращення повинна зробити Ethereum у моделі управління, що має велике значення для спільноти Ethereum та Bitcoin.
Якщо ви раніше не знали про події, пов’язані з Ethereum AA (абстрагування рахунку), ось короткий огляд:
Кілька тижнів тому пропозиція EIP-3074 отримала схвалення від розробників ядра Ethereum і буде включена до наступної хардфорку “Pectra”. Ця пропозиція принесе два нових опкоди для EVM, що дозволить обліковим записам EOA Ethereum отримати практично нативний досвід відносно АА.
З того часу багато людей у спільноті ERC-4337, особливо ті, хто вніс пропозицію 4337, сильно проти EIP-3074, бо вони хвилюються, що ця пропозиція може створити багато проблем з безпекою і несумісна з маршрутною картою AA Ethereum. В попередній маршрутній карті Ethereum чітко зазначено, що ERC-4337 та подібні пропозиції, такі як 7560 (відомий як “nativeAA”), є центральними.
5 月初,Віталік запропонував EIP-7702 як альтернативу EIP-3074, досягнувши балансу між 4337 та 3074 - забезпечуючи користувачам EOA досвід AA, але в певній мірі сумісний з ERC-4337 та сумісний з “кінцевим варіантом AA” 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 спільнота активно взаємодіє з розробниками ядра Ethereum 4337. Якщо це передбачення справджується, наступні два результати:
Після розгляду 4337 відгуків спільноти, 3074 пропозиція була затверджена (і можливо буде змінена), за таких умов спільнота 4337 прийматиме 3074, і основна команда Ethereum не повинна відкликати 3074.
Або ж, 3074 ніколи не було затверджено, але 4337 спільнота та основна команда Ethereum запропонували спільний пропозицію, щоб всі були задоволені, так само, як 7702.
Кожен голос може бути почутим, і немає драматичних поворотів. Це могло б бути добре - от чому це не так?
Що пішло не так?
Підсумовуючи усю цю подію, обидві сторони взаємно звинувачують одна одну.
Етереум розробники ядра (а також автори EIP-3074) вважають це помилкою “4337 прихильників”, оскільки вони не брали активної участі у процесі обговорення всіма розробниками ядра (ACD), в якому EIP проходить тривалу розгляд, перш ніж буде прийнятий і впроваджений командами розробників клієнтів Етереуму, таких як Geth.
Деякі вважають, що підтримувачі “01928374656574839201” мали б взяти участь в обговоренні пропозиції 3074, висловити свою думку, а не критикувати пізніше, коли пропозиція вже отримала затвердження. В кінцевому підсумку, весь процес ACD прозорий, засідання відкриті для всіх, і, як Тім Бейко, після кожного засідання ACD активно публікує підсумкові твіти. Отже, якщо підтримувачі “01928374656574839201” настільки цікавляться цією темою, чому вони не беруть активну участь у відповідних засіданнях?
Лише в перекладі з’явився Ethereum, але в оригіналі такого слова не було.
Багато людей вказують на те, що весь процес конференції ACD є дуже непрозорим для тих, хто серйозно займається у спільноті Ethereum, але не може вчасно відслідковувати оновлення ACD. Деякі вважають, що ACD повинен активно звертатися до зацікавлених сторін (тут мається на увазі спільнота 4337) для збору відгуків.
Однак я вважаю, що обидва боки не поставили точки над “i”. За цим ховається ще глибша проблема, і якщо ми не вирішимо цю проблему або хоча б визнаємо її, ми будемо продовжувати потрапляти в ситуації з управлінням, а потім обидва боки будуть взаємно звинувачувати один одного, але це не матиме сенсу.
Основна причина аварій: карта шляху
Навпаки загальному уявленню, коренем управління інцидентами є те, що ACD не єдине джерело права на управління оновленням протоколу Ethereum, воно замінене іншим джерелом права на управління. Проблема полягає в тому, що, хоча вплив іншого джерела управління на основні проблеми Ethereum (такі як AA та масштабованість) є більшим, ніж у ACD, його рідко визнають.
У цій статті я називаю цю силу “планом шляху”.
Як я покажу нижче, весь випадок збою управління “3074-4337-7702” є прикладом того, як сила існуючої дорожньої карти Ethereum переважає силу ACD. Якщо ми говоримо про управління, коли ми помічаємо, що невидима сила переважає видиму силу, ми повинні бути дуже обурені, оскільки невидиме часто важко пояснити і не привертає уваги багатьох, тому його потрібно розкрити.
Що таке дорожня карта?
Будь-хто в Ethereum спільноті непомічено не пропустить термін “Roadmap”, наприклад, в “Roadmap, зосереджена на агрегації”, “Roadmap ETH 2.0” або пов’язана з цим подією “Roadmap AA”.
Для пояснення моєї точки зору, давайте уявимо сценарій на зустрічі ACD, де основні розробники обговорюють, як розширити масштаб Ethereum:
Один з ключових розробників Боб: Я підтримую EIP-1234, цей пропозиція вказує, що ми повинні прискорити швидкість блоку на 10 разів, збільшити розмір блоку в 10 разів та знизити вартість на 100 разів.
Інші ключові розробники: … Ви зійшли з розуму?
让我们想一想。为什么Ethereum核心团队会拒绝 Bob 说的东西?他只是提出了一种看起来非常合理的扩容方式,Solana 和 Aptos、Sui 等许多公链都这么做了,并取得了很高的 TPS。
Причина полягає в тому, що уявний EIP-1234 порушує шлях розширення Ethereum, який базується на “rollup-центризм”, який вказує, що для децентралізації важливо, щоб звичайні користувачі могли ефективно запускати вузли за низькими витратами, тому уявний EIP-1234 не може бути прийнятий, оскільки це значно збільшить витрати на запуск вузлів Ethereum.
Я хочу проілюструвати це на прикладі, що розробники-ключові учасники процесу управління ACD та прийняття рішень щодо оновлення протоколу, керуються вищою силою, яку я називаю «дорожньою картою». Наразі існують такі дорожні карти навколо Ethereum, як «дорожня карта масштабування», «дорожня карта AA», «дорожня карта MEV» та інші, які разом складають загальну дорожню карту Ethereum, і на їх основі розробники-ключові учасники повинні приймати рішення.
Коли точки зору та дорожні карти основних розробників не узгоджуються
Оскільки дорожня карта не є офіційною частиною процесу управління Ethereum, немає гарантії, що основна команда буде дотримуватися дорожньої карти. Крім того, не існує офіційної процедури “затвердження” дорожньої карти, тому не всі дорожні карти мають однаковий “ортодоксальний” статус. Дослідники за дорожньою картою Ethereum повинні докладати зусиль для просування своєї дорожньої карти серед основних розробників та спільноти, щоб отримати “ортодоксальний” статус та отримати підтримку від основної команди розробників Ethereum.
Щодо AA та абстрагування рахунку, сам Віталік неодноразово підтримував шлях AA з центром у 4337, але загалом головними пропагандистами шляху AA з центром у 4337 на форумах та на конференції ACD були команди, особливо Йоав та Дрор.
Однак, незважаючи на ці зусилля, деякі основні розробники Ethereum все ще рішуче проти маршрутної карти AA, зосередженої на 4337. Вони вважають, що 7560 (природжена версія 4337, яку має впровадити майбутній клієнт Ethereum) є занадто складною і не єдиним життєздатним варіантом “AA Endgame”. Нарешті, ACD вирішила затвердити пропозицію 3074, незважаючи на протистояння команди 4337, оскільки останні вважають, що 3074 призведе до розриву всієї екосистеми AA.
3074 після отримання схвалення викликав сильну реакцію у всьому співтоваристві 4337, що змусило розробників ядра Ethereum повернутися до обговорення 3074. Обговорення в результаті упало в тупик, автори 4337 та 3074 не змогли переконати один одного, але на останній хвилині Віталік запропонував EIP-7702 як альтернативний варіант для 3074. Ця пропозиція чітко сумісна з “AA термінальним” підходом, що базується на 4337, що дозволяє уникнути конфлікту та забезпечити відповідність остаточного результату та дорожньої карти AA.
Роль Віталіка: фактично CTO Ethereum
Незважаючи на те, що Віталік вважає себе дослідником, згадана вище історія чітко показує, що у Віталіка є влада в управлінні, яка відрізняється від інших дослідників. Отже, виникає питання: яку роль відіграє Віталік у управлінні Ethereum?
Особисто я вважаю, що розглядати Віталіка як технічного директора дуже великої компанії може бути вкрай доцільним (до речі, для відповідності реальному становищу, припустимо, що у “компанії” Ethereum немає генерального директора).
Якщо ви коли-небудь працювали в технологічній компанії з більш ніж 50 співробітників, ви зрозумієте, що CTO не може брати участь у кожному технічному рішенні. Після досягнення певного розміру компанії, процеси прийняття рішень щодо технічних рішень незаперечно розпадаються - зазвичай у кожній області продукту / бізнесу компанії є власна команда, яка може вільно вирішувати деталі рішення.
Крім того, CTO не обов’язково є провідним експертом у всіх (або будь-яких) питаннях. У компанії можуть бути інженери, які краще розбираються в певних галузях, ніж CTO, тому в обговоренні технічних деталей зазвичай кінцеве рішення приймають різні інженери.
Однак, CTO визначив технічну візію компанії. Виконання візії залишається на розсуд розробників.
Хоча це не є ідеальним аналогом, я вважаю, що це розумно узагальнює роль Віталіка в екосистемі Ethereum. Віталік не бере участь у кожному технічному рішенні - він просто не може. Він не є експертом у кожній галузі. Але його вплив на розробку всіх ключових рішень щодо Ethereum (масштабування, AA, POS…) є приголомшливим, і це стосується не лише його технічної експертизи, але й того, що він є остаточним суддею “чи відповідає ця стратегія візії Ethereum (його візії)”.
Кожен успішний продукт починається з бажання
Якщо я вважаю, що Віталік є CTO Ethereum, це ще не викликає достатньо суперечок, то найбільш суперечливою частиною є: ми повинні обійняти Віталіка в якості CTO.
Як засновник стартапу, я вважаю, що за кожним успішним продуктом depend впевнене довгострокове бачення - так, Ethereum також є “продуктом”, оскільки він може вирішувати реальні проблеми реальних користувачів. І це послідовне бачення має бути розроблене малою кількістю людей, таких як засновники стартапів, і, як правило, зазвичай лише одним засновником.
Прекрасність Ethereum полягає в тому, що, незважаючи на його складність та велику кількість компонентів, всі вони ідеально поєднуються в функціонуючий децентралізований комп’ютер, що щодня розраховує мільярди доларів вартості транзакцій.
Ми досягли сьогоднішнього дня не через проектні розробки якоїсь комісії, а завдяки візіонерському керівництву Віталіка. Саме завдяки його візії ми маємо такий послідовний та красивий Ethereum сьогодні. Ethereum - це ідея, запропонована Віталіком у 2015 році, і вона залишається незмінною до цього часу.
Конечно, це в жодному разі не означає принижування внеску інших дослідників та інженерів, вони зробили більшість внеску в досягнення сьогоднішнього Ethereum. Однак це не суперечить, оскільки Ethereum - це реалізація візії Віталіка, значно більша, ніж будь-яка інша візія.
说实话,你能对此抱怨吗?当你被以太坊生态系统的开放性、З спротивом до цензури和创新速度所吸引时,你是否抱怨过它始于 Vitalik 的愿景?也许你没有抱怨,因为你没有这样想过——但现在你有了,但你真的介意这个问题吗?
Децентралізація як вирішити?
Але ви скажете, що ж таке децентралізація? Якщо одна людина має таку переважну владу над Ethereum, як ми можемо сказати, що він є децентралізованим?
Щоб відповісти на це питання, нам потрібно звернутися до класичної статті про значення децентралізації, автором якої є Віталік. Ключові висновки статті полягають в тому, що децентралізація має три типи:
Архітектура Децентралізація: Скільки вузлів можуть вийти з ладу перед тим, як система припинить роботу?
Логічна децентралізація: чи здатні підсистеми системи розвиватися незалежно одна від одної, забезпечуючи нормальне функціонування системи в цілому, чи вони повинні тісно координуватися?
Політична децентралізація: нарешті, скільки людей або організацій контролюють цю систему?
За цими визначеннями, Ethereum очевидно має децентралізовану архітектуру, і можна сказати, що він також логічно децентралізований, оскільки його компоненти мають слабку зв’язаність (наприклад, рівень згоди та рівень виконання).
Щодо політичної децентралізації, хорошою новиною є те, що жодна особа або організація не може закрити Ethereum, навіть Віталік. Однак деякі люди можуть вважати, що ступінь політичної децентралізації Ethereum не така висока, як здається, оскільки Віталік відіграв важливу роль у визначенні візії та дорожньої карти Ethereum.
Однак, я вважаю, що якщо ми хочемо, щоб Ethereum продовжував інновації, нам потрібно прийняти Віталіка в якості фактичного CTO, навіть якщо це означає пожертвувати деяку політичну децентралізованість.
Якщо Ethereum дійсно стане таким же “застоєм” як Bitcoin, майже нещасною блокчейном, то, можливо, Віталік просто вийде у відставку. Але перед тим, як ми дійдемо до цього кроку, надзвичайно важливо мати авторитет, яким поважають всі сторони, цей авторитет є достойним довіри, може приймати рішення з технічних питань не лише на основі того, чи є технічне рішення переважним, а й на основі того, чи відповідають ці рішення візії Ethereum.
Якщо б не було таких осіб, як Віталік, то існувало б лише два можливих результати, історія навколо 3074 живо демонструє ці два можливих результати:
Процес управління Ethereum може потрапити в безкінечний тупик, обидві протилежності сторони не хочуть уступати, і ніхто не може зробити прогрес, як це виявилося в 3074 дискусії до втручання Віталіка.
Або Ethereum може стати непослідовною «Франкенштейном» (прим. перекл.: монстр, зображений у науково-фантастичному романі «Франкенштейн», створений вченим з частин тіл померлих людей). Згадані вище 3074 та 4337 можуть бути взаємно непоодинокі, що в кінцевому підсумку змусить екосистему AA розділитися на два несумісних паралельних простори.
Якщо Віталік визначив візію Ethereum, дослідники визначили шлях карту, а розробники ядра втілили шлях карту, то яку роль відіграє спільнота? Вона точно не просто бездіяльна.
Щасливо, спільнота фактично відіграє найважливішу роль. Причина полягає в тому, що перед баченням варто мати цінності. Ми об’єдналися в спільноту, тому що об’єднані деякими цінностями, і візія Віталіка в кінцевому рахунку повинна бути згідна з цими цінностями, інакше вона втратить підтримку спільноти.
Етереум спільнота вважає, що мати децентралізований комп’ютер, до якого всі можуть отримати доступ, який не підлягає цензурі, та є довіреною та нейтральною, корисно для світу. Ми підтримуємо та підтверджуємо ці цінності кожен день через нашу роботу на Етереумі, та надаємо легітимність візії, дорожньої карти та коду, розробленого Віталіком, дослідниками та основними розробниками.
Модель управління VVRC для Ethereum
Отже, ось повний модель мислення з управління Ethereum, цінності⇒візія⇒дорожня карта⇒клієнт, скорочено VVRC:
V==价值观==社区;
V==візія==Віталік;
R==路线图==研究人员; => * R==Roadmap==researchers;
C==клієнтська==розробник ядра;
Вони разом грали наступні ролі:
Спільнота збирається навколо певних цінностей.
Віталік висловив бачення, яке відповідає цим цінностям.
Дослідники розробляють дорожню карту відповідно до візії.
Основні розробники реалізують клієнт відповідно до дорожньої карти.
Звісно, реальність набагато складніша, ніж будь-яка проста модель може зафіксувати. Фактично, розробники ядра Ethereum - єдині, хто може справжньо “голосувати” за будь-який пропозицію шляхом змін в клієнтському коді. Віталік та інші дослідники виступають лише у консультативній ролі, іноді їхню думку не приймають розробники ядра, і це саме те, чому EIP-3074 отримав затвердження.
话虽如此,我认为 VVRC 模型合理地捕捉了以太坊的治理模式在通常情况下的运转方式,而我们需要「调试」该过程,使其不会再出现 EIP-3074 那样的事故。 => Незважаючи на це, я вважаю, що модель VVRC раціонально ухоплює спосіб функціонування управління Ethereum в звичайних умовах, і нам потрібно “налагодити” цей процес, щоб у майбутньому уникнути подібних аварій, як EIP-3074.
Як покращити модель управління Ethereum
Тепер ми вже маємо психологічну модель того, як працює управління Ethereum, тут є кілька ідей щодо вдосконалення процесу управління.
Необхідно підвищити видимість обговорення прогресу EIP, який перебуває на розгляді. Уся спільнота не повинна бути “здивованою” прийняттям EIP, такі непередбачувані способи затвердження пропозицій, як 3074, більше не повинні траплятися.
Наразі статус EIP на веб-сайті EIP не відображає його стану в процесі ACD. Тому він все ще показує, що 3074 знаходиться в стані “на розгляді”, навіть після того, як основні розробники проголосували за його затвердження, і навіть немає жодних підказок, що він взагалі був розглянутий для затвердження з самого початку.
理想情况下,коли EIP майже буде прийнято, Фонд Ефіріуму повинен зробити велике заявлення в соціальних мережах, щоб чітко оголосити цей результат для підвищення усвідомленості у спільноті.
Іноді розробники ядра можуть недооцінити вплив певного EIP на проекти та користувачів у нижній частині, спільноти 3074 та 4337 свідчать про це. З огляду на обмежений час засідання ACD та необхідність координації через часові пояси, на засіданнях зазвичай можуть виступати лише “зацікавлені сторони”.
Хоча це й так, іноді надання спільноті можливості висловитися і висловлення коментарів щодо впливу певних пропозицій EIP на підприємство після їх затвердження має певний сенс.
Якщо дослідники відчувають, що їхні погляди не приймаються розробниками ядра, як у випадку 4337, вони можуть залучити членів спільноти, щоб посилити свої аргументи.
Дуже важливо, щоб основні розробники та дослідники взаємно визнавали, що незважаючи на різний досвід, вони є частиною влади управління Ethereum. Основні розробники мають єдине право змінювати та оновлювати клієнт Ethereum через зміни в самому протоколі, що надає їм “голос” у процесі. Дослідники зазвичай мають більше публічної підтримки для змін та пояснень у маршрутній карті, завдяки активному обговоренню та написанню своїх ідей.
Коли зіткнуться ці дві сили, розробники ядра можуть схилятися до прямого скасування дослідників, наприклад, розробники ядра скасували заперечення команди 4337. Однак таке скасування може спричинити конфлікт, оскільки конфлікт між цими двома силами може стати нестабільним, і драматичні події, які відбулися після схвалення 3074, свідчать про це.
Так само, коли зіштовхуються зі спротивом, дослідники можуть схильні відмовлятися від співпраці з основними розробниками, на мою думку, це одна з причин створення процесу RIP, а також причина, чому природний AA( 7560) зараз в основному просувається як RIP, а не EIP.
Хоча випробування спірних оновлень протоколу на рівні L2 справді має свої переваги для L1, ми не можемо розглядати RIP як альтернативу участі в процесі управління EIP. Дослідники повинні продовжувати співпрацювати з основними розробниками до тих пір, поки цінності обох сторін повністю не відповідатимуть дорожньому картографу.
Висновок
3074/7702 подія показала справжній спосіб функціонування управління Ethereum - крім явної влади управління процесом EIP/ACD, яку здійснюють основні розробники, існує також прихована влада управління маршрутом, яку здійснюють дослідники. Коли ці владні повноваження виходять з-під контролю, ми бачимо тупік і підступи, і, можливо, потрібна буде інша сила - Віталік - щоб якось змінити цей баланс.
Потім ми стверджуємо, що Віталік представляє унікальну силу, а саме “візію” Ethereum, яка є основою для будь-якої офіційної дорожньої карти. Ми порівнюємо Віталіка з CTO великої компанії, визнаємо, що його роль як псевдо-CTO є необхідною для збереження інноваційного темпу Ethereum, це може запобігти деградації Ethereum до “Франкенштейн” стилю ляпсусів.
Наприкінці ми висунули модель VVRC, що описує управління Ethereum: цінності (спільнота)⇒візія (Віталік)⇒дорожня карта (дослідники)⇒клієнт (основні розробники). Потім ми висунули різні способи виправлення “помилок” цієї моделі.
Ефірійне управління - це “створення машини для створення машин” - щоб ефірій працював належним чином, нам потрібно розумно управляти. Тому приклад випадку управління 3074 є цінним, і я сподіваюся, що спільнота Ethereum зможе взяти з нього корисні уроки для поліпшення майбутніх процесів управління Ethereum.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Про вплив Віталіка та різноманітних дорожніх карт на процес управління Ethereum
Оригінальний автор: Дерек Чанг, генеральний директор компанії ZeroDev
Faust, веб3 для гіків
Короткий огляд: це нещодавно опублікована думка голови ZeroDev Дерека Чанга про пропозицію V про EIP-7702 для балансування протирічь між ERC-4337 та EIP-3074. Через особистий досвід засновника проекту в екосистемі AA, стаття об’єктивно вказує на поточну модель управління Ethereum та її проблеми, чітко вказуючи:
Одним з конфліктів у галузі управління Ethereum є розбіжність думок між дослідниками, які визначають шлях розвитку, та командами розробників клієнтів, таких як Geth, а Віталік, виступаючи у ролі, схожій на CTO, став остаточним арбітром.
Derek після позитивної оцінки ролі Віталіка вказав, які покращення повинна зробити Ethereum у моделі управління, що має велике значення для спільноти Ethereum та Bitcoin.
Якщо ви раніше не знали про події, пов’язані з Ethereum AA (абстрагування рахунку), ось короткий огляд:
Кілька тижнів тому пропозиція EIP-3074 отримала схвалення від розробників ядра Ethereum і буде включена до наступної хардфорку “Pectra”. Ця пропозиція принесе два нових опкоди для EVM, що дозволить обліковим записам EOA Ethereum отримати практично нативний досвід відносно АА.
З того часу багато людей у спільноті ERC-4337, особливо ті, хто вніс пропозицію 4337, сильно проти EIP-3074, бо вони хвилюються, що ця пропозиція може створити багато проблем з безпекою і несумісна з маршрутною картою AA Ethereum. В попередній маршрутній карті Ethereum чітко зазначено, що ERC-4337 та подібні пропозиції, такі як 7560 (відомий як “nativeAA”), є центральними.
5 月初,Віталік запропонував EIP-7702 як альтернативу EIP-3074, досягнувши балансу між 4337 та 3074 - забезпечуючи користувачам EOA досвід AA, але в певній мірі сумісний з ERC-4337 та сумісний з “кінцевим варіантом AA” 7560.
Зараз розробники ядра Ethereum розглядають питання EIP-7702, і попередні обговорення та настрої у спільноті показують, що EIP-7702 дуже ймовірно замінить згаданий вище EIP-3074.
За що стосується мене особисто, я дуже задоволений цим результатом: користувачі EOA незабаром зможуть насолодитися різноманітними продуктами в екосистемі ERC-4337 та отримати більшість переваг AA. Але я не можу не помітити, що ми можемо досягти цієї мети кращим способом, і це було зауважено багатьма протягом останніх кількох тижнів. Я вважаю, що якщо ми матимемо кращий процес управління, то зможемо зекономити багато зусиль і швидше досягнемо очікуваних результатів.
У цій статті я хочу:
Підсумок та роздуми щодо події EIP-3074
前文提到的故事讓很多人不高興,原因如下:
EIP-3074 затверджувалося кілька років. Після остаточного затвердження 3074 розробники Ethereum стали зіткнення з сильним опором від спільноти 4337.
З іншого боку, автори ERC-4337 висловлювали своє занепокоєння з приводу EIP-3074 Ethereum основній команді найдовше, але безрезультатно. Тепер Ethereum планує скасувати затвердження 3074 і замінити його іншим EIP (7702).
В цьому процесі насправді немає нічого поганого:
Проте, справа могла бу розв’язатися набагато гладше. Уявімо, що якщо все пішло б так:
В обговоренні 3074 спільнота активно взаємодіє з розробниками ядра Ethereum 4337. Якщо це передбачення справджується, наступні два результати:
Кожен голос може бути почутим, і немає драматичних поворотів. Це могло б бути добре - от чому це не так?
Що пішло не так?
Підсумовуючи усю цю подію, обидві сторони взаємно звинувачують одна одну.
Етереум розробники ядра (а також автори EIP-3074) вважають це помилкою “4337 прихильників”, оскільки вони не брали активної участі у процесі обговорення всіма розробниками ядра (ACD), в якому EIP проходить тривалу розгляд, перш ніж буде прийнятий і впроваджений командами розробників клієнтів Етереуму, таких як Geth.
Деякі вважають, що підтримувачі “01928374656574839201” мали б взяти участь в обговоренні пропозиції 3074, висловити свою думку, а не критикувати пізніше, коли пропозиція вже отримала затвердження. В кінцевому підсумку, весь процес ACD прозорий, засідання відкриті для всіх, і, як Тім Бейко, після кожного засідання ACD активно публікує підсумкові твіти. Отже, якщо підтримувачі “01928374656574839201” настільки цікавляться цією темою, чому вони не беруть активну участь у відповідних засіданнях?
Лише в перекладі з’явився Ethereum, але в оригіналі такого слова не було.
Багато людей вказують на те, що весь процес конференції ACD є дуже непрозорим для тих, хто серйозно займається у спільноті Ethereum, але не може вчасно відслідковувати оновлення ACD. Деякі вважають, що ACD повинен активно звертатися до зацікавлених сторін (тут мається на увазі спільнота 4337) для збору відгуків.
Однак я вважаю, що обидва боки не поставили точки над “i”. За цим ховається ще глибша проблема, і якщо ми не вирішимо цю проблему або хоча б визнаємо її, ми будемо продовжувати потрапляти в ситуації з управлінням, а потім обидва боки будуть взаємно звинувачувати один одного, але це не матиме сенсу.
Основна причина аварій: карта шляху
Навпаки загальному уявленню, коренем управління інцидентами є те, що ACD не єдине джерело права на управління оновленням протоколу Ethereum, воно замінене іншим джерелом права на управління. Проблема полягає в тому, що, хоча вплив іншого джерела управління на основні проблеми Ethereum (такі як AA та масштабованість) є більшим, ніж у ACD, його рідко визнають.
У цій статті я називаю цю силу “планом шляху”.
Як я покажу нижче, весь випадок збою управління “3074-4337-7702” є прикладом того, як сила існуючої дорожньої карти Ethereum переважає силу ACD. Якщо ми говоримо про управління, коли ми помічаємо, що невидима сила переважає видиму силу, ми повинні бути дуже обурені, оскільки невидиме часто важко пояснити і не привертає уваги багатьох, тому його потрібно розкрити.
Що таке дорожня карта?
Будь-хто в Ethereum спільноті непомічено не пропустить термін “Roadmap”, наприклад, в “Roadmap, зосереджена на агрегації”, “Roadmap ETH 2.0” або пов’язана з цим подією “Roadmap AA”.
Для пояснення моєї точки зору, давайте уявимо сценарій на зустрічі ACD, де основні розробники обговорюють, як розширити масштаб Ethereum:
让我们想一想。为什么Ethereum核心团队会拒绝 Bob 说的东西?他只是提出了一种看起来非常合理的扩容方式,Solana 和 Aptos、Sui 等许多公链都这么做了,并取得了很高的 TPS。
Причина полягає в тому, що уявний EIP-1234 порушує шлях розширення Ethereum, який базується на “rollup-центризм”, який вказує, що для децентралізації важливо, щоб звичайні користувачі могли ефективно запускати вузли за низькими витратами, тому уявний EIP-1234 не може бути прийнятий, оскільки це значно збільшить витрати на запуск вузлів Ethereum.
Я хочу проілюструвати це на прикладі, що розробники-ключові учасники процесу управління ACD та прийняття рішень щодо оновлення протоколу, керуються вищою силою, яку я називаю «дорожньою картою». Наразі існують такі дорожні карти навколо Ethereum, як «дорожня карта масштабування», «дорожня карта AA», «дорожня карта MEV» та інші, які разом складають загальну дорожню карту Ethereum, і на їх основі розробники-ключові учасники повинні приймати рішення.
Коли точки зору та дорожні карти основних розробників не узгоджуються
Оскільки дорожня карта не є офіційною частиною процесу управління Ethereum, немає гарантії, що основна команда буде дотримуватися дорожньої карти. Крім того, не існує офіційної процедури “затвердження” дорожньої карти, тому не всі дорожні карти мають однаковий “ортодоксальний” статус. Дослідники за дорожньою картою Ethereum повинні докладати зусиль для просування своєї дорожньої карти серед основних розробників та спільноти, щоб отримати “ортодоксальний” статус та отримати підтримку від основної команди розробників Ethereum.
Щодо AA та абстрагування рахунку, сам Віталік неодноразово підтримував шлях AA з центром у 4337, але загалом головними пропагандистами шляху AA з центром у 4337 на форумах та на конференції ACD були команди, особливо Йоав та Дрор.
Однак, незважаючи на ці зусилля, деякі основні розробники Ethereum все ще рішуче проти маршрутної карти AA, зосередженої на 4337. Вони вважають, що 7560 (природжена версія 4337, яку має впровадити майбутній клієнт Ethereum) є занадто складною і не єдиним життєздатним варіантом “AA Endgame”. Нарешті, ACD вирішила затвердити пропозицію 3074, незважаючи на протистояння команди 4337, оскільки останні вважають, що 3074 призведе до розриву всієї екосистеми AA.
3074 після отримання схвалення викликав сильну реакцію у всьому співтоваристві 4337, що змусило розробників ядра Ethereum повернутися до обговорення 3074. Обговорення в результаті упало в тупик, автори 4337 та 3074 не змогли переконати один одного, але на останній хвилині Віталік запропонував EIP-7702 як альтернативний варіант для 3074. Ця пропозиція чітко сумісна з “AA термінальним” підходом, що базується на 4337, що дозволяє уникнути конфлікту та забезпечити відповідність остаточного результату та дорожньої карти AA.
Роль Віталіка: фактично CTO Ethereum
Незважаючи на те, що Віталік вважає себе дослідником, згадана вище історія чітко показує, що у Віталіка є влада в управлінні, яка відрізняється від інших дослідників. Отже, виникає питання: яку роль відіграє Віталік у управлінні Ethereum?
Особисто я вважаю, що розглядати Віталіка як технічного директора дуже великої компанії може бути вкрай доцільним (до речі, для відповідності реальному становищу, припустимо, що у “компанії” Ethereum немає генерального директора).
Якщо ви коли-небудь працювали в технологічній компанії з більш ніж 50 співробітників, ви зрозумієте, що CTO не може брати участь у кожному технічному рішенні. Після досягнення певного розміру компанії, процеси прийняття рішень щодо технічних рішень незаперечно розпадаються - зазвичай у кожній області продукту / бізнесу компанії є власна команда, яка може вільно вирішувати деталі рішення.
Крім того, CTO не обов’язково є провідним експертом у всіх (або будь-яких) питаннях. У компанії можуть бути інженери, які краще розбираються в певних галузях, ніж CTO, тому в обговоренні технічних деталей зазвичай кінцеве рішення приймають різні інженери.
Однак, CTO визначив технічну візію компанії. Виконання візії залишається на розсуд розробників.
Хоча це не є ідеальним аналогом, я вважаю, що це розумно узагальнює роль Віталіка в екосистемі Ethereum. Віталік не бере участь у кожному технічному рішенні - він просто не може. Він не є експертом у кожній галузі. Але його вплив на розробку всіх ключових рішень щодо Ethereum (масштабування, AA, POS…) є приголомшливим, і це стосується не лише його технічної експертизи, але й того, що він є остаточним суддею “чи відповідає ця стратегія візії Ethereum (його візії)”.
Кожен успішний продукт починається з бажання
Якщо я вважаю, що Віталік є CTO Ethereum, це ще не викликає достатньо суперечок, то найбільш суперечливою частиною є: ми повинні обійняти Віталіка в якості CTO.
Як засновник стартапу, я вважаю, що за кожним успішним продуктом depend впевнене довгострокове бачення - так, Ethereum також є “продуктом”, оскільки він може вирішувати реальні проблеми реальних користувачів. І це послідовне бачення має бути розроблене малою кількістю людей, таких як засновники стартапів, і, як правило, зазвичай лише одним засновником.
Прекрасність Ethereum полягає в тому, що, незважаючи на його складність та велику кількість компонентів, всі вони ідеально поєднуються в функціонуючий децентралізований комп’ютер, що щодня розраховує мільярди доларів вартості транзакцій.
Ми досягли сьогоднішнього дня не через проектні розробки якоїсь комісії, а завдяки візіонерському керівництву Віталіка. Саме завдяки його візії ми маємо такий послідовний та красивий Ethereum сьогодні. Ethereum - це ідея, запропонована Віталіком у 2015 році, і вона залишається незмінною до цього часу.
Конечно, це в жодному разі не означає принижування внеску інших дослідників та інженерів, вони зробили більшість внеску в досягнення сьогоднішнього Ethereum. Однак це не суперечить, оскільки Ethereum - це реалізація візії Віталіка, значно більша, ніж будь-яка інша візія.
说实话,你能对此抱怨吗?当你被以太坊生态系统的开放性、З спротивом до цензури和创新速度所吸引时,你是否抱怨过它始于 Vitalik 的愿景?也许你没有抱怨,因为你没有这样想过——但现在你有了,但你真的介意这个问题吗?
Децентралізація як вирішити?
Але ви скажете, що ж таке децентралізація? Якщо одна людина має таку переважну владу над Ethereum, як ми можемо сказати, що він є децентралізованим?
Щоб відповісти на це питання, нам потрібно звернутися до класичної статті про значення децентралізації, автором якої є Віталік. Ключові висновки статті полягають в тому, що децентралізація має три типи:
За цими визначеннями, Ethereum очевидно має децентралізовану архітектуру, і можна сказати, що він також логічно децентралізований, оскільки його компоненти мають слабку зв’язаність (наприклад, рівень згоди та рівень виконання).
Щодо політичної децентралізації, хорошою новиною є те, що жодна особа або організація не може закрити Ethereum, навіть Віталік. Однак деякі люди можуть вважати, що ступінь політичної децентралізації Ethereum не така висока, як здається, оскільки Віталік відіграв важливу роль у визначенні візії та дорожньої карти Ethereum.
Однак, я вважаю, що якщо ми хочемо, щоб Ethereum продовжував інновації, нам потрібно прийняти Віталіка в якості фактичного CTO, навіть якщо це означає пожертвувати деяку політичну децентралізованість.
Якщо Ethereum дійсно стане таким же “застоєм” як Bitcoin, майже нещасною блокчейном, то, можливо, Віталік просто вийде у відставку. Але перед тим, як ми дійдемо до цього кроку, надзвичайно важливо мати авторитет, яким поважають всі сторони, цей авторитет є достойним довіри, може приймати рішення з технічних питань не лише на основі того, чи є технічне рішення переважним, а й на основі того, чи відповідають ці рішення візії Ethereum.
Якщо б не було таких осіб, як Віталік, то існувало б лише два можливих результати, історія навколо 3074 живо демонструє ці два можливих результати:
Роль спільноти
经過了上述思考,我們快要勾勒出一個完整的以太坊治理思維模型了,但到目前為止,我們的討論中有一個明顯的遺漏——社區。
Якщо Віталік визначив візію Ethereum, дослідники визначили шлях карту, а розробники ядра втілили шлях карту, то яку роль відіграє спільнота? Вона точно не просто бездіяльна.
Щасливо, спільнота фактично відіграє найважливішу роль. Причина полягає в тому, що перед баченням варто мати цінності. Ми об’єдналися в спільноту, тому що об’єднані деякими цінностями, і візія Віталіка в кінцевому рахунку повинна бути згідна з цими цінностями, інакше вона втратить підтримку спільноти.
Етереум спільнота вважає, що мати децентралізований комп’ютер, до якого всі можуть отримати доступ, який не підлягає цензурі, та є довіреною та нейтральною, корисно для світу. Ми підтримуємо та підтверджуємо ці цінності кожен день через нашу роботу на Етереумі, та надаємо легітимність візії, дорожньої карти та коду, розробленого Віталіком, дослідниками та основними розробниками.
Модель управління VVRC для Ethereum
Отже, ось повний модель мислення з управління Ethereum, цінності⇒візія⇒дорожня карта⇒клієнт, скорочено VVRC:
Вони разом грали наступні ролі:
Звісно, реальність набагато складніша, ніж будь-яка проста модель може зафіксувати. Фактично, розробники ядра Ethereum - єдині, хто може справжньо “голосувати” за будь-який пропозицію шляхом змін в клієнтському коді. Віталік та інші дослідники виступають лише у консультативній ролі, іноді їхню думку не приймають розробники ядра, і це саме те, чому EIP-3074 отримав затвердження.
话虽如此,我认为 VVRC 模型合理地捕捉了以太坊的治理模式在通常情况下的运转方式,而我们需要「调试」该过程,使其不会再出现 EIP-3074 那样的事故。 => Незважаючи на це, я вважаю, що модель VVRC раціонально ухоплює спосіб функціонування управління Ethereum в звичайних умовах, і нам потрібно “налагодити” цей процес, щоб у майбутньому уникнути подібних аварій, як EIP-3074.
Як покращити модель управління Ethereum
Тепер ми вже маємо психологічну модель того, як працює управління Ethereum, тут є кілька ідей щодо вдосконалення процесу управління.
Наразі статус EIP на веб-сайті EIP не відображає його стану в процесі ACD. Тому він все ще показує, що 3074 знаходиться в стані “на розгляді”, навіть після того, як основні розробники проголосували за його затвердження, і навіть немає жодних підказок, що він взагалі був розглянутий для затвердження з самого початку.
理想情况下,коли EIP майже буде прийнято, Фонд Ефіріуму повинен зробити велике заявлення в соціальних мережах, щоб чітко оголосити цей результат для підвищення усвідомленості у спільноті.
Хоча це й так, іноді надання спільноті можливості висловитися і висловлення коментарів щодо впливу певних пропозицій 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: цінності (спільнота)⇒візія (Віталік)⇒дорожня карта (дослідники)⇒клієнт (основні розробники). Потім ми висунули різні способи виправлення “помилок” цієї моделі.
Ефірійне управління - це “створення машини для створення машин” - щоб ефірій працював належним чином, нам потрібно розумно управляти. Тому приклад випадку управління 3074 є цінним, і я сподіваюся, що спільнота Ethereum зможе взяти з нього корисні уроки для поліпшення майбутніх процесів управління Ethereum.
Посилання на оригінал