Як новий клієнт проходить шлях від тестів до реальної частки мережі

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

Яке технічне питання тут головне

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

Межа аналізу: цей матеріал описує загальну структуру шляху для будь-якого нового клієнта в екосистемі Solana. Він не розглядає, які саме проблеми розв’язує той чи інший клієнт — це тема окремого матеріалу про Firedancer та його завдання. Він також не є інструкцією для валідаторів — це тема наступної статті кластера. Загальний огляд різноманіття реалізацій доступний у матеріалі про клієнти мережі.

Місце теми в системі: клієнти — це один із трьох стовпів мережі разом із протоколом консенсусу та економікою стейкінгу. Зміна в клієнтному рівні впливає на розподіл стейку, безпеку форків та доступність RPC-вузлів для продуктів Solana. Детальніше про цю систему — у загальному хабі «Під капотом».

Що відбувається під капотом

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

Етап 1: Ізольовані тести

На цьому етапі клієнт не підключається до жодної мережі. Розробники перевіряють окремі компоненти: обробку транзакцій, підписування, серіалізацію блоків, роботу з акаунтами. Типові інструменти — модульні тести, property-based тести, фаззинг.

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

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

Етап 2: Локальний кластер

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

Ключовий критерій: клієнт має досягати консенсусу з еталонним клієнтом (зазвичай Agave) у контрольованих умовах без мережевих затримок і без атаки.

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

Етап 3: Devnet

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

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

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

Етап 4: Testnet

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

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

Обмеження етапу: навіть з наближеними параметрами testnet не має тієї економічної цінності, яка створює реальні стимули для витончених атак. Поведінка учасників відрізняється від mainnet.

Етап 5: Аудит безпеки

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

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

Етап 6: Mainnet-beta

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

Що перевіряється: здатність працювати з реальними даними, реальним навантаженням, реальною топологією мережі — без ризику впливу на консенсус.

Обмеження етапу: mainnet-beta не показує, як клієнт поводиться, коли його голоси реально формують консенсус. Помилка, яка не проявляється в режимі спостереження, може проявитися за активної участі.

Етап 7: Mainnet із реальним стейком

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

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

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

Нижче — узагальнена таблиця етапів із ключовими параметрами.

Етап	Середовище	Реальний стейк	Що доводить	Чого не доводить
Ізольовані тести	Локальна машина	Ні	Коректність окремих компонентів	Коректність взаємодії з мережею
Локальний кластер	Контрольована multi-node	Ні	Базову здатність до консенсусу	Стійкість до реальних мережевих умов
Devnet	Публічне тестове	Ні (умовний)	Роботу в реальній топології	Поведінку за mainnet-параметрів
Testnet	Тестове з наближеними параметрами	Ні (умовний)	Поведінку за наближених до mainnet умов	Реакцію на реальні економічні стимули
Аудит	Аналіз коду	Ні	Відсутність знайдених вразливостей	Повну відсутність вразливостей
Mainnet-beta	Основна мережа	Ні	Роботу з реальними даними	Безпеку реальної участі в консенсусі
Mainnet із стейком	Основна мережа	Так	Повну участь у консенсусі	—

Як вимірюється «реальна частка мережі»

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

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

Де факти, а де інтерпретація

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

Що потрібно для перевірки поточного статусу

Якщо читач хоче дізнатися, на якому етапі зараз перебуває конкретний клієнт, необхідні такі джерела:

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

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

Позиція розробників клієнта

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

Позиція валідаторів

Валідатори — це сторони, які приймають рішення про перехід. Їхня позиція визначається співвідношенням ризику та потенційної вигоди. Ризик очевидний: помилка в клієнті може призвести до простою, пропущених винагород, операційних збитків або репутаційних втрат. За актуальною документацією Solana про стейкінг протокольний slashing зараз не реалізований, тому його не слід подавати як чинний наслідок помилки клієнта. Вигода менш очевидна і залежить від контексту: підвищена продуктивність, зниження витрат на інфраструктуру, диверсифікація клієнтного ризику для мережі в цілому.

Детальні критерії, за якими валідатор приймає рішення — тема окремої статті.

Позиція мережі як спільноти

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

Відкриті змінні

Компроміс швидкості та безпеки

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

Ризик консенсусного розбіжності

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

Протокольний факт: механізм консенсусу Solana (Tower BFT) визначає кінцевий стан ланцюга на основі голосів валідаторів, зважених за стейком. Якщо клієнт з помилкою починає голосувати за некоректний стан і за ним стоїть значний стейк, це створює загрозу для консенсусу.

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

Ризик «довіри до аудиту»

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

Невизначеність з поведінкою за масштабування

Деякі помилки виявляються лише за певного рівня навантаження або певної конфігурації мережі. Наприклад, стан гонитви (race condition) може не проявлятися в тестовій мережі з низьким навантаженням, але спрацьовувати в mainnet за пікових транзакцій. Ця невизначеність принципово не усувається тестуванням — вона знижується, але залишається.

Невизначеність із часом перебування на кожному етапі

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

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

Висновок і наступна перевірка

Шлях нового клієнта від тестів до реальної частки мережі — це послідовність середовищ із зростаючою відповідальністю. Кожен етап розширює зону перевірки, але жоден не усуває невизначеність повністю. Перехід від mainnet-beta до mainnet із реальним стейком є якісним стрибком: саме тут клієнт перестає бути спостерігачем і стає учасником консенсусу.

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

Що перевірити далі

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

Якщо вас цікавить, чому взагалі виникає потреба в нових клієнтах і які проблеми вони розв’язують, дивіться матеріал про завдання Firedancer як приклад мотивації створення альтернативного клієнта.

Загальний контекст — у огляді клієнтів мережі Solana та хабі «Під капотом».

Редакція солана.укр

Джерела для перевірки. Актуальні технічні деталі варто звіряти з первинними джерелами: офіційний репозиторій та офіційний репозиторій.