Befehlsformat

Jede zNS-Operation ist eine abgeschirmte ZCash-Transaktion an die Protokolladresse der Registrierungsstelle, wobei der Betrag die Zahlung und das Memo der signierte Befehl ist. Beides reist in derselben Note, sodass Absicht und Zahlung untrennbar verbunden sind — es gibt keine separate Referenz oder Rechnung, die zugeordnet werden müsste.

Diese Seite beschreibt das exakte Wire-Format. Ein danach gebauter Befehl wird sowohl von der Registrierungsstelle als auch von der Zero-Knowledge-Schaltung akzeptiert.

Aufbau

Alle Befehle sind ASCII mit Doppelpunkten als Trennzeichen und beginnen mit Protokollmarker und Version:

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

Die Felder dazwischen hängen von der Operation ab:

Operation	Memo-Aufbau	Gezahlter Betrag
REG registrieren	zNS:1:REG:{name}:{address}:{pubkey}:{nonce}:{sig}	Registrierungsgebühr für die Namenslänge
UPD Adresse ändern	zNS:1:UPD:{name}:{address}:{pubkey}:{nonce}:{sig}	Änderungsgebühr
CHG Inhaber übertragen	zNS:1:CHG:{name}:{new_pubkey}:{nonce}:{sig}	Änderungsgebühr
LST zum Verkauf anbieten	zNS:1:LST:{name}:{pubkey}:{price}:{nonce}:{sig}	Änderungsgebühr
ULT vom Markt nehmen	zNS:1:ULT:{name}:{pubkey}:{nonce}:{sig}	Änderungsgebühr
BUY kaufen	zNS:1:BUY:{name}:{address}:{pubkey}:{nonce}:{sig}	exakt der Angebotspreis

Bei CHG ist {new_pubkey} der Schlüssel des übernehmenden Inhabers, und die Signatur stammt vom abgebenden Inhaber — die Übertragung autorisiert der aktuelle Inhaber.

Die signierte Nachricht

Die Signatur deckt den Befehl ohne das abschließende :{signature} ab — also alles vom Marker bis einschließlich der Nonce:

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

Die Regeln sind exakt; ein Client, der eine davon verletzt, erzeugt eine Signatur, die die Schaltung zurückweist:

• pubkey ist Kleinbuchstaben-Hex, 64 Zeichen.
• price erscheint nur bei LST.
• address erscheint nur bei REG, UPD und BUY.
• price und nonce sind dezimal, ohne führende Nullen, ohne Vorzeichen, ohne Auffüllen.
• Die Signatur ist Ed25519 über genau diese Bytes, hex-kodiert, 128 Zeichen.

Die Prüfung ist streng: nicht-kanonische Signaturen und Schlüssel kleiner Ordnung werden abgelehnt.

Feldregeln

Name

Regel	Wert
Zeichen	a-z, 0-9, Bindestrich
Länge	1–64 Zeichen einschließlich der Zone
Schreibweise	nur Kleinbuchstaben — ein Name wird kleingeschrieben gespeichert und gehasht
Bindestriche	nicht am Anfang, nicht am Ende, nie doppelt
Zonen	.zcash, .zec, .private, .secure, .safe

Genau ein Punkt ist erlaubt; er trennt das Label von der Zone.

Zieladresse

Die Adresse, auf die ein Name aufgelöst wird, muss eine Unified Address im Mainnet mit einem Orchard-Receiver sein. Adressen ohne einen solchen werden abgelehnt.

Der Grund ist praktisch und nicht willkürlich: Die Registrierungsstelle empfängt und zahlt über Orchard-Schlüsselmaterial, das laut ZIP 229 auch den Ironwood-Pool abdeckt. Eine Adresse ohne Orchard-Receiver kann nicht bezahlt werden und eignet sich daher weder für Rückerstattungen noch für Verkaufserlöse.

tipp

Ironwood fügt keinen Receiver hinzu

Ironwood ist ein neuer Wertpool, kein neues Adressformat. Wallets verschieben Notes dorthin, während die Empfangsadresse eine Orchard-Adresse bleibt. Die Unified Address einer aktuellen Wallet funktioniert unverändert.

Nonce

Die Nonce ist ein Unix-Zeitstempel in Sekunden zum Zeitpunkt der Signatur.

• Sie muss strikt größer sein als die aktuell für diesen Namen gespeicherte Nonce. Das verhindert das Wiedereinspielen eines alten signierten Befehls.
• Sie darf dem Block, der sie trägt, um höchstens 300 Sekunden vorauslaufen; das fängt übliche Uhrabweichungen ab, ohne dass eine Nonce weit in der Zukunft geparkt werden kann.

Für eine Erstregistrierung genügt ein beliebiger aktueller Zeitstempel.

Preis

Nur LST trägt einen Preis. Er ist eine ganze Zahl in Zatoshi (1 ZEC = 100.000.000 Zatoshi) und muss größer als null sein.

Einen bereits angebotenen Namen zu einem neuen Preis erneut anzubieten ist erlaubt — senden Sie ein weiteres LST. Das jüngste gewinnt.

Größenbeschränkung

Ein ZCash-Memo umfasst genau 512 Bytes, und der ganze Befehl muss hineinpassen. Die festen Teile verbrauchen einen vorhersehbaren Anteil:

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

Damit bleiben rund 295 Bytes, die sich Name und Zieladresse teilen. Eine Unified Address mit mehreren Receivern kann lang sein, sodass bei einem sehr langen Namen eine sehr lange Adresse möglicherweise nicht mehr passt. Clients sollten das Budget berechnen und warnen, bevor der Nutzer zahlt, statt die Transaktion im Nachhinein scheitern zu lassen.

Zahlung

Der Betrag entscheidet ebenso über die Gültigkeit wie das Memo:

• REG muss exakt die Registrierungsgebühr für die Namenslänge zahlen.
• UPD, CHG, LST, ULT müssen exakt die Änderungsgebühr zahlen.
• BUY muss exakt den Angebotspreis zahlen.

Die Länge wird am Label gemessen, ohne die Zone: ab.zcash ist ein Name mit 2 Zeichen.

Ein zu niedrig oder zu hoch bezahlter Befehl wird nicht verarbeitet. Sind Operation und öffentlicher Schlüssel lesbar, wird der Betrag Ihrem internen Guthaben gutgeschrieben und kann ausgezahlt werden — siehe Fragen & Antworten.

Reihenfolge

Befehle werden in der Reihenfolge verarbeitet, in der ZCash sie erzeugt hat: Blockhöhe, dann Transaktionsindex innerhalb des Blocks, dann Eingabeindex. Die Registrierungsstelle wählt die Reihenfolge nicht und kann sie nicht ändern, ohne dass jeder unabhängige Indexer einen anderen Root berechnet.

Bei konkurrierenden Operationen — zwei REG für denselben Namen oder zwei BUY für dasselbe Angebot — gewinnt die in dieser Reihenfolge erste, den übrigen wird der Betrag auf das interne Guthaben erstattet.

Durchgerechnetes Beispiel

Registrierung von 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.

Innerhalb weniger Minuten wird der Befehl gebündelt, bewiesen und verankert. Von da an löst sich richard.zcash über jeden Indexer auf, mit einem Merkle-Beweis, den Sie selbst prüfen können.