Перейти до основного контенту
Change page

Різноманіття клієнтів

Останні оновлення сторінки: 27 жовтня 2025 р.

wackerowwopens in a new tab
LifeofDan-ELLopens in a new tab
victorelec14vopens in a new tab
+19

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

Передумови

Якщо ви ще не знаєте, що таке вузли та клієнти, перегляньте статтю вузли та клієнти. Визначення та можна знайти в глосарії.

Чому існують множинні клієнти?

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

Чому різноманітність клієнтів важлива?

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

Помилки

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

Стійкість до атак

Різноманітність клієнтів також забезпечує стійкість до атак. Наприклад, атака, що обманом заманює певного клієнтаopens in a new tab в певну гілку ланцюжка, навряд чи буде успішною, оскільки інші клієнти навряд чи будуть вразливими таким же чином, а канонічний ланцюжок залишиться неушкодженим. Низька різноманітність клієнтів збільшує ризик, пов'язаний зі зломом домінуючого клієнта. Різноманітність клієнтів вже виявилася важливим захистом від зловмисних атак на мережу, наприклад, Шанхайська атака на відмову в обслуговуванні в 2016 році стала можливою завдяки тому, що зловмисники змогли обдурити домінуючий клієнт (Geth), змусивши його виконувати операції вводу-виводу на повільному диску десятки тисяч разів за блок. Оскільки в мережі також були альтернативні клієнти, які не мали вразливості, Ethereum зміг протистояти атаці і продовжити роботу, поки вразливість в Geth не була виправлена.

Завершеність proof-of-stake

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

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

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

Спільна відповідальність

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

Поточна різноманітність клієнтів

Клієнти виконання

Клієнти консенсусу

Ця діаграма може бути застарілою — перейдіть на ethernodes.orgopens in a new tab та clientdiversity.orgopens in a new tab для отримання актуальної інформації.

Дві кругові діаграми вище показують знімки поточної різноманітності клієнтів для рівнів виконання та консенсусу (на момент написання в жовтні 2025 року). Різноманітність клієнтів з роками покращилася, і на рівні виконання спостерігається зменшення домінування Gethopens in a new tab, Nethermindopens in a new tab посідає друге місце, Besuopens in a new tab — третє, а Erigonopens in a new tab — четверте, при цьому інші клієнти становлять менше 3% мережі. Найчастіше використовуваний клієнт на рівні консенсусу — Lighthouseopens in a new tab — має показники, близькі до другого за популярністю клієнта. На Prysmopens in a new tab та Tekuopens in a new tab припадає ~31% і ~14% відповідно, а інші клієнти використовуються рідко.

Дані рівня виконання були отримані з supermajority.infoopens in a new tab 26 жовтня 2025 року. Дані для клієнтів консенсусу були отримані від Michael Sproulopens in a new tab. Дані про клієнтів рівня консенсусу отримати складніше, оскільки клієнти рівня консенсусу не завжди мають однозначні сліди, які можна використати для їхньої ідентифікації. Дані були згенеровані за допомогою алгоритму класифікації, який іноді плутає деяких клієнтів меншості (докладніше дивіться тутopens in a new tab). На діаграмі вище ці неоднозначні класифікації обробляються з позначкою «або/або» (наприклад, Nimbus/Teku). Тим не менш, очевидно, що більша частина мережі використовує Prysm. Попри те, що це лише знімки, значення на діаграмі дають гарне загальне уявлення про поточний стан клієнтського розмаїття.

Актуальні дані про різноманітність клієнтів для рівня консенсусу тепер доступні на clientdiversity.orgopens in a new tab.

Рівень виконання

Досі розмова про клієнтське розмаїття зосереджувалася переважно на рівні консенсусу. Однак на клієнт виконання Gethopens in a new tab наразі припадає близько 85% усіх вузлів. Цей відсоток є проблематичним з тих же причин, що і для консенсусних клієнтів. Наприклад, помилка в Geth, що впливає на обробку транзакцій або побудову корисного навантаження виконання, може призвести до того, що консенсусні клієнти завершуватимуть проблемні або пошкоджені транзакції. Тому Ethereum був би працездатнішим при більш рівномірному розподілі клієнтів виконання, в ідеалі, коли жоден клієнт не представляв би понад 33% мережі.

Використовуйте клієнт меншості

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

Клієнти виконання

Клієнти консенсусу

Технічні користувачі можуть допомогти прискорити цей процес, написавши більше навчальних посібників і документації для міноритарних клієнтів і заохочуючи своїх колег, які працюють на вузлах, мігрувати від домінуючих клієнтів. Посібники з переходу на клієнт консенсусу меншості доступні на clientdiversity.orgopens in a new tab.

Панелі моніторингу різноманітності клієнтів

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

Консенсусний шар:

Рівень виконання:

Для подальшого читання

Пов'язані теми

Чи була ця стаття корисною?