Як читати звіт про доказ резервів: кожне поле і що воно каже

2026-09-20

Як читати звіт про доказ резервів: кожне поле і що воно каже

Звіт про доказ резервів невеликий, але несучих деталей у ньому багато. Ідентифікатор періоду каже, який знімок перед вами, дата знімка — коли баланси було заморожено, версія алгоритму — як побудовано дерево, кореневий хеш — те, з чим зобов'язана збігтися ваша власна перевірка, а покриття за монетами — чи вистачало активів на баланси. Розберемо поле за полем: для чого кожне і де кожне здатне ввести в оману.

Читання звіту про доказ резервів: період, дата знімка, версія алгоритму, кореневий хеш і покриття за монетами

Що насправді міститься в розкритті

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

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

Добре читати звіт означає тому знати, які поля несучі. Далі їх розібрано в порядку значущості.

Поля і для чого кожне

Поле Що це На що дивитися
Ідентифікатор періоду Про яке розкриття йдеться Чи збігається з періодом вашого файлу
Дата знімка Коли заморожено баланси Ваше поповнення було до неї чи після
Версія алгоритму Як побудовано дерево Чи реалізує ваш верифікатор цю версію
Статус Чи остаточний період Що він опублікований, а не в очікуванні
Кореневий хеш Зведення всього дерева Що він дорівнює вашому порахованому кореню
Покриття за монетою Активи, поділені на зобов'язання Що за кожною монетою не нижче 100%
Перелік охоплення Які активи включено Які ваші активи поза охопленням

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

Період і дата знімка

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

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

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

Версія алгоритму і чому її друкують

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

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

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

Кореневий хеш

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

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

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

Покриття та перелік охоплення

Резервне покриття — це ончейн-активи, поділені на зобов'язання перед користувачами, а 100% є порогом. На ньому або вище біржа тримала достатньо цієї монети, щоб покрити баланси на момент знімка.

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

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

Чого у звіті немає навмисно

Доказ резервів є твердженням про активи в момент часу, і звідси випливають три речі, про які не скаже жодне поле звіту.

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

Ніщо з цього не робить звіт слабким. Це робить його конкретним, що властивість корисніша, і саме тому бік зобов'язань потребує окремого розбору в статті доказ резервів і зобов'язання.

Підсумок

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

Потім читайте саме твердження. Кореневий хеш зобов'язаний збігтися з порахованим вами, покриття за кожною охопленою монетою зобов'язане бути не нижче 100%, а перелік охоплення підкаже, про які ваші активи звіт узагалі не висловлювався. Звіт, у якому немає будь-якого з цих полів, не коротший: він просто не піддається повній перевірці. Читайте далі матеріали Bitbase Academy.

Схожі матеріали

Інші матеріали Bitbase на цю тему:

Застереження: Ця стаття є освітнім матеріалом Bitbase Academy і надається лише для інформації. Вона не є інвестиційною, торговою, податковою чи фінансовою порадою. Криптоактиви волатильні — оцінюйте ризики самостійно. Написано станом на вересень 2026 року; орієнтуйтеся на найновішу офіційну інформацію.

Джерела

[1] Bitbase, «Доказ резервів» — щомісячне розкриття, корінь Меркла та відкритий верифікатор www.bitbase.com

Пов'язані статті

Більше
Токенізовані акції, акції та безстрокові контракти: власність, дивіденди й голос

Токенізовані акції, акції та безстрокові контракти: власність, дивіденди й голос

2026-09-21

Токенізовані акції в гаманці: переказ, самостійне зберігання, години торгів і погашення

Токенізовані акції в гаманці: переказ, самостійне зберігання, години торгів і погашення

2026-09-21

Ризики токенізованих акцій: емітент, ліквідність, відстеження ціни та погашення

Ризики токенізованих акцій: емітент, ліквідність, відстеження ціни та погашення

2026-09-21