Signature de transaction et hachage

Lev Knoblock

Signature de transaction et hachage


J’ai parcouru EthereumJ, essayant de comprendre comment fonctionne le hachage et la signature des transactions.

D’après ce que je peux dire du code, la signature est créée en signant le hachage de la transaction encodée RLP. La raison pour laquelle je suis confus, cependant, est que le hachage est généré à partir des valeurs r et s de la signature avec le reste. Étant donné que ces valeurs r et s n’existent pas encore, comment seraient-elles incluses?

Un peu plus de fouille dans le code ressemble à deux hachages différents sont générés. Un hachage « brut », dans lequel les valeurs r et s sont simplement des tableaux d’octets vides, qui est le hachage qui est signé, puis un hachage réel, qui inclut les valeurs r et s générées.

Cette compréhension est-elle correcte? Pourquoi s’embêter à inclure la signature dans le processus de signature? Comme dans, pourquoi la signature ne signe-t-elle pas simplement le hachage des éléments non-signature de la transaction? Pourquoi le hachage « brut » inclut-il les valeurs vr et s (même si les r et s sont vides)?

Réponses


 Thorkil Værge

La transaction encodée RLP avec des tableaux d’octets vides pour r, s était la pré-image de hachage d’origine. Par EIP155, une valeur dans le champ v a été ajoutée pour protéger les signatures contre les attaques par relecture, ce qui signifie que les signatures sur la blockchain Ethereum Classic ne seraient pas également valides pour la même transaction sur la blockchain Ethereum. Le champ v sert donc un double objectif: protéger contre les attaques par rejeu et activer la récupération de clé publique à partir de la signature, comme expliqué ici .

Par EIP155, la pré-image de hachage a été modifiée pour inclure l’ID de chaîne (empêche les attaques de relecture sur d’autres fourches Ethereum / testnet) et également des valeurs nulles (encodées en 80 dans RLP), en tant que valeurs r, s temporaires. Une fois la signature calculée, les valeurs r, s de la signature, ainsi que le bit de récupération, sont insérés dans l’hex de transaction finale, créant ainsi la transaction signée.

Il est difficile pour moi de répondre à la raison pour laquelle EIP155 change la pré-image de hachage des champs no r, s en champs r, s vides. La spécification n’explique pas pourquoi cette modification a été apportée.

Avant EIP155, la signature était:

 ECDSA_secp256k1(private_key, Keccak256(RLP(nonce, gasPrice, gasLimit, To, Value, Data))) 

Avec EIP155, la signature est:

ECDSA_secp256k1(private_key, Keccak256(RLP(nonce, gasPrice, gasLimit, To, Value, Data, v, r, s))) ,

où r, s est le codage RLP de la liste [0x00]. Ceci est codé en 0x80.

Le réseau accepte les deux types de signature.

L’ID de transaction (TXID) est calculé à partir de la transaction signée. Donc, si vous dans le code voyez une valeur de hachage calculée à partir de quelque chose contenant la signature, c’est le TXID.

 

#de, #et, hachage, signature, transaction

 

yahoo

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *