Пояснення управління базовим протоколом Етеріуму

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

Ця стенограма є доступною копією оригінальної стенограми відео (opens in a new tab), опублікованої EthBoulder. Її було злегка відредаговано для зручності читання.

Вступ (0:12)

Дякую всім шістьом моїм друзям, які прийшли. Гаразд. Сьогодні я розповім вам про управління базовим протоколом Етеріуму. Мене звати Ніксо. Я очолюю команду підтримки протоколу у Фундації Ethereum (EF). Серед усіх наших завдань одне з головних — зробити процес управління більш зрозумілим і простим для навігації для всіх інших учасників, оскільки Етеріум включає набагато більше людей, ніж просто його основні розробники (core developers).

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

Отже, що таке управління базовим протоколом? Я запускаю вузол. Це означає, що у мене є обладнання, комп'ютер вдома, на якому я запускаю програмне забезпечення Етеріуму. Коли я налаштовував це програмне забезпечення Етеріуму, мені довелося вибирати клієнти, які будуть його запускати. Етеріум є певною мірою унікальним, оскільки він має кілька клієнтів для забезпечення різноманітності клієнтів. Суть цього полягає в тому, що якщо один клієнт виходить з ладу, якщо в клієнті є помилка, вся мережа не падає. Існують інші блокчейни, які мають інші клієнти. Однак Етеріум — єдиний, який налаштований таким чином, що дійсно захищає нас від помилок. Наприклад, якщо ви подивитеся на Solana, у Solana є інший клієнт, здається, він називається GTO, але його рівень впровадження становить лише 20–21%. Тому, якщо клієнт більшості вийде з ладу, ланцюг зупиниться. І ми бачили, як інші мережі падали. Саме тому Етеріум є найбільш стійким і безпечним блокчейном.

Тож постає питання: як вносити зміни в Етеріум, коли доводиться координувати роботу з такою кількістю різних клієнтів? Спочатку ми розрізнимо хардфорк і софтфорк. Софтфорк не вимагає такої координації, як хардфорк. Етеріум переважно працює з хардфорками. Отже, хардфорк — це, по суті, коли всі клієнти створюють нову версію Етеріуму і вирішують у певний заздалегідь налаштований час запустити цю нову версію Етеріуму. Це все ще Етеріум, але він має нові функції. Він має інші функції. І всі оператори вузлів, такі як я, які запускають вузли вдома, або професійні оператори, повинні прийняти цю нову версію Етеріуму. Вони повинні оновити свій вузол або оновити свої вузли, щоб включити це нове програмне забезпечення.

Тож як вони вирішують, які функції увійдуть до цих хардфорків? Вони повинні узгодити пріоритети для розподілу свого часу та ресурсів, оскільки у них є обмежений час і ресурси для цього. Вони надають пріоритет таким речам, як недоліки безпеки або виправлення безпеки, таким речам, як користувацький досвід (UX) — якщо є інший блокчейн, який конкурує з нами, нам потрібно стати конкурентоспроможними порівняно з цими іншими блокчейнами. Тому одна з речей, на яку вони звертають увагу, полягає в тому, що будь-яка функція, яка впроваджується, повинна бути сумісною з потенційними майбутніми пунктами дорожньої карти.

Минулого року сталася дійсно суперечлива річ. Можливо, ви чули про це. Це називалося EOF. Це EVM Object Format (об'єктний формат EVM). Це був набір функцій, який планувалося включити в хардфорк Фусака — Пектра, Фусака, здається, в обидва — але його розділили. І одним із тригерів серед багатьох інших, через який його виключили з цього форку, було те, що Віталік опублікував допис про потенціал переходу Етеріуму на RISC-V. Багато людей, які читали це, подивилися на це і подумали: гаразд, якщо ми перейдемо на RISC-V, функції, які ми розглядаємо в EOF, будуть вбудованими в RISC-V. Тож навіщо нам додавати цю складність до протоколу? Навіщо нам витрачати всі ці ресурси розробників клієнтів на цю річ? Це не мало б сенсу, якби ми зрештою перейшли на RISC-V.

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

Хибні уявлення (5:23)

Це підводить нас до хибних уявлень, і ми розглянемо деякі з них. Перше: Віталік вирішує, що увійде до протоколу Етеріуму. Продовженням цього є те, що Фундація Ethereum контролює все. І третє: це все кулуарні домовленості — інсайдери, ветерани (OGs) приймають ці рішення.

Отже, перше: Віталік вирішує. Я просто вибрав підмножину застійних пропозицій щодо покращення Етеріуму (EIP), авторами яких є Віталік. Це означає, що Віталік сів, написав пропозицію і сказав: я хочу, щоб ці речі увійшли в Етеріум, і ніхто не погодився — ці речі просто лежать там. Він не зміг впровадити їх у протокол. Тож не все, що він пропонує, автоматично включається.

Продовженням цього є те, що Фундація Ethereum контролює все. Я збираюся навести конкретний приклад ситуації, яка, на мою думку, суперечить цьому. У 2024 році було багато розмов про ліміт газу. Причина цього полягає в тому, що у 2022 році під час Злиття ми підняли ліміт газу до 30 мільйонів. Це максимальний обсяг обчислень, дозволений у блоці. А потім ми ніби не чіпали його деякий час, тому що це не було вузьким місцем, через яке люди казали б: «Ось чому я не переходжу на Етеріум» або «Це обмежує мій поточний варіант використання Етеріуму».

А наприкінці 2023 — на початку 2024 року з'явився наратив про те, що наближається Solana. Вона збиралася обійти Етеріум. Тож люди думали про те, що може зробити Етеріум для прискорення. І однією з ідей було: давайте збільшимо цей показник газу. І на той час Фундація Ethereum та розробники клієнтів ніби казали: «У нас є інші речі, про які варто турбуватися. Але дякуємо». Проте ці двоє людей, Ерік Коннор (Eric Connor) та Маріано Конті (Mariano Conti), прийшли і сказали: «Ні, ми підвищуємо ліміт газу». Ліміт газу — це параметр, який контролюється валідаторами. Тож вони могли просто почати говорити з валідаторами, професійними операторами, і казати: «Гей, підніміть свій ліміт газу».

І в якийсь момент рівень підтримки став настільки високим, що Фундація Ethereum та клієнти сказали: «О, ми повинні звернути на це увагу. Ми повинні переконатися, що те, що вони роблять, є безпечним, і що значення, до якого вони зрештою це піднімуть, буде безпечним для мережі». Тож їм довелося перерозподілити свої ресурси. Незермайнд розробив цю систему тестування. Фундація Ethereum виконала багато роботи в Берліні. Усі розробники клієнтів проводили бенчмаркінг цього. І мені це подобається, тому що це змусило Фундацію Ethereum змінити свої пріоритети.

І мені подобається цей дурний твіт, скріншот якого я тут зробив, тому що це схоже на те, як якесь випадкове новинне видання називає Еріка Коннора та Маріано Конті основними розробниками (core devs). Вони не є основними розробниками. Ерік Коннор був стейкером і членом спільноти. Маріано Конті був колишнім розробником додатків MakerDAO. Але їх просто назвали основними розробниками, тому що розробка Етеріуму дійсно виходить за рамки того, як працює традиційне програмне забезпечення, і тому вони побачили, що змінюється основний параметр, і подумали: «О, це, мабуть, основні розробники». Це не так. Тож це просто приклад того, як члени спільноти приходять і кажуть, що ми хочемо бачити цю зміну, і втілюють її в життя.

Це все кулуарні домовленості, інсайдери, ветерани — я трохи краще розумію, чому це є хибним уявленням, тому що ви, по суті, приходите на ці дзвінки з управління, і на цих дзвінках присутня сотня людей. Здається, що всі вони дуже комфортно почуваються з тим, що відбувається. Ви розгублені. Ви не маєте уявлення, як приймаються ці рішення. Ви думаєте: «Чи вже моя черга говорити?» І здається, що люди слухають одних і тих самих 10 людей, щоб прийняти ці рішення.

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

Але правда полягає в тому, що розробка Етеріуму — це більша меритократія, ніж я коли-небудь бачив у більшості розробок програмного забезпечення. Усі ці люди на цьому скріншоті — це один із трьох випадкових дзвінків All Core Devs (ACD), які я вирішив заскріншотити — жоден із цих людей не був призначений бути тут. Усі вони — це просто люди, які прийшли. Це розробники, які провели багато часу з цим протоколом. Це ті, кого люди визнали талановитими розробниками в цьому просторі, які постійно приймають правильні рішення, і ніхто з них не призначений бути тут.

Тож я приєднався до Фундації Ethereum лише трохи більше року тому. Я зібрав цю статистику. Вона охоплює період лише до березня 2025 року. Тобто менше року. Середня кількість відвідувачів All Core Devs — це дзвінки з управління — становить 98. Тобто в середньому на цих дзвінках присутні 98 людей. Максимальна кількість відвідувачів на одному дзвінку з того часу становила 153. Здається, це був день, коли ми визначали дату запуску Пектра в Головній мережі. А загальна кількість унікальних відвідувачів становить 567 лише за останній рік. Мені дуже подобається цей показник, тому що він дійсно показує, що це не одні й ті самі 100 людей, які щоразу приходять на ці дзвінки. Ці розробники додатків, дослідники, хтось чує про якусь функцію, яка обговорюється, вони приходять, щоб висловити свою незгоду з нею або свою підтримку, а потім не приходять на інший дзвінок.

Як працює процес управління (11:52)

Тож це трохи сухий слайд, але я думаю, що важливо його розглянути — ось як наразі працює управління Етеріумом. Отже, коли обговорюється один із цих форків, перше, що відбувається, це те, що люди протягом цього виділеного часового вікна можуть подати свою головну пропозицію. Головна пропозиція — це основна функція, навколо якої ми хочемо згуртувати людей для цього форку. Це може бути член спільноти, дослідник, основний розробник — дійсно будь-хто, хто подає одну з цих головних пропозицій. Потім вікно закривається, і на дзвінках з управління ми ніби обговорюємо, яка з них має сенс. Люди наводять свої аргументи, люди сперечаються, і досягається консенсус щодо того, яку з них ми повинні вибрати для цього майбутнього форку.

Після цього вони вибирають другорядні функції. Тобто менші речі, які насправді не повинні бути цими основними функціями, що керують форком. І протягом усього цього часу у нас є девнети, специфічні для певних функцій. Девнет — це як тестова мережа — приватна тестова мережа для розробників, щоб протестувати ці функції та переконатися, що вони дійсно працюють в Етеріумі. А потім у якийсь момент відбувається заморожування функцій (feature freeze). Отже, ми обговорили основні функції, ми обговорили другорядні функції, ми запустили ці специфічні для функцій девнети, які зазвичай є головними темами форку. І це заморожування функцій із зірочкою, тому що на цьому етапі ми вирішили, що більше не будемо додавати жодних функцій до цього форку. Ми збираємося запустити всі функції разом, переконатися, що все добре, переконатися, що нічого не зламається. Але якщо щось починає сповільнювати процес, якщо форк затримується, якщо він занадто складний, речі все ще можуть бути виключені на цьому етапі.

Тож після кількох девнетів — їх може бути два, може бути 10 — усі клієнти в якийсь момент вирішують, що це стабільно. Ми довіряємо тому, що відбувається зараз. Ми в хорошому стані. Давайте почнемо думати про те, щоб випустити це в Головну мережу Етеріуму. Вони випускають релізи клієнтів, а потім настає 30-денний період, коли команда безпеки Фундації Ethereum оголошує програму винагород за знайдені помилки (bug bounty). Вони замовляють аудити безпеки. А потім наприкінці цього 30-денного періоду ми запускаємо форк у тестових мережах. Це тестові мережі, про які ви, можливо, чули — наприклад, Holesky. Саме тут розробники додатків можуть протестувати свої речі до того, як форк запрацює. І зазвичай це мінімум 14 днів для кожної, просто щоб переконатися, що все гаразд. Ми не очікуємо жодних великих проблем, тому що це вже пройшло через специфічні для функцій девнети та узагальнені девнети раніше, але історично це ламало деякі з цих тестових мереж. Тож це ніби останній шанс знайти та усунути всі ці помилки.

А потім, як тільки бездозвільна тестова мережа стає стабільною, вибирається дата запуску в Головній мережі. Після цього є 30-денний буфер. Цей 30-денний буфер існує, тому що рішення другого рівня (L2) та протоколи просили про це, щоб підготуватися до форку. Тож це мінімум 30 днів, а потім відбувається форк.

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

Протягом усього цього часу відбуваються деякі основні серії дзвінків. Усі ці публічні дзвінки транслюються наживо на YouTube. Основними з них є ACDE та ACDC. E означає рівень виконання (execution layer) — це такі речі, як транзакції, розгортання смарт-контрактів, управління мемпулом. ACDC — це рівень консенсусу (consensus layer) — тобто це речі валідаторів, такі як управління валідаторами, слешинг. І вони чергуються по четвергах. Тож кожного четверга відбувається ACD, і один із них — це ACDE, а наступний — ACDC, і так далі.

Дзвінки ACDE та ACDC зосереджені на форку, який ми зараз робимо, і форках, які ми плануємо на майбутнє. Дзвінки ACDT більше заглиблюються в деталі. Це клієнти, які говорять про помилки, які вони не можуть подолати, або деталі реалізації, які потрібно вирішити щодо форку, над яким вони зараз працюють. Тож зараз наступний форк, який відбудеться, — це Гламстердам. Тому на цих дзвінках ACDT домінують розмови про ePBS та списки доступу на рівні блоків, які є речами, що увійдуть до Гламстердаму. І це високотехнічні дзвінки.

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

Процес, що розвивається (15:29)

Тож одна річ, яку я хочу донести до всіх, полягає в тому, що цей процес зовсім не є статичним. Цей процес, який я вам щойно описав, діє менше року. Етеріум працює вже 10 років. Але він постійно змінюється, і причина, чому він постійно змінюється, полягає в тому, що ніхто не є головним. І цей процес ніби еволюціонує, щоб знайти найбільш ефективний спосіб роботи. І хоча я кажу «ефективний», репутація управління Етеріумом полягає в тому, що воно дійсно застійне, через нього важко щось просунути, воно заплутане — і це тому, що коли у вас від 100 до 500 людей приймають рішення, я чесно вражений, що це взагалі працює.

Тож Тім (Tim) зробив допис у квітні 2025 року під назвою «Реконфігурація All Core Devs», який зрештою став пропозицією щодо того, як усе працює зараз. І причина цього полягає в тому, що до цього у нас був ніби цілісний наратив про те, на чому ми повинні зосередитися в Етеріумі. Було Злиття, яке було величезним починанням. Всі були дуже схвильовані. Більшість людей були дуже схвильовані. Майнери — ні. А потім після Злиття у вас з'явилося зняття коштів. Тож ми не хотіли, щоб люди мали свій ETH заблокованим у контракті, і щоб цей FUD (страх, невпевненість і сумніви) виглядав так, ніби вони ніколи не зможуть вивести звідти ETH. Тому нам довелося випустити це якомога швидше. А потім був прото-данкшардинг, а потім з'явилася Пектра, і Пектра була ніби цією сумішшю різних непов'язаних EIP і насправді не мала цілісного наративу. І вона стала настільки великою, тому що люди просто впихали туди речі через відсутність згуртованості, що її довелося розділити на два різні форки, тому що команди тестувальників ніби казали: «Обсяг занадто великий. Ми не можемо все це протестувати».

І тому стимулом Тіма зробити це було: гаразд, нам потрібно придумати спосіб зберегти ці форки максимально сфокусованими та цілісними. І головна пропозиція (headliner) стала своєрідною відповіддю на це. Суть цього полягала в тому, щоб випускати оновлення таким чином, щоб пріоритетом було відчуття, що всі знають, про що цей форк, щоб їм не доводилося впихати 25 різних EIP.

Тож інший скріншот зверху — це Тім, який пропонує визначення для етапів включення цих EIP. І думка, яку я хочу донести за допомогою цього, полягає в тому, що іноді ви чуєте, як люди кажуть, що цей процес занадто бюрократичний. Але насправді відбувається те, що люди приходять у цей процес управління і запитують: «Як мені впровадити EIP?», а люди, які були там 10 років, відповідають: «Ти ніби просто робиш це». І люди такі: «Це жахливо». І тому те, що роблять ці речі, — вони описують, що відбувається, щоб полегшити стороннім особам участь у цьому процесі, тому що якщо ви просто приходите сюди і кажете: «У мене є один EIP, мене не хвилює управління Етеріумом, я просто хочу, щоб цей один EIP був прийнятий» — ви хочете рубрику, ви хочете контрольний список, ви хочете дуже чіткий покроковий план того, як впровадити цей EIP. Тож більшість із цих речей стосуються скоріше опису того, як працює процес, ніж створення бюрократичних правил, яких люди повинні дотримуватися, щоб ускладнити впровадження EIP.

Третя річ — це коміти з часом на Forkcast. Forkcast — це продукт моєї команди, створений Вольфрамом Марком (Wolfram Mark), хлопцем з моєї команди, який створив його в середині минулого року, коли була сформована моя команда в її поточній ітерації. І він став таким канонічним ресурсом, який люди використовують для взаємодії з форком, щоб побачити, що входить у форк і як це впливає на них. Усім цим речам менше двох років. Тож я просто хочу сказати, що цей процес дуже змінюється. Він зовсім не статичний. Це не якась заморожена бюрократія, куди важко потрапити.

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

Тож я хотів би швидко торкнутися найбільш схожих децентралізованих систем управління, які я бачу, на управління Етеріумом. І думка, яку я намагаюся тут донести, полягає в тому, що це життєздатно — хоча це дивно, що від 100 до 500 людей можуть приймати рішення, це життєздатно в реальному світі. Ми дійсно бачимо приклади того, як це працює.

IETF — це Інженерна рада Інтернету (Internet Engineering Task Force). Це керований волонтерами орган зі стандартизації, який створив TCP/IP, HTTP. Це організація, яка найбільше відповідає за те, що сьогодні ми маємо вільний інтернет. Ядро Linux — це основа операційної системи Linux. Тобто це програмне забезпечення з відкритим вихідним кодом, яке забезпечує роботу інтернет-серверів, телефонів Android, суперкомп'ютерів. Різниця там полягає в тому, що у них є своєрідна модель доброзичливого диктатора з Лінусом Торвальдсом (Linus Torvalds). Але навіть при цьому у них понад 17 000 контриб'юторів, що просто вражає.

Речі, на які це не схоже: інші блокчейни, які мають ончейн-голосування токенами. Етеріум спеціально уникає будь-якого механізму голосування, тому що, на мою думку, це призводить до можливостей для захоплення і ніби позбавляє стимулу робити речі меритократією, де люди просто довіряють тим, хто пише найкращий код. А ще є рішення другого рівня (L2). У них є мультипідписи (multi-sigs). У них є ради безпеки. Це більше схоже на призначені посади, які приймають ці рішення. І це має свої компроміси. Це більш централізовано. Хоча це рухається швидше.

Чому це хвилює розробників (22:38)

Тож чому розробників (builders) хвилює управління? Тому що розробники — це буквально ті, для кого створений Етеріум. Етеріум створений не для основних розробників (core devs). Він створений не для валідаторів. Іноді ці люди плутаються в цьому. Основні розробники Етеріуму та валідатори служать Етеріуму, який служить розробникам і користувачам.

І у кожного був такий момент зі штучним інтелектом (AI), коли ви занадто заглиблюєтеся в деталі, і він намагається виправити цю дрібницю, і йому не вдається віддалитися і подивитися на всю мету проєкту. І основні розробники можуть бути такими ж, коли вони намагаються вдосконалити процес основної розробки. І в цьому випадку дуже важливо, щоб розробники (builders) втручалися, тому що основна розробка настільки всепоглинаюча, що більшість часу вони не створюють нічого поверх Етеріуму. Вони дуже залучені в основну розробку. Це забирає весь їхній час. І тому розробники додатків дійсно повинні докласти зусиль, щоб прийти і сказати: «Гей, нам це потрібно. Це критично важливо для Етеріуму». Просто щоб переконатися, що перспектива існує, і що вони не просто заганяють себе в рамки роботи лише для основних розробників.

Як взяти участь (24:40)

Тож як вам взяти участь або впровадити свою функцію? Це ніби загальна порада, але я думаю, що вона найкраща. Голосно заявляйте про свої больові точки. Заходьте у Twitter, пишіть дописи в блогах, шукайте рішення для своїх больових точок. Розмірковуйте про речі, які могли б вам допомогти. Якщо ви знайдете інших людей, які мають такі ж больові точки, зазвичай ви можете знайти EIP, який існує для вирішення цієї больової точки, або попросити когось допомогти вам написати EIP, який це робить.

Одна річ, яка мені подобається в програмному забезпеченні з відкритим вихідним кодом, полягає в тому, що зазвичай добре капіталізовані компанії виділяють час своїх розробників і ресурси на підтримку інструментів з відкритим вихідним кодом, які вони використовують. І в результаті виходить, що купа різних компаній співпрацюють над підтримкою цієї речі, і так само це може працювати в Етеріумі. Тож якщо у вас є больова точка, яку ви визначили, ви можете знайти розробника Base, який має схожу больову точку, а Base — це добре капіталізована організація, і тому вони, ймовірно, будуть готові виділити деякі ресурси на випуск функції або супровід функції через хардфорк Етеріуму.

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