Mueve valor. Mueve datos. Con tus reglas.
Una transacción de ZooBC es un sobre firmado que envuelve un pequeño cuerpo tipado. El sobre es idéntico para todos los tipos; el cuerpo y unos pocos modificadores opcionales deciden lo que ocurre realmente: un envío simple, una transferencia de tokens, un salario con liberación gradual, un acuerdo con depósito en garantía, una jugada en una aplicación, un disparador programado. Este es el mapa completo.
01Anatomía de una transacción
Todo se serializa en little-endian en un único búfer de bytes y luego se firma. Los campos azules son el sobre (igual para todos los tipos); el cuerpo morado es lo que cambia según el tipo.
Una dirección de cuenta es tipo de 4 bytes (LE) + clave pública: 00000000+32B ed25519 para ZBC, 04000000+ETH, 05000000+BTC, etc. Un destinatario ausente se escribe como el tipo vacío 02000000. La cola del mensaje es donde un envío simple lleva su nota; el cuerpo de un SendZBC es solo el importe, y el destinatario y la nota van en el sobre.
02Firma
El tipo de cuenta determina tanto el prefijo de la dirección como el esquema de firma. Se firma sobre todo el sobre (sin el campo de firma), precedido por la etiqueta de firma y el hash de génesis. Los tres son deterministas, así que una billetera de navegador y el nodo coinciden byte a byte.
ZooBC (ed25519) · tipo 00000000
// digest, then sign digest = SHA3_256("ZBC-TX" ‖ genesis_hash ‖ txBytes) sig = ed25519(digest, privkey) // 64 bytes
Es también el esquema de Solana, Cardano, Tezos y Polkadot: la misma clave ed25519, con distinto prefijo de dirección + codificación de visualización.
Ethereum (secp256k1) · tipo 04000000
// recoverable ECDSA, low-s digest = keccak256(SHA3_256("ZBC-TX" ‖ genesis_hash ‖ txBytes)) r,s,v = secp256k1.sign(digest) sig = r ‖ s ‖ (v+27) // 65 bytes
MetaMask también puede enviar su propio RLP firmado; el nodo recupera el remitente y lo convierte en una transferencia de ZBC.
Bitcoin (secp256k1) · tipo 05000000
// double-sha over the SHA3 payload digest = SHA256d(SHA3_256("ZBC-TX" ‖ genesis_hash ‖ txBytes)) sig = secp256k1.sign(digest) field = [len(2)] ‖ compressedPub(33) ‖ sig
La comisión, en resumen
La comisión mínima depende del tamaño: una tarifa base × la escala de comisiones de la red, más un componente por byte de almacenamiento/duración. Consúltala en vivo en https://zoobc.network/api/v1/blockchain/fee-params o calcula el precio exacto de una tx con /estimate-fee para que la billetera nunca discrepe del nodo ni en una unidad atómica. Lo pagado de más en un envío con comisión exacta se reembolsa.
El digest vinculado a la cadena (versión de firma 2)
Desde el nodo v0.4.0, el término más interno es el mismo en los tres esquemas, porque el nodo calcula ese digest una sola vez y lo entrega al esquema de firma que seleccione el tipo de cuenta.
- "ZBC-TX" son seis bytes ASCII sin terminador: 5a 42 43 2d 54 58.
- genesis_hash son los 32 bytes en bruto del bloque 0 de la cadena para la que se firma.
Lee genesis_hash de GET /api/v1/node/info; la misma respuesta incluye signing_version: 2 y signing_tag: "ZBC-TX". Nunca lo escribas fijo en el código: cambia cada vez que se relanza una red de pruebas.
Vincular el hash de génesis al digest es lo que hace que una firma sea válida en una sola red, de modo que una transacción firmada para una cadena de pruebas no se puede reutilizar en otra. Firmar el SHA3_256(txBytes) sin más es la versión de firma 1, y el nodo la rechaza con:
Invalid transaction signature: legacy unbound digest (signing v1); this chain requires signing v2
03Los tres tipos de moneda
Los importes son siempre atómicos (1 ZBC = 100,000,000). Lo único que cambia entre monedas es el campo token_id; la mecánica del movimiento es idéntica.
① ZBC nativo
token_id = 0 en todas partes. La moneda del gas y las comisiones, las recompensas de bloque, el staking. Un SendZBC (tipo 1) es la vía simple.
② Tokens de génesis / de puente
Activos externos envueltos y acuñados en la génesis (ZBTC, ZETH, ZSOL…). Son tokens coloreados corrientes con un token_id fijo asignado en la configuración de génesis; no tienen nada especial a nivel de protocolo.
③ Tokens emitidos por usuarios
Cualquiera puede acuñar uno con IssueToken (tipo 10): símbolo, suministro, decimales y respaldo opcional en ZBC. Su token_id deriva de la tx de emisión. Se aplican los mismos TransferToken / MintToken / BurnToken.
Siempre que un cuerpo tenga un token_id (transferencia, intercambio, stake de aplicación, líquido, liberación gradual…), pasa 0 para ZBC o el id del token para una moneda coloreada. Los tokens respaldados pueden incluso pagar su propia comisión (con la opción fee_in_token), con un precio calculado sobre su respaldo en ZBC.
04Modificadores: un pago, muchas formas
Más allá de los tipos base, cuatro envoltorios de tiempo y confianza cambian cuándo y si los fondos llegan realmente. Son los que hacen que la superficie parezca tan amplia.
Depósito en garantía
Añade una sección de depósito en garantía al sobre de cualquier tx de valor (aprobador · comisión · plazo · instrucción). Los fondos quedan retenidos hasta que el aprobador designado firma ApprovalEscrow (tipo 4) para liberarlos o rechazarlos, o hasta que vence el plazo. Un acuerdo condicional sobre cualquier transferencia.
Líquido
LiquidPayment (tipo 6): un único pago diferido a lo largo de un intervalo. El destinatario recibe el importe completo cuando termina el intervalo, o una parte proporcional si el remitente lo detiene antes con LiquidPaymentStop (tipo 262). A corto plazo (horas), en ZBC o en token.
Programado / con liberación gradual
ScheduledTransfer (tipo 29): liberación en tramos según un temporizador, ya sea liberación gradual (fondos bloqueados de antemano) o salario recurrente (cobrado en cada periodo). Cliff, revocación, rechazo del destinatario, reasignación. A largo plazo (de semanas a años). Las liberaciones aparecen como movimientos del libro mayor, no como tx nuevas.
Disparador / Detención
El temporizador ligero: CreateTrigger (15) bloquea un importe para ejecutarlo a una altura futura; CancelTrigger (16) lo reembolsa. Para detener los de larga duración: CancelSchedule (30) para revocar/rechazar, LiquidPaymentStop (262).
Se combinan. Un salario mensual que además tiene depósito en garantía, una asignación con liberación gradual en un token coloreado: las primitivas se componen. (La composición completa de pagos recurrentes con depósito en garantía está en la hoja de ruta; todas las piezas ya existen hoy.)
05Mantener vivos los objetos de datos
Los objetos en la cadena que contienen datos, los conjuntos de datos (perfiles clave/valor, chat, formularios de negocio) y los tokens, pagan alquiler para persistir. "Añadir fondos a un objeto" significa recargar su financiación de supervivencia.
Conjuntos de datos y archivos → almacenamiento prepagado
Escribes datos con SetupAccountDataset (tipo 3, un par propiedad → valor) o almacenas un archivo con DFSCreateFile (8). Cada bloque cobra alquiler de almacenamiento contra el almacenamiento prepagado de tu cuenta; cuando se agota, el objeto se elimina. Recárgalo con AddPrepaidStorage (tipo 9): el cuerpo es solo un importe, que se acredita directamente a tu saldo de almacenamiento prepagado. Más prepago = vida más larga.
Tokens → financiación de la persistencia
Un token coloreado también paga para sobrevivir. FinanceToken (tipo 14) amplía el horizonte de persistencia de un token a partir de la comisión, alargando el tiempo que permanece activo antes de que su respaldo sin usar se devuelva al creador. La misma idea, por token.
06Catálogo completo de transacciones
Los 50 tipos de transacción, con la estructura exacta de su cuerpo en little-endian. moneda = admite token_id · modificable = acepta una sección de depósito en garantía · nueva cadena = a nivel de consenso (llega con el lanzamiento de una cadena).