Во-первых, четко сформулируйте проблему, которую необходимо доказать.
При изучении блока часто возникают вопросы о том, включена ли транзакция, каков результат ее выполнения и каков статус учетной записи в конкретном блоке. Это разные вопросы, требующие разных данных и доказательств. Хэш корневого элемента в заголовке блока предоставляет подтверждение соответствующей структуры данных, но сам хэш корневого элемента не является непосредственно читаемым списком учетных записей и не объясняет, почему транзакция приводит к определенному бизнес-результату.
Корни транзакций соответствуют набору транзакций.
Корни транзакций связаны с транзакциями, организованными последовательно внутри блока. При проверке связи включения транзакции необходимо одновременно знать сеть, заголовок блока и соответствующую структуру подтверждения. Включение транзакции не гарантирует успешного выполнения и не означает, что принимающая платформа зачислила транзакцию на счет клиента. Ссылка в браузере предоставляет только точку входа для запроса; для формальной проверки крайне важно уточнить, кому вы доверяете: узлу, браузеру или проверенному заголовку блока.
Корень квитанции соответствует результатам выполнения
Квитанции обычно содержат такую информацию, как статус выполнения, суммарное использование газа и журналы. Корень квитанции гарантирует эти результаты выполнения, а не баланс клиента платформы. Приложения могут идентифицировать активность по логам, но контракт эмиссии, декодирование параметров и статус транзакции в логах должны рассматриваться совместно. Наличие события с именем «Transfer» не обходит проверки подлинности контракта токена и результата его исполнения.
Корневые состояния описывают состояние конкретного блока
Корневое состояние соответствует снимку состояния и может включать в себя связанную структуру балансов счетов, nonce, кода и хранилища. Доказательства требуют фиксированного блока; вчерашнее доказательство не может быть применено к сегодняшнему. Действительное доказательство для конкретного слота хранения не гарантирует отсутствия риска для токен-экономики, административного органа или внешних оракулов. Объем технических обязательств должен быть более точным, чем заявления о «полностью проверяемом в блокчейне» в маркетинговых материалах.
Пример межполевой проверки
Предположим, пользователь хочет подтвердить вызов контракта. Сначала определите, в какой блок вошла транзакция, затем проверьте, было ли получение успешным, и параметры события, и, наконец, запросите соответствующий статус учетной записи или контракта в зависимости от вопроса. Если браузер и приложение отображают разную информацию, проверьте, используются ли разные высоты блоков или разные сети, вместо того, чтобы сразу предполагать, что одна из сторон совершает мошенничество. Этот пример иллюстрирует уровни доказательств и не является аудиторским заключением по какому-либо контракту.
Сохранение контекста доказательства
Сохраните идентификатор цепочки, высоту блока и хеш, тип корневого хеша, метод запроса, данные доказательства и версию инструмента. Если используется сторонний сервис декодирования, укажите его роль и потенциальную задержку кэширования. Окончательность и реорганизация цепочки по-прежнему влияют на статус выбранного блока; Проверьте подтверждение данных, ответив только на конкретные технические вопросы, и не подтверждайте субъект обслуживания, резервы активов или возможность выкупа в будущем.