He estado mirando a través de EthereumJ, tratando de entender cómo funciona el hash y la firma de transacciones.
Por lo que puedo decir del código, la firma se crea firmando el hash de la transacción codificada RLP. Sin embargo, la razón por la que estoy confundido es porque el hash se genera a partir de los valores r y s de la firma junto con el resto. Teniendo en cuenta que esos valores de r y s aún no existen, ¿cómo se incluirían?
Un poco más de investigación en el código parece que se generan dos hashes diferentes. Un hash "en bruto", en el que los valores de r y s son simplemente matrices de bytes vacías, que es el hash que se firma, y luego un hash real, que incluye los valores de r y s generados.
¿Es correcto este entendimiento? ¿Por qué molestarse en incluir la firma en el proceso de firma? Como en, ¿por qué la firma no firma simplemente el hash de los elementos de la transacción que no son de firma? ¿Por qué el hash "en bruto" incluye los valores vr y s (aunque la r y la s están vacías)?
La transacción codificada con RLP con matrices de bytes vacías para r, s era la preimagen hash original. Para EIP155, se agregó un valor en el campo v para proteger las firmas contra ataques de reproducción, lo que significa que las firmas en la cadena de bloques Ethereum Classic no serían válidas para la misma transacción en la cadena de bloques Ethereum. Por lo tanto, el campo v tiene un doble propósito: proteger contra ataques de reproducción y permitir la recuperación de la clave pública de la firma, como se explica aquí .
Para EIP155, la imagen previa del hash se cambió para incluir el ID de la cadena (evita ataques de repetición en otras bifurcaciones/redes de prueba de Ethereum) y también valores cero (codificados como 80 en RLP), como valores temporales de r, s. Una vez que se calcula la firma, los valores r, s de la firma, junto con el bit de recuperación, se insertan en el hexadecimal de transacción final, creando así la transacción firmada.
Es difícil para mí responder por qué EIP155 cambia la preimagen hash de campos sin r,s a campos r,s vacíos. La especificación no explica por qué se realizó este cambio.
Antes de EIP155, la firma era:
ECDSA_secp256k1(private_key, Keccak256(RLP(nonce, gasPrice, gasLimit, To, Value, Data)))
Con EIP155, la firma es:
ECDSA_secp256k1(private_key, Keccak256(RLP(nonce, gasPrice, gasLimit, To, Value, Data, v, r, s))),
donde r, s es la codificación RLP de la lista [0x00]. Esto está codificado como 0x80.
La red acepta ambos tipos de firma.
El ID de transacción (TXID) se calcula a partir de la transacción firmada. Entonces, si en el código ve que se calcula un valor hash a partir de algo que contiene la firma, este es el TXID.