Glossaire / Référence pour développeurs
Ordre des octets RPC
- Qu'est-ce que l'ordre des octets RPC ?
- L'ordre des octets RPC est la manière inversée dont les logiciels bitcoin affichent les hachages de 32 octets, et c'est la forme de chaque identifiant de transaction que vous copiez depuis un portefeuille ou un explorateur de blocs.
La chaîne de 64 caractères que votre portefeuille appelle identifiant de transaction n'est pas l'ordre que ces octets prennent partout ailleurs. Bitcoin Core conserve un hachage dans un type qui l'affiche en commençant par l'octet le plus significatif, tous les explorateurs ont repris cette habitude, et la convention est désormais définitive. Elle est sans conséquence quand vous collez un identifiant dans un champ de recherche et coûteuse quand vous le collez dans du code.
Comment cela fonctionne
L'ordre des octets RPC est une transformation d'affichage appliquée à la sortie d'un nœud, pas un hachage différent.
Un condensat quitte SHA-256 sous la forme de 32 octets sans direction inhérente. Bitcoin Core le conserve dans un conteneur qui modélise ces octets comme un seul très grand nombre, et l'affichage d'un nombre place la partie la plus significative à gauche, ce qui inverse le tableau. Chaque champ JSON nommant un bloc ou une transaction sort ainsi : le hachage de getblockhash, le txid de getrawtransaction, le merkleroot de getblock, le previousblockhash qui relie un bloc à son parent.
Une conséquence se voit sur la page d'accueil de chaque explorateur. La preuve de travail produit des condensats qui commencent, dans ce sens d'affichage, par une longue série de zéros. Ces zéros se trouvent à l'extrémité des octets bruts. Les cibles de minage sont plus faciles à interpréter sous la forme affichée, ce qui explique en partie pourquoi la convention s'est imposée plutôt que d'être corrigée.
L'inversion ne s'applique qu'aux hachages. Les clés publiques, les signatures, les scripts et les éléments de témoin sont tous affichés dans leur ordre réel, si bien qu'un script issu de decodescript peut être comparé directement à la transaction brute, alors qu'un txid ne le peut pas. C'est en mélangeant ces deux règles que le code fonctionnel se trompe le plus souvent.
Une même réponse peut même contenir les deux conventions à la fois. Demandez une transaction avec une sortie détaillée et le champ txid est inversé, tandis que le champ hex à côté est la sérialisation intacte contenant le même hachage dans l'autre sens.
Où cela se voit
L'ordre des octets RPC est la seule forme d'un hachage que la plupart des gens manipulent.
C'est ce qu'une plateforme d'échange met dans un courriel de confirmation de retrait, ce qu'un explorateur de blocs attend dans une URL, ce qu'un agent de support vous demande d'envoyer, et ce qu'affiche bitcoin-cli. Demander à un nœud le tout premier bloc avec getblockhash 0 renvoie 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, et coller cette chaîne dans n'importe quel explorateur renvoie le bloc miné le 3 janvier 2009.
Le mode de défaillance est étroit et constant. Quelqu'un calcule lui-même un identifiant de transaction, en hachant deux fois la sérialisation avec SHA-256, compare le résultat à un explorateur et ne trouve aucune ressemblance. Les deux chaînes sont les mêmes 32 octets et l'une d'elles doit être inversée. Le même correctif s'applique quand un script extrait un txid d'une entrée brute et le cherche dans une table d'identifiants collectés depuis une API.
Il y a une habitude de deux secondes qui vaut la peine d'être adoptée. Si un hachage que quelqu'un vous a envoyé ne renvoie nulle part, essayez-le à l'envers avant de conclure que la transaction n'existe pas. Les fils de support sont pleins de hachages copiés depuis des données brutes plutôt que depuis un portefeuille, et ils semblent parfaitement valides jusqu'à ce que vous les inversiez.