Firmas vinculadas a la cadena
Una firma de ZooBC solo es válida en una cadena. Antes de firmar una transacción, una billetera calcula un resumen que incluye el hash del génesis de la cadena, así que un pago firmado en testnet no se verifica en mainnet ni en devnet, aunque la misma clave dé la misma dirección en todas las cadenas. La misma vinculación protege las conexiones entre nodos y los mensajes firmados fuera de la cadena.
El resumen
El firmante nunca firma los bytes en bruto de la transacción. Firma este resumen:
digest = SHA3-256("ZBC-TX" ‖ genesis hash ‖ unsigned transaction bytes)
transaction hash = SHA3-256(unsigned transaction bytes ‖ signature)
transaction id = the first 8 bytes of the transaction hash, little-endianLa etiqueta «ZBC-TX» marca el resumen como el de una transacción; otras acciones firmadas usan otras etiquetas (véase más abajo). El hash del génesis ata la firma a una sola cadena. Solo se acepta este resumen vinculado a la cadena: una firma sobre los bytes desnudos, sin ninguna cadena incluida, se rechaza en todas las cadenas. Véase firmar una transacción para el procedimiento de firma completo.
El hash del génesis es la identidad de la cadena
El hash del génesis es el hash del primer bloque de una cadena. Se deriva de la configuración del génesis de la cadena, así que cambiar cualquier valor comprometido de esa configuración da un hash nuevo, es decir, una cadena distinta (véase bloque génesis). En ZooBC no hay ningún byte de id de red aparte: el hash del génesis es la única identidad de la cadena. Devnet, testnet y mainnet tienen cada una el suyo (véase devnet, testnet y mainnet), y una red de pruebas relanzada recibe uno nuevo.
Un nodo indica el genesis_hash de su cadena y su signing_version en su ruta de información, /api/v1/node/info (véase API del nodo), de modo que una billetera o una herramienta puede saber para qué cadena está firmando.
La repetición entre cadenas
Supongamos que se firma un pago en testnet y alguien lo copia a mainnet. El nodo de mainnet calcula el resumen con el hash del génesis de mainnet, obtiene un valor distinto y la firma no se verifica: la transacción se rechaza por «no estar firmada para esta cadena». El importe no influye, y la billetera no tiene que añadir nada.
La misma clave da la misma dirección en todas las cadenas ZooBC, y una dirección con fondos en una cadena simplemente muestra un saldo de cero en otra. Precisamente por eso importa la vinculación: sin ella, un pago hecho en una cadena podría copiarse en otra y mover monedas allí.
Todos los tipos de cuenta, todos los firmantes
Las cuentas de ZooBC pueden controlarlas muchos tipos de claves: las propias claves Ed25519 de ZooBC, claves de Bitcoin y de Ethereum, y otras (véase claves y tipos de cuenta). Todos los tipos de cuenta firman el mismo resumen vinculado a la cadena; algunos le vuelven a aplicar antes un hash, como exige el esquema de firma de su cadena de origen (las claves al estilo de Ethereum firman su hash Keccak-256, por ejemplo). Los participantes de una cuenta multifirma firman el resumen vinculado a la cadena de la transacción interna.
Otras acciones firmadas usan resúmenes propios, también vinculados a la cadena: los consentimientos que vinculan o controlan grupos de cuentas («ZBC-GROUP-LINK», «ZBC-GROUP-CONTROL»), la cofirma de un escrow entre varias partes y la petición que cancela una transacción pendiente en el conjunto de espera de un nodo («ZBC-CANCEL»).
Nodos y mensajes
La vinculación a la cadena no se limita a las transacciones:
- El saludo entre pares. Cuando dos nodos se conectan, el saludo inicial lo firma la clave de nodo y lleva el hash del génesis. Un par de otra cadena se rechaza con «Genesis hash mismatch», así que un nodo de una cadena nunca se conecta como par con un nodo de otra.
- Los mensajes firmados. Los mensajes firmados fuera de la cadena con las herramientas usan el resumen SHA3-256("ZBC-MSG-v2" ‖ hash del génesis ‖ mensaje), así que un mensaje firmado en devnet nunca se verifica en testnet ni en mainnet (véase mensajes firmados y cifrados).
Los recibos son la excepción dentro del protocolo: un recibo no nombra ninguna cadena, así que no lleva ninguna vinculación propia a la cadena. Sí nombra un bloque de referencia por su altura y su hash, que los validadores comprueban.