Огляд викликів безпеки

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

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

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

1.1 Керування ключами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.5 Приватність

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 Ланцюги рівня 2 (l2)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.6 Цензура на рівні інтернет-провайдера

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.1 Централізація стейку

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

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

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

6.2 Централізація позамережевих активів

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

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

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

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

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

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

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