Визначення
Client diversity — це наявність у мережі кількох незалежних реалізацій клієнтського програмного забезпечення (валідаторів), кожна з яких написана окремою командою, іншою мовою програмування та з іншою архітектурою. У контексті Solana це означає, що не всі ноди працюють на одному й тому самому коді, а мають альтернативні варіанти для виконання консенсусу та обробки транзакцій.
Головна мета client diversity — усунути єдину точку відмови на рівні програмного забезпечення. Якщо в одному клієнті є критична вразливість або баг, інші клієнти продовжують утримувати мережу.
Як працює
У блокчейні кожен валідатор запускає клієнтське ПЗ, яке зчитує транзакції, застосовує їх до стану мережі та бере участь у консенсусі. Коли існує лише одна реалізація клієнта, будь-який баг у ній може зупинити чи скомпрометувати всю мережу, оскільки всі ноди виконують однаковий код.
Client diversity вирішує це так:
- Різні команди, різний код. Кожен клієнт розробляється незалежно: інша мова (Rust, C тощо), інші бібліотеки, інший підхід до парсингу транзакцій та зберігання стану.
- Спільний протокол. Усі клієнти реалізовують одну й ту саму специфікацію протоколу Solana, тому вони сумісні між собою на рівні мережевого взаємодії.
- Розподіл навантаження. Чим більша частка мережі працює на альтернативних клієнтах, тим менший ризик масового збою через один баг.
У Solana історично домінував один клієнт — Agave (раніше відомий як solana-labs/solana), написаний на Rust. Розвиток client diversity у цій екосистемі означає появу та впровадження таких альтернативних реалізацій, як Firedancer від Jump Crypto (C/C), а також інших ініціатив, що знаходяться на різних стадіях розробки.
Приклад
Уявіть мережу зі ста валідаторів. Усі сто запускають лише клієнт Agave. У коді Agave виявляється баг, який призводить до краху ноди при обробці певного типу транзакції. Усі сто валідаторів виходять з ладу одночасно — мережа зупиняється.
Тепер уявіть, що 70 валідаторів працюють на Agave, а 30 — на Firedancer. Той самий б'яг змушує 70 нод Agave зупинитися, але 30 нод Firedancer продовжують працювати. Мережа залишається функціональною: транзакції обробляються, нові блоки створюються, а команда Agave отримує час на виправлення без повної зупинки екосистеми.
Типова помилка
Поширене хибне уявлення — вважати, що client diversity автоматично досягається самим фактом існування альтернативного клієнта в репозиторії. Насправді важлива не наявність коду, а реальна частка мережі, яка на ньому працює. Якщо альтернативний клієнт запущено на 1 % валідаторів, практичний захист від масового збою майже відсутній. Client diversity — це показник розподілу, а не просто кількість репозиторіїв.
Інша помилка — плутати client diversity із децентралізацією апаратного забезпечення або географічним розподілом нод. Це різні виміри безпеки: клієнтська різноманітність стосується виключно програмного стеку валідаторів.
Пов'язані матеріали
Внутрішні переходи
- Consensus — про те, як валідатори Solana досягають узгодженості щодо стану мережі, і яку роль у цьому відіграє клієнтське ПЗ.
- Fork — про розгалуження ланцюжка та ситуації, коли різні клієнти можуть тимчасово не збігатися в інтерпретації стану.
Додаткові ресурси
Для актуального стану впровадження альтернативних клієнтів у Solana рекомендується переглядати офіційні репозиторії проєктів та дорожні карти розробників, оскільки ця сфера активно розвивається і конкретні відсотки розподілу клієнтів змінюються з часом.