Formato de comandos

Toda operación de zNS es una transacción blindada de ZCash dirigida a la dirección de protocolo del registrador, donde el importe es el pago y el memo es el comando firmado. Ambos viajan en la misma nota, de modo que intención y pago quedan atados de forma atómica: no hay una referencia o factura aparte que haya que correlacionar.

Esta página describe el formato de transmisión exacto. Un comando construido conforme a él será aceptado tanto por el registrador como por el circuito de conocimiento cero.

Anatomía

Todos los comandos son ASCII separado por dos puntos y empiezan por el marcador de protocolo y la versión:

zNS:1:{OP}:{name}:…:{ed25519_pubkey_hex}:…:{nonce}:{signature_hex}

Los campos intermedios dependen de la operación:

Operación	Estructura del memo	Importe pagado
REG registrar	zNS:1:REG:{name}:{address}:{pubkey}:{nonce}:{sig}	tarifa de registro según la longitud del nombre
UPD cambiar dirección	zNS:1:UPD:{name}:{address}:{pubkey}:{nonce}:{sig}	tarifa de modificación
CHG transferir titular	zNS:1:CHG:{name}:{new_pubkey}:{nonce}:{sig}	tarifa de modificación
LST poner a la venta	zNS:1:LST:{name}:{pubkey}:{price}:{nonce}:{sig}	tarifa de modificación
ULT retirar de la venta	zNS:1:ULT:{name}:{pubkey}:{nonce}:{sig}	tarifa de modificación
BUY comprar	zNS:1:BUY:{name}:{address}:{pubkey}:{nonce}:{sig}	exactamente el precio publicado

En CHG, {new_pubkey} es la clave del titular entrante, y la firma la hace el titular saliente: es el titular actual quien autoriza una transferencia.

El mensaje firmado

La firma cubre el comando sin el :{signature} final, es decir, todo desde el marcador hasta el nonce incluido:

zNS:1:REG:richard.zcash:u1…:0101…0101:1780000001

Las reglas son exactas, y un cliente que incumpla cualquiera de ellas produce una firma que el circuito rechaza:

• pubkey es hex en minúsculas, 64 caracteres.
• price aparece solo en LST.
• address aparece solo en REG, UPD y BUY.
• price y nonce son decimales, sin ceros a la izquierda, sin signo y sin relleno.
• La firma es Ed25519 sobre esos bytes exactos, codificada en hex, 128 caracteres.

La verificación es estricta: se rechazan las firmas no canónicas y las claves de orden pequeño.

Reglas de los campos

Nombre

Regla	Valor
Caracteres	a-z, 0-9, guion
Longitud	1–64 caracteres incluida la zona
Mayúsculas	solo minúsculas: un nombre se almacena y se hashea en minúsculas
Guiones	ni al principio, ni al final, nunca dobles
Zonas	.zcash, .zec, .private, .secure, .safe

Se permite exactamente un punto, que separa la etiqueta de la zona.

Dirección de destino

La dirección a la que resuelve un nombre debe ser una Unified Address en mainnet con un receptor Orchard. Las direcciones que no lo tengan se rechazan.

El motivo es práctico y no arbitrario: el registrador cobra y paga a través de material de claves Orchard, que según ZIP 229 cubre también el pool Ironwood. A una dirección sin receptor Orchard no se le puede pagar, así que no sirve ni para reembolsos ni para ingresos de ventas.

tip

Ironwood no añade un receptor

Ironwood es un nuevo pool de valor, no un nuevo formato de dirección. Los monederos migran notas a él mientras la dirección de recepción sigue siendo una dirección Orchard. La Unified Address de un monedero actual funciona sin cambios.

Nonce

El nonce es una marca de tiempo Unix en segundos en el momento de firmar.

• Debe ser estrictamente mayor que el nonce registrado en ese momento para ese nombre. Eso es lo que impide repetir un comando firmado antiguo.
• No puede adelantarse más de 300 segundos al bloque que lo transporta, margen que absorbe el desfase habitual de reloj sin permitir dejar un nonce muy en el futuro.

Para un primer registro sirve cualquier marca de tiempo actual.

Precio

Solo LST lleva precio. Es un número entero de zatoshis (1 ZEC = 100 000 000 zatoshis) y debe ser mayor que cero.

Volver a publicar un nombre ya publicado a otro precio está permitido: envíe otro LST. Gana el más reciente.

Límite de tamaño

Un memo de ZCash ocupa exactamente 512 bytes, y el comando entero debe caber. Las partes fijas consumen una cantidad previsible:

zNS:1:{OP}: …  marker, version, operation      11 bytes
{pubkey}       64 hex characters               65 bytes with separator
{nonce}        10 digits today                 11 bytes with separator
{signature}    128 hex characters             128 bytes

Quedan unos 295 bytes que deben repartirse entre el nombre y la dirección de destino. Una Unified Address con varios receptores puede ser larga, así que con un nombre muy largo puede que una dirección muy larga no quepa. Los clientes deberían calcular ese presupuesto y avisar antes de que el usuario pague, en vez de dejar que la transacción falle a posteriori.

Pago

El importe determina la validez tanto como el memo:

• REG debe pagar exactamente la tarifa de registro correspondiente a la longitud del nombre.
• UPD, CHG, LST, ULT deben pagar exactamente la tarifa de modificación.
• BUY debe pagar exactamente el precio publicado.

La longitud se mide sobre la etiqueta, sin la zona: ab.zcash es un nombre de 2 caracteres.

Un comando pagado de menos o de más no se procesa. Si la operación y la clave pública son legibles, el importe se abona en su saldo interno y puede retirarse — consulte Preguntas y respuestas.

Orden

Los comandos se procesan en el orden en que ZCash los produjo: altura de bloque, después índice de transacción dentro del bloque y después índice de entrada. El registrador no elige el orden y no puede reordenar sin que todos los indexadores independientes calculen una raíz distinta.

En las operaciones en disputa —dos REG para el mismo nombre, o dos BUY sobre la misma publicación— gana la primera según ese orden y a las demás se les reembolsa en el saldo interno.

Ejemplo resuelto

Registro de richard.zcash:

1. Generate an Ed25519 keypair. The public key is your identity across all your names.

2. Build the message to sign (note: no trailing signature field):

   zNS:1:REG:richard.zcash:u1mvnsq85wane…:3757ee1a…a53:1780000001

3. Sign it with the private key; hex-encode the 64-byte signature.

4. Append it to form the memo:

   zNS:1:REG:richard.zcash:u1mvnsq85wane…:3757ee1a…a53:1780000001:cfec7a58…04

5. Send a shielded transaction to the registrar address, with that memo, paying the
   registration fee for a 7-character name.

En unos minutos el comando se agrupa en un lote, se demuestra y se ancla. A partir de ahí, richard.zcash resuelve a través de cualquier indexador, con una prueba de Merkle que usted mismo puede comprobar.