Merkle proof может показать, что определённая запись включена в дерево на конкретном снимке. Это узкое утверждение о включении данных, а не самостоятельное доказательство полной платёжеспособности биржи или возможности вывести любую сумму в любой момент.
Сначала зафиксируй границы snapshot
На собственной странице Proof of Reserves Binance описывает Merkle/zk-SNARK проверку пользовательского баланса, record ID и даты снимка. Это описание самого оператора, а не независимая проверка (Binance Proof of Reserves). Если сверяешь свой аккаунт, войди на сайт вручную, найди доступный отчёт и зафиксируй дату, актив и тип счёта. Не отправляй в чат логин, полный баланс или закрытые документы.
В синтетическом учебном дереве есть четыре листа: L1, L2, L3, L4. Пользовательский лист L2 объединён с соседним хешем в узел N1; N1 объединяется с N2 и даёт root. Проверяющий пересчитывает путь L2 → N1 → root с теми sibling hashes, которые входят в proof. Значения здесь условные, это не формат или данные Binance и не реальный Merkle proof.
| Проверка | Что ответить | Чего она не устанавливает |
|---|---|---|
| leaf/record включён в root? | Да/нет в рамках данной схемы и snapshot | Полный объём всех обязательств оператора |
| Какой баланс попал в leaf? | Актив, счёт, значение и дата снимка | Изменения после snapshot |
| Кто контролирует показанные on-chain резервы? | Нужны отдельные адресные доказательства | Что учтены все обязательства и права клиентов |
| Есть ли долг/заёмные активы/контроли? | Proof сам по себе не отвечает на всё это | Solvency, качество governance или доступность средств позже |
PCAOB Office of the Investor Advocate предупреждает, что PoR-отчёты могут быть ограничены по объёму; advisory сотрудников отдельно отмечает, что они не эквивалентны аудиту и могут не охватывать обязательства, права держателей, заимствование активов, внутренние контроли и последующую доступность (PCAOB staff advisory). Это предупреждение о типе отчётов, не вывод о нарушении конкретной биржи.
Попроси модель объяснить путь, не подтвердить биржу
По синтетическому Merkle proof проверь только цепочку leaf → sibling → root,
если все хеши и правило объединения предоставлены.
Не называй пример Binance proof, не делай вывод о резервах/обязательствах/solvency.
Если не хватает порядка хеширования или данных snapshot, укажи это.
Лист, sibling hashes, правило и заявленный root: [учебные значения]
Финальный вывод формулируй точно: «мой leaf включён в указанный снимок» — только если криптографическая проверка прошла по правилам оператора. Не превращай это в «биржа доказала отсутствие долга» или «средства гарантированно доступны». Общие риски централизованных площадок описаны в руководстве по криптобиржам, а безопасность аккаунта и ключей — в чеклисте защиты.