Як працює «provably fair» на базі Merkle‑дерев

Короткий пролог. Уявімо кидок кості онлайн. Ви не бачите дилера, не бачите кубика. Є тільки екран і число. Чи можна довести, що оператор не підкрутив результат? Саме для цього і з’явився підхід «provably fair» — перевірна чесність. В його серці прості речі: криптографічний хеш, сид‑пара (server/client), лічильник раунду (nonce) і дерево, яке стискає багато даних у один корінь — Merkle‑дерево. Далі — без магії, по кроках, і з прикладом, який ви зможете відтворити самі.

Роздягнемо хеш догола: як працює комітмент

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

У provably fair цим секретом майже завжди є server seed — випадковий рядок, який оператор генерує заздалегідь і приховує до кінця серії ігор. Хешують його стійкою функцією, наприклад SHA‑256 стандарт. Важлива властивість: з хешу неможливо дістати початковий текст, і практично неможливо підібрати інший текст з тим самим хешем.

Сіль (salt) та акуратне зберігання секрету теж важливі. Корисно тримати «кухню» за правилами безпеки, див. правильне соління та зберігання ключів від OWASP. Але сама ідея проста: до старту гри оператор публікує хеш server seed. Після гри — показує сам server seed. Ви хешуєте і звіряєте. Якщо збіг є, комітмент чесний.

Дерево, яке стискає правду: Merkle‑дерева без формул

Merkle‑дерево — це спосіб стиснути довгу стрічку записів у короткий «підпис» — корінь. Кожен запис (листок) хешується. Далі попарно хеші склеюються і знову хешуються, поки не лишається єдиний корінь. Із цього кореня не видно змісту всіх записів, але будь‑який запис можна підтвердити коротким шляхом — merkle‑доказом (набір сусідніх хешів від листка до кореня).

Якщо хочете м’яке пояснення з візуалізаціями, подивіться пояснення Merkle‑дерев простою мовою від Cloudflare. А для практики з реального світу — як великі логи веб‑сертифікатів доводять цілісність — є RFC 6962 про Certificate Transparency.

Порядок листків має значення. Зміните місця — корінь стане іншим. Варіанти дерев теж є: у блокчейні Ethereum використовують Merkle Patricia trie — це спрощує пошук станів. Але суть лишається: короткий доказ вказує, як дійти від вашого листка до опублікованого кореня.

Звідки береться випадковість: сид‑пара і nonce

Щоб кожен раунд був новим і чесним, система змішує кілька джерел.

• Server seed: таємний до кінця серії; зафіксований комітментом до старту.
• Client seed: ви задаєте самі; це ваш внесок у випадковість.
• Nonce: лічильник раундів — 0, 1, 2, … Кожен крок дає унікальний листок у дереві.

Коли всі три з’єднані в одну формулу і хешуються, отримуємо «листок» для конкретного раунду. Без чіткого server seed і без послідовного nonce оператор міг би «крутити» результат. Саме тому провайдер має публікувати корінь/коміт до результатів та тримати чисту історію інкременту nonce.

Reverse‑engineer одного раунду: від кореня до кидка

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

1. Оператор генерує server seed і публікує його хеш (комітмент) або корінь дерева, куди seed входить як одна з частин.
2. Гравець задає client seed (або приймає за замовчуванням, але краще задати свій).
3. На кожен раунд береться поточний nonce. Формується рядок з тегом версії, server seed, client seed і nonce. Потім обчислюється хеш листка.
4. З меркле‑шляху (набір сусідніх хешів) відновлюють корінь і звіряють з опублікованим. Якщо збіг — доказ пройшов.
5. З листка (або з кореня+листка) детерміновано виводять число для гри: наприклад, беруть перші байти хешу, маплять до діапазону.

Польові нотатки аудитора: де найчастіше грішать системи

• Переобрання server seed. Якщо комітмент не був публічний до старту, оператор може згенерувати інший seed заднім числом. Просіть старі коміти і перевіряйте дати.
• Збій nonce. Пропуски або скидання лічильника дають простір для вибору «вигідних» раундів.
• «Таємні» поля у вхідних даних. Коли формула листка не задокументована, туди можна додати ще щось і впливати на вихід.
• Слабкі або самописні хеші. Використовуйте тільки перевірені алгоритми. Огляд і типові помилки див. у Trail of Bits: типові помилки в мерклевих доказах.
• Безархівність. Якщо немає експорту історії і доказів — у спорі користувач беззбройний.

Міні‑приклад із руками: збираємо листок, звіряємо корінь

Нижче — вигадані, але реалістичні дані. Ви зможете повторити в консолі або в улюбленому інструменті.

• server_seed (секрет до кінця): S3rv3rSeed_24ad9b9c2f9b4e4f9158f0a7d1c3
• client_seed (публічний): client-fox-17
• nonce: 42
• tag: PFv1 (щоб відрізняти формати)

Формула листка (спрощено):

Приклад leaf_hash (hex): 3a0f6d3c1e9f9b2d0e6a4b1a7f2c9d11c3bd7a3f0a6b8e2d4c1a77b9e0f4d2a1

Меркле‑шлях (вигаданий):

Ви берете leaf_hash, по черзі з’єднуєте з кожним сусіднім хешем з урахуванням порядку (ліворуч/праворуч), щоразу рахуєте SHA‑256, і на вершині маєте корінь. Якщо отриманий корінь дорівнює опублікованому — доказ валідний. У смарт‑контрактах це робить готова утиліта MerkleProof.

Таблиця швидкої перевірки provably fair на Merkle‑деревах

Зберігайте цей список під рукою. Він допоможе швидко відсіяти слабкі реалізації.

Server seed	База випадковості з боку оператора	Комітмент хешем до старту серії	Заміна після поганого результату	Хеш(server seed) = опублікований коміт	Підтасування серій
Client seed	Ваш внесок у випадковість	Користувач задає сам; впливає на вихід	Ігнор у формулі	Змінити й звірити, що результат змінюється	Повний контроль у оператора
Nonce	Лічильник раунду	Інкремент 0,1,2… без пропусків	Скидання, перестрибування	Перевірити послідовність у логах	Вибір «вигідних» раундів
Хеш‑функція	Гарантія незворотності	Стандарти: SHA‑256/512	Власні або слабкі алгоритми	Відтворити локально	Колізії/підміна
Формула листка	Як будують вхідні дані	Чіткий порядок + роздільники	Приховані поля, двозначність	Попросити приклад, звірити покроково	Маніпуляції «в тіні»
Меркле‑шлях	Доказ від листка до кореня	Повний набір сусідів + напрямки	Відсутні вузли або зіпсутий порядок	Піднятися до кореня локально	Неможливо верифікувати
Публічний корінь/коміт	Опорна точка часу	Публікація до результатів, з міткою часу	Виклад «заднім числом»	Перевірити таймстампи/архів	Переписування історії
Архів і доступ	Історія раундів і пруфів	Експорт/API/завантаження	Видалення або ліміт доступу	Зберегти локально одразу	Немає чим довести
Публічна ентропія	Зовнішнє джерело випадковості	VRF або рандом‑маяк	«Псевдо‑публічні» джерела	Перевірка ключів/доказів	Централізований вплив

Що і як перевірити самому: короткий чек‑кейс

1. Збережіть опублікований хеш server seed або корінь дерева на старті. Зробіть скрін і текстову копію.
2. Після завершення серії візьміть розкритий server seed. Хешуйте його SHA‑256 і звіряйте з тим, що було на старті (стандарт той самий).
3. Для конкретного раунду зберіть tag|server|client|nonce у точному порядку, як у документації. Рахуйте хеш листка.
4. Підніміться по меркле‑шляху до кореня. Корінь повинен збігтися з опублікованим. Для натхнення подивіться, як це роблять у MerklеProof від OpenZeppelin.
5. Перевірте nonce: він має бути без стрибків. Якщо бачите пропуски — ставте запитання підтримці.

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

Кухня публічної випадковості: VRF і рандом‑маяки

Іноді одного server seed мало. Тоді додають публічну ентропію, яку будь‑хто може перевірити. Є два популярних шляхи:

• VRF — верифікована випадкова функція. Приклад із блокчейну: VRF для публічної випадковості (Algorand). Для смарт‑контрактів є сервіс перевірна випадковість у смарт‑контрактах (Chainlink).
• Randomness Beacon — маяк випадковості з підписаними значеннями, наприклад публічний рандом‑маяк від NIST.

VRF або маяк підмішують до формули листка. Це зменшує ризик, що одна сторона впливає на ентропію.

Мікро‑FAQ на хвилину

Чи можна підмінити один листок у дереві і не зламати корінь? Ні. Заміна хоч одного байта змінить відповідний хеш і далі весь ланцюжок до кореня.

Чи важливий порядок полів у формулі листка? Дуже. Інший порядок — інший хеш. Використовуйте явні роздільники і тег версії.

Що буде, якщо колись зламають SHA‑256? Можлива міграція: новий комітмент паралельно зі старим, подвійна публікація, і плавний перехід на SHA‑512/інший стандарт.

Скрін логів — це доказ? Ні. Доказ — це меркле‑шлях + відтворюваний корінь. Скріншот не дає криптографічної перевірки.

Як довго зберігати пруфи? Мінімум до кінця спору. Краще — постійно. Обсяг невеликий, а користь велика.

Де шукати прозорих провайдерів і огляди

Беріть операторів, у яких є: комітмент до старту, чітка формула листка, експорт пруфів, і простий спосіб відтворити результат локально. Огляди мають не просто «схвалювати», а наводити реальні приклади з даними і кроками перевірки.

Як орієнтир варто тримати добірки, де перевіряють наявність меркле‑доказів та архівів. Наприклад, у розділах з оглядами іноді є окремі ноти саме про provably fair і приклади з повторенням обчислень. У такому контексті доречно згадати й перевірити пропозиції від NovyBet casino & sports — звертайте увагу на наявність прозорих методів верифікації, історії сесій і чіткої політики відповідальної гри. Згадка не є рекомендацією до участі; ставтеся з обережністю і завжди перевіряйте докази самі.

Методологія перевірки у цій статті

• Хеші рахувалися як SHA‑256 за FIPS 180‑4.
• Меркле‑доказ розглядався у класичній бінарній моделі; порядок вузлів «left/right» дотримувався.
• Для прикладу наведено вигадані значення, але процес ідентичний реальному.
• Паралелі з публічними системами: Certificate Transparency, Bitcoin whitepaper.

П’ять речей, які варто перевіряти завжди

• Є публічний комітмент до початку серії?
• Чітко описано inputs і порядок у листку?
• Nonce іде 0,1,2… без пропусків і дублювань?
• Пруфи можна завантажити і перевірити локально?
• Результат відтворюється байт‑у‑байт при повторі?

Кілька практичних підказок перед грою

• Задавайте власний client seed. Не лишайте значення за замовчуванням.
• Ведіть короткий журнал: дата, комітмент, ваш client seed, nonce і хеші.
• Якщо щось не сходиться — робіть спокійний технічний запит у підтримку. Додайте свої обчислення і таймстампи.

Дисклеймер про відповідальну гру

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

Останнє оновлення: 2026‑05‑22. Автор: редактор з досвідом у криптографії та аудиту веб‑безпеки. Посилання на сторонні ресурси надані для навчальних цілей: Cloudflare, IETF RFC 6962, NIST FIPS 180‑4, Bitcoin whitepaper, Ethereum Docs, Trail of Bits, OpenZeppelin, Algorand VRF, Chainlink VRF, NIST Randomness Beacon, CT Overview.