Técnico › Red

Estructura de una transacción

Qué hay en los bytes de una transacción de Monero: prefijo, firma RingCT y la parte podable

En resumen

Una transacción = un prefijo (versión, entradas, salidas, extra) + la base RingCT (tipo, comisión, importes cifrados, compromisos de las salidas) + la parte podable (Bulletproofs+, CLSAG, pseudo-salidas). El hash de la transacción se construye a partir de los hashes de las tres partes, así que los nodos pueden descartar la parte podable de las transacciones antiguas (pruning) sin que deje de ser verificable.

Prefijo

version        = 2
unlock_time    = 0                       // campo heredado, ahora siempre 0
vin[]:                                   // entradas
  txin_to_key:
    amount       = 0                     // los importes están ocultos en RingCT
    key_offsets  = [g₀, Δ₁, …, Δ₁₅]      // 16 índices globales, como desplazamientos relativos
    k_image      = I                     // key image, 32 bytes
vout[]:                                  // salidas
  amount = 0
  target: txout_to_tagged_key
    key      = P                         // clave de un solo uso, 32 bytes
    view_tag = 1 byte
extra          = [0x01 ‖ R, …]           // clave de transacción y más

Los key_offsets se guardan como diferencias: el primero es el índice absoluto de la salida y los demás son distancias respecto a la anterior. Los números pequeños ocupan menos bytes como varints.

Base RingCT

type       = 6                           // RCTTypeBulletproofPlus
txnFee     = fee in atomic units (varint)
ecdhInfo[] = encrypted amount, 8 bytes per output
outPk[]    = commitment C, 32 bytes per output

Parte podable

bulletproofs_plus[] = one aggregated proof
CLSAGs[]            = { s[16], c1, D } per input
pseudoOuts[]        = C̃, 32 bytes per input

Hash de la transacción

txid = Keccak( H(prefix) ‖ H(RingCT base) ‖ H(prunable) )

Este «árbol de tres hashes» permite que un nodo con pruning descarte las pruebas pesadas de transacciones antiguas (conservando su hash) y que el txid se pueda seguir calculando.

Comisiones

La comisión depende del peso de la transacción (≈ tamaño en bytes, ajustado para Bulletproofs+ de modo que las transacciones con muchas salidas no salgan desproporcionadamente baratas) y de un nivel de prioridad. La tarifa base por byte se adapta a la mediana del tamaño de bloque: ver tamaño de bloque dinámico.

Qué cambia con FCMP++

  • En lugar de key_offsets, una referencia al bloque cuyo estado del árbol se usa para construir la prueba.
  • En lugar de CLSAG, una prueba de pertenencia y SA+L; la key image se mantiene.
  • Formato de salidas: Carrot (view tags de 3 bytes, ancla Janus).