Огляд викликів у сфері безпеки

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

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

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

1.1 Управління ключами

Багато користувачів не готові до безпечного керування криптографічними ключами.

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

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

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

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

1.2 Сліпий підпис і невизначеність транзакцій

Користувачі регулярно схвалюють транзакції «наосліп», не розуміючи, що вони роблять. Гаманці часто показують необроблені шістнадцяткові дані, скорочену адресу контракту або іншу інформацію, якої недостатньо для того, щоб користувач зрозумів наслідки певної транзакції. Це робить користувачів усіх типів вразливими до зловмисних смарт-контрактів, фішингу, шахрайства, підроблених інтерфейсів, компрометації фронтенду та простих помилок користувача.

1.3 Керування схваленнями та дозволами

У багатьох застосунках Ethereum користувачі часто надають певні дозволи базовому застосунку в рамках звичайного використання. Наприклад, користувач може надати децентралізованій біржі, як-от Uniswap, дозвіл на переміщення своїх токенів для обміну їх на ETH.

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

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

Це однаково є ризиком і для організаційних користувачів. Наприклад, організація може надати маршрутизатору DEX необмежений дозвіл на використання USDC для операційної зручності, що потім наражає її на ризики, якщо контракт маршрутизатора буде оновлено.

1.4 Скомпрометовані вебінтерфейси

Більшість користувачів не взаємодіють безпосередньо зі смарт-контрактом, а через вебінтерфейс на своєму мобільному пристрої або у веббраузері.

Ці фронтенди можуть бути вразливими до атак через знайомі засоби, як-от перехоплення DNS, впровадження зловмисного JavaScript, небезпечний хостинг або різноманітні залежності від третіх сторін. Скомпрометований UX застосунку може перенаправляти користувачів усіх типів на зловмисні смарт-контракти або змушувати їх підписувати оманливі транзакції.

1.5 Конфіденційність

Конфіденційність може пом'якшити або посилити ризики безпеки для користувачів усіх типів.

Слабші засоби захисту конфіденційності наражають окремих користувачів на різноманітні цілеспрямовані загрози, як-от фішинг, експлуатація, шахрайство або фізичні напади. Багато поширених шаблонів UX наражають користувачів на ризик, наприклад, повторне використання адрес, дані KYC та інші витоки метаданих.

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

1.6 Фрагментація

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

Наприклад, користувачі не можуть покладатися на послідовні підказки UX для захисту від фішингу та спуфінгу, оскільки вони відрізняються в різних гаманцях. Користувачі не можуть сформувати надійні очікування щодо того, як працює Ethereum, якщо кожен інструмент функціонує по-різному.

Безпека смарт-контрактів радикально покращилася за історію Ethereum. Ранні інциденти безпеки, як-от злом DAO, мотивували екосистему професіоналізуватися та вдосконалити засоби захисту протягом усього життєвого циклу програмного забезпечення, що призводить до розгортання коду на блокчейні. Основні досягнення включають:

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

Однак у цій сфері залишаються слабкі місця та напрямки для вдосконалення.

2.1 Уразливості контрактів

Незважаючи на досягнення в галузі безпеки смарт-контрактів, все ще існують уразливості, які можуть призвести до значних проблем з безпекою, зокрема:

• Ризик оновлення контракту. Деякі контракти розроблені таким чином, щоб їх можна було змінювати після розгортання, щоб команда розробників могла продовжувати оновлювати та вдосконалювати застосунок. Однак це створює ризики. Оновлення можуть призвести до нових уразливостей або повної втрати коштів користувачів у разі зловмисного оновлення.
• Повторний вхід, де контракт А викликає зовнішній контракт Б перед оновленням власного внутрішнього стану, а контракт Б викликає назад початковий контракт А до завершення першого виклику.
• Небезпечне використання зовнішніх бібліотек, де контракт викликає зовнішню бібліотеку, яка може бути неперевіреною, зловмисною або оновлюваною.
• Неперевірені компоненти. Хоча аудит та використання стандартних бібліотек покращилися, розробники іноді покладаються на неперевірені компоненти у своїх застосунках.
• Збої в контролі доступу, коли дозволи налаштовані неправильно або визначені занадто широко, що дозволяє зловмисникам вживати зловмисні дії.
• Несанкціонований доступ, коли приватний ключ, здатний контролювати контракт, отримує зловмисник.
• Мости та міжмережеві взаємодії. Мости та міжмережеві протоколи додають додаткову складність, і зловмисники можуть використовувати слабкі місця в тому, як передаються або перевіряються міжмережеві повідомлення.
• Делегування або неправильне використання підпису облікового запису, що належить зовнішній стороні (EOA). Зловмисні застосунки можуть обманом змусити користувачів підписати повне делегування свого облікового запису іншій стороні, що уможливлює крадіжку. Зловмисні застосунки також можуть використовувати підписані повідомлення від користувача несподіваними способами, наприклад, в атаці повторного відтворення.
• Новий ризик помилок, що виникають через генерацію коду штучним інтелектом або автоматизовані інструменти рефакторингу.

2.2 Досвід розробника, інструменти та мови програмування

Уразливості потрапляють у розгорнутий код внаслідок помилок розробників. Покращені інструменти для розробників значно спростили розгортання безпечних смарт-контрактів. Проте проблеми залишаються.

• Відсутність безпечних налаштувань за замовчуванням у популярних фреймворках. Деякі інструменти надають пріоритет гнучкості або швидкості над безпекою, встановлюючи небезпечні налаштування за замовчуванням, як-от необмежені схвалення токенів у функції approve(), або не включаючи шаблони контролю доступу за замовчуванням.
• Спеціальний код для розширених операційних елементів керування. Інституційні користувачі зі складними операційними вимогами часто змушені створювати необхідні функції з нуля, що підвищує ризик уразливостей. Існує брак стандартизованих безпечних компонентів або фреймворків для розширених робочих процесів безпеки.
• Непослідовне покриття тестуванням у стеках інструментів, а також відсутність норм щодо використання перевірених методів, як-от фаззинг або перевірка інваріантів.
• Низький рівень впровадження методів формальної верифікації. Методи формальної верифікації є потужними, але вони складні, дорогі, вимагають спеціалізованої експертизи в предметній області та погано інтегровані в стандартні робочі процеси розробників, де їх можна було б використовувати набагато раніше у виробництві програмного забезпечення для перевірки безпеки на етапі специфікації.
• Проблеми, пов'язані з верифікацією контракту. Користувачі та розробники не можуть легко оцінити надійність розгорнутих контрактів, ступінь їхньої перевірки безпеки (наприклад, аудити коду) або наявність прихованих ризиків. Хоча існують рішення для цієї мети, багато проблем залишаються. Інструменти, що вирішують ці проблеми, не є широко поширеними, стандарти, які б уніфікували підходи, залишаються фрагментованими, а деякі з наявних сервісів самі є централізованими залежностями.
• Ризики компілятора. Компілятори (програмне забезпечення, що перетворює людський читабельний код, як-от Solidity, у байт-код, що використовується самою EVM) можуть мати недоліки, які вносять помилки у смарт-контракти перед їх розгортанням. Екосистема Ethereum сьогодні в основному залежить від компілятора solc, що означає, що помилка може мати широкі наслідки.
• Різноманітність та глибина мов програмування. Хоча Solidity має глибоку екосистему інструментів, побудовану на ньому, деякі розробники хочуть отримати більш сучасні функції безпеки, які є в інших мовах програмування, як-от безпека пам'яті.

2.3 Оцінка ризиків коду на блокчейні

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

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

3.1 Мережі 2-го рівня

Мережі 2-го рівня (L2) слугують розширеннями для Ethereum, забезпечуючи швидші та дешевші середовища, зберігаючи при цьому деякі характерні гарантії безпеки основної мережі Ethereum (залежно від їхньої конкретної конструкції). Однак вони також мають свої власні окремі поверхні атаки, включаючи:

• Складність активів, що переміщуються через кілька мостів. Коли активи переміщуються між L1 та кількома L2, вони піддаються впливу кількох наборів контрактів, кожен з яких має бути безпечним. Невідповідність обліку або збої в мережах L2 можуть створювати уразливості, які можуть бути використані зловмисниками.
• Ролапи L2 покладаються на системи доведення для забезпечення правильності оновлень стану. Помилки або неправильна конфігурація в цих системах можуть зупинити або запобігти фіналізації, або дозволити фіналізацію хибних оновлень стану, що призводить до втрати коштів користувачів.
• Ради безпеки — це групи власників ключів, які слугують «резервним» механізмом для оновлення програмного забезпечення L2 або реагування на певні надзвичайні ситуації. Самі ради безпеки створюють ризики, оскільки компрометація або змова між членами може поставити під загрозу кошти користувачів або заморозити активи.

Дивіться L2Beatopens in a new tab для детального фреймворку та панелі моніторингу, яка оцінює та порівнює продуктивність та безпеку L2.

3.2 RPC та інфраструктура вузлів

Застосунки Ethereum залежать від невеликої кількості постачальників інфраструктури для доступу до RPC, API та послуг вузлів. Це включає як специфічних для криптовалют постачальників інфраструктури, так і традиційні хмарні сервіси, які зазвичай використовуються для розміщення вузлів (наприклад, AWS, Cloudflare, Hetzner).

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

3.3 Уразливості на рівні DNS

Система доменних імен (DNS) є фундаментальним рівнем Інтернету, але вона також централізована і може бути скомпрометована. Багато користувачів отримують доступ до застосунків через вебдомени, які вразливі до:

• Перехоплення DNS, коли зловмисник вставляє зловмисний хибний фронтенд.
• Захоплення домену, коли уряд або реєстратор можуть захопити домени.
• Фішинг за допомогою схожих доменів, коли зловмисники реєструють майже ідентичні імена, щоб заплутати користувачів.

3.4 Ланцюг постачання програмного забезпечення та бібліотеки

Розробники Ethereum покладаються на бібліотеки з відкритим кодом, які часто завантажуються безпосередньо з таких сервісів, як npm, crates.io або GitHub. Якщо ці бібліотеки скомпрометовані, вони можуть стати вектором для атак, як-от:

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

3.5 Служби доставки фронтенду та пов'язані з ними ризики

Багато застосунків Ethereum надають свої фронтенди через мережу доставки контенту (CDN) або хмарну хостингову платформу (наприклад, Vercel, Netlify, Cloudflare). Якщо ці служби скомпрометовані, вони можуть стати вектором для атак, як-от впровадження зловмисного JavaScript, коли зловмисники надають користувачам змінений фронтенд.

3.6 Цензура на рівні постачальника інтернет-послуг

Постачальники інтернет-послуг (ISP) або національні держави можуть використовувати контроль над базовою інтернет-інфраструктурою для цензури доступу до Ethereum. Наприклад, ці атаки можуть включати:

• Блокування або обмеження трафіку на поширені порти Ethereum
• Фільтрація DNS-запитів, що спрямовують на сервіси, пов'язані з Ethereum
• Гео-обмеження або IP-бани проти відомих вузлів Ethereum
• Глибока інспекція пакетів для виявлення та цензури трафіку, пов'язаного з протоколом Ethereum

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

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

4.1 Крихкість консенсусу та ризики відновлення

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

4.2 Різноманітність клієнтів

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

4.3 Централізація стейкінгу та домінування пулів

Значна частина ваги валідаторів зосереджена в протоколах ліквідного стейкінгу, кастодіальних сервісах та великих операторах вузлів. Ця концентрація може призвести до таких ризиків, як:

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

4.4 Невизначений соціальний слешинг та прогалини в координації

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

4.5 Економічні та теоретико-ігрові вектори атак

Багато потенційних економічних векторів атак залишаються недостатньо вивченими, включаючи:

• Атаки скорботи або слешинг-скорботи. Валідатори можуть нести витрати або штрафи за слешинг не через власні помилки, а через ворожу поведінку, спрямовану виключно на шкоду іншим за рахунок зловмисника.
• Стратегічні виходи або тимчасова неактивність. Валідатори можуть навмисно виходити з мережі або виходити в критичні моменти, щоб максимізувати прибутки або порушити консенсус з мінімальними штрафами.
• Змова між валідаторами або ретрансляторами. Скоординована поведінка між валідаторами або між ретрансляторами та валідаторами може зменшити децентралізацію або витягти MEV.
• Використання стимулів у крайніх випадках у MEV, розділенні пропонувача-будівельника або дизайні ліквідного стейкінгу. Актори можуть маніпулювати рідкісними умовами протоколу, щоб отримати надмірні винагороди.

4.6 Квантовий ризик

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

Шляхи міграції до квантово-стійкої криптографії (наприклад, через схеми пост-квантових підписів) потребують розробки, тестування та, можливо, вбудовування в протокол за роки до того, як вони знадобляться. Організації в екосистемі Ethereum, включаючи Ethereum Foundation, активно вивчають ці варіанти та моніторять ризики.

Навіть ідеалізована екосистема блокчейну матиме ризики, атаки та вразливості. Коли щось іде не так, повинні існувати ефективні системи для пом'якшення, виявлення та реагування. Проблеми тут включають:

• Зв'язок із постраждалою командою. Може бути складно зв'язатися з командою, чий застосунок було скомпрометовано. Це може призвести до годинних затримок, обмежуючи можливість реагуючих сторін відновити кошти.
• Ескалація проблем у пов'язаних організаціях. Коли проблема стосується платформи (наприклад, соціальної мережі або централізованої біржі), реагуючим сторонам може бути складно ескалувати проблему, якщо у них немає попереднього контакту.
• Координація реагування. Часто незрозуміло, скільки команд реагування на інциденти допомагають постраждалому застосунку, що призводить до непорозумінь або марних зусиль, коли групові зусилля могли б бути більш ефективними.
• Відсутність можливостей моніторингу. Може бути складно моніторити проблеми на блокчейні та поза ним, що забезпечило б раннє попередження та швидку реакцію на загрози.
• Доступ до страхування. Страхування є важливим інструментом для пом'якшення збитків у більшості традиційних систем, що мають справу з грошима, фінансовими системами, ідентичністю та іншою цінною інформацією. Однак сьогодні традиційні фінансові послуги пропонують небагато варіантів страхування для крипто-екосистеми.

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

6.1 Централізація частки

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

• Координувати або чинити опір форкам.
• Цензурувати певні транзакції або контракти.
• Підривати консенсус спільноти, погрожуючи виходом або опозицією.

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

6.2 Централізація активів поза блокчейном

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

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

6.3 Регуляторна атака або тиск

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

6.4 Організаційне захоплення управління

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

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