Глоссарий / Справочник разработчика
Порядок байтов RPC
- Что такое порядок байтов RPC?
- Порядок байтов RPC означает обратный порядок, в котором программное обеспечение биткоина отображает хеши из 32 байт, и именно в такой форме представлен каждый ID транзакции, который вы копируете из кошелька или обозревателя блоков.
Строка из 64 символов, которую ваш кошелек называет ID транзакции, представлена не в том порядке, в каком эти байты хранятся где-либо еще. Bitcoin Core хранит хеш в типе, который печатает его начиная с самого старшего байта, все обозреватели блоков переняли эту привычку, и теперь это соглашение постоянно. Оно безвредно, когда вы вставляете идентификатор в поле поиска, и дорого обходится, когда вы вставляете его в код.
Как это работает
Порядок байтов RPC представляет собой преобразование при отображении, которое выполняется на выходе из узла, а не другой хеш.
Дайджест выходит из SHA-256 в виде 32 байт без какого-либо внутренне присущего направления. Bitcoin Core хранит его в контейнере, который представляет эти байты как одно очень большое число, а при печати числа самая старшая часть оказывается слева, что переворачивает массив. Каждое поле JSON, называющее блок или транзакцию, выводится именно так: хеш из getblockhash, txid из getrawtransaction, merkleroot из getblock, previousblockhash, который связывает блок с его родителем.
Одно следствие видно на главной странице любого обозревателя блоков. Доказательство работы дает дайджесты, которые в этом направлении печати начинаются с длинной череды нулей. Эти нули находятся на дальнем конце необработанных байт. О целях майнинга проще рассуждать в печатной форме, и отчасти поэтому соглашение прижилось, а не было исправлено.
Переворот касается только хешей. Публичные ключи, подписи, скрипты и элементы свидетеля печатаются в их истинном порядке, поэтому скрипт из decodescript можно напрямую сравнить с необработанной транзакцией, а txid нельзя. Смешение этих двух правил обычно и становится причиной ошибок в рабочем коде.
Один ответ может даже содержать оба соглашения одновременно. Запросите транзакцию с подробным выводом: поле txid будет перевернуто, а поле hex рядом с ним представляет собой нетронутую сериализацию, содержащую тот же хеш в обратном порядке.
Где это видно
Порядок байтов RPC является единственной формой хеша, с которой большинство людей когда-либо имеет дело.
Именно в нем биржа указывает хеш в письме с подтверждением вывода средств, его обозреватель блоков ожидает в URL, его просит прислать агент поддержки, и его печатает bitcoin-cli. Если запросить у узла самый первый блок с помощью getblockhash 0, будет возвращено 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, и если вставить эту строку в любой обозреватель блоков, она приведет к блоку, добытому 3 января 2009 года.
Сценарий сбоя узок и единообразен. Кто-то сам вычисляет идентификатор транзакции, дважды хешируя сериализацию с помощью SHA-256, сравнивает результат с обозревателем блоков и не находит никакого сходства. Обе строки представляют собой одни и те же 32 байта, и одну из них нужно перевернуть. Та же самая поправка применяется, когда скрипт извлекает txid из необработанных входных данных и ищет его в таблице идентификаторов, собранных из API.
Есть привычка на две секунды, которую стоит завести. Если хеш, который вам прислали, никуда не ведет, попробуйте его в обратном порядке, прежде чем делать вывод, что транзакции не существует. Ветки поддержки полны хешей, скопированных из необработанных данных, а не из кошелька, и они выглядят совершенно действительными, пока их не перевернуть.