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

Статус клієнтів для «Conformance testing: як перевіряється сумісність клієнтів Solana» перевірено 2 серпня 2026 року. Frankendancer — гібрид Agave/Firedancer — працює на mainnet-beta щонайменше з 2025 року: офіційна програма делегування повідомляла майже про 200 валідаторів у вересні 2025 року. Повний Firedancer є окремою реалізацією мовою C; його поточне впровадження та частку валідаторів потрібно звіряти з офіційним звітом, а не з давніми твердженнями про «лише testnet».

Що таке conformance testing

Визначення та цілі тестування відповідності

Conformance testing (тестування відповідності) — це процес, у якому реалізація програмного забезпечення перевіряється на відповідність формальній специфікації. У контексті Solana це означає: якщо два клієнти отримують однакову послідовність слотів і транзакцій, вони мають продукувати ідентичний банк слотів (bank state) та ідентичні кореневі хеші.

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

Чому це критично для мультиклієнтної мережі

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

  • Порядок обробки транзакцій у межах одного пакету, коли кілька транзакцій конкурують за один і той самий баланс акаунта.
  • Обробка граничних випадків обчислення витрат (compute budget) — зокрема поведінка при нульовому ліміті або переповненні.
  • Точність арифметики з цілими числами у внутрішніх розрахунках (rounding, overflow, truncation).
  • Порядок виклику програм через CPI (Cross-Program Invocation) за умов складних графів залежностей.

Без conformance testing ці розбіжності виявляються вже на mainnet-beta у вигляді форків або невалідних блоків, що прямо загрожує безперервності мережі.

Інструменти та методологія

Тестові набори та покриття сценаріїв

Основний інструментарій для conformance testing у Solana базується на фіксованих дампах стану (snapshot-based test vectors) та записаних трейсах виконання. Методологія включає кілька рівнів:

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

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

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

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

Автоматизоване порівняння поведінки клієнтів

Архітектура порівняння зазвичай реалізується як окремий тестовий раннер, який:

  1. Завантажує фіксований вхідний вектор із репозиторію тестових даних.
  2. Передає його кожній реалізації через уніфікований інтерфейс (зазвичай — виклик функції обробки слота або транзакції без залучення мережевого стека).
  3. Збирає вихідні дані: фінальний стан акаунтів, хеш банку слота, логи виконання, списки відхилених транзакцій із причинами.
  4. Порівнює виходи попарно та формує звіт про розбіжності.

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

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

Поточний стан conformance у Solana

Результати для Agave, Firedancer та Frankendancer

Agave (форк оригінального клієнта на Rust) фактично слугує еталонною реалізацією, відносно якої вимірюється відповідність інших клієнтів. Це створює методологічне напруження: conformance з Agave не є синонімом конформності специфікації, оскільки сам Agave може містити поведінку, яка не задокументована формально, але стала де-факто стандартом.

Firedancer (клієнт на C від Jump Crypto) проходить conformance testing поступово. Спочатку покриваються базові сценарії обробки транзакцій, потім — складніші випадки з CPI та межами обчислень. Оскільки Firedancer переписує значну частину стеку з нуля, а не форкає існуючий код, розбіжності на етапі інтеграції є очікуваними і системно усуваються.

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

Конкретні відсотки проходження тестових векторів та перелік невирішених розбіжностей змінюються часто. Рекомендується перевіряти актуальні звіти безпосередньо у репозиторіях відповідних клієнтів у розділах conformance або test-results.

Відкриті проблеми та напрямки вдосконалення

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

Серед практичних напрямків вдосконалення:

  • Розширення покриття векторів. Значна частина edge-кейсів ще не формалізована у вигляді тестових векторів. Зокрема, складні сценарії з стейкінгом, делегуванням та управлінням потребують окремих наборів.
  • Інтеграція з фаззингом. Поєднання фіксованих векторів із генеративним фаззингом дозволяє знаходити розбіжності в сценаріях, які не були передбачені вручну. Проте це вимагає додаткової інфраструктури для відтворення знайдених розбіжностей.
  • Тестування продуктивності як складової conformance. Клієнт може бути логічно конформним, але непридатним для виробництва через невідповідність часовим обмеженням слота. Формалізація цих вимог у рамках conformance поки що не стандартизована.
  • Уніфікація інтерфейсів тестування. Кожен альтернативний клієнт зараз реалізує власну адаптацію для запуску conformance-тестів. Стандартизація інтерфейсу знизить бар'єр входу для нових реалізацій.

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

Джерела