コマンド形式
zNS のすべての操作は、レジストラのプロトコルアドレス宛のシールドされた ZCash トランザクションであり、 金額が支払いで、メモが署名済みのコマンドです。どちらも同じノートの中を運ばれるので、意図と支払いが不可分に 結びつきます — 突き合わせるべき別の参照番号や請求書はありません。
このページは正確なワイヤ形式を示します。これに沿って組み立てたコマンドは、レジストラとゼロ知識回路の どちらにも受け入れられます。
構造
すべてのコマンドはコロン区切りの ASCII で、プロトコルマーカーとバージョンから始まります：
zNS:1:{OP}:{name}:…:{ed25519_pubkey_hex}:…:{nonce}:{signature_hex}
その間のフィールドは操作によって変わります：
| 操作 | メモの構成 | 支払額 |
|---|---|---|
REG 登録 | zNS:1:REG:{name}:{address}:{pubkey}:{nonce}:{sig} | 名前の長さに応じた登録料 |
UPD アドレス変更 | zNS:1:UPD:{name}:{address}:{pubkey}:{nonce}:{sig} | 変更料 |
CHG 保有者の移転 | zNS:1:CHG:{name}:{new_pubkey}:{nonce}:{sig} | 変更料 |
LST 出品 | zNS:1:LST:{name}:{pubkey}:{price}:{nonce}:{sig} | 変更料 |
ULT 取り下げ | zNS:1:ULT:{name}:{pubkey}:{nonce}:{sig} | 変更料 |
BUY 購入 | zNS:1:BUY:{name}:{address}:{pubkey}:{nonce}:{sig} | ちょうど出品価格 |
CHG では {new_pubkey} が受け取る側の保有者の鍵で、署名は渡す側の保有者が行います — 移転を
承認するのは現在の保有者です。
署名対象のメッセージ
署名は末尾の :{signature} を除いたコマンドを対象とします。つまりマーカーから nonce までを含む全体です：
zNS:1:REG:richard.zcash:u1…:0101…0101:1780000001
ルールは厳密で、クライアントがどれか 1 つでも誤れば、回路が拒否する署名ができてしまいます：
pubkeyは小文字の 16 進数、64 文字です。priceはLSTにのみ現れます。addressはREG、UPD、BUYにのみ現れます。priceとnonceは 10 進数で、先頭のゼロ・符号・パディングはいずれも不可です。- 署名はまさにそのバイト列に対する Ed25519 署名で、16 進数エンコードの 128 文字です。
検証は厳格です。正準でない署名や小さな位数の鍵は拒否されます。
フィールドのルール
名前
| ルール | 値 |
|---|---|
| 文字 | a-z、0-9、ハイフン |
| 長さ | ゾーンを含めて 1〜64 文字 |
| 大文字・小文字 | 小文字のみ — 名前は小文字で保存・ハッシュされます |
| ハイフン | 先頭不可、末尾不可、連続も不可 |
| ゾーン | .zcash、.zec、.private、.secure、.safe |
ドットはラベルとゾーンを分けるちょうど 1 つだけが許されます。
宛先アドレス
名前が解決される先のアドレスは、Orchard レシーバーを備えたメインネットの Unified Address でなければ なりません。それを持たないアドレスは拒否されます。
理由は恣意的ではなく実務的です。レジストラは Orchard の鍵素材を通じて受け取りと支払いを行い、その素材は ZIP 229 により Ironwood プールもカバーします。Orchard レシーバーのない アドレスへは支払えないので、返金にも売上にも使えません。
Ironwood は新しいレシーバーを追加しません
Ironwood は新しい価値プールであって、新しいアドレス形式ではありません。ウォレットはノートをそちらへ移し ますが、受け取りアドレスは Orchard アドレスのままです。現行ウォレットの Unified Address はそのまま使えます。
Nonce
nonce は署名した時点の秒単位の Unix タイムスタンプです。
- その名前について現在記録されている nonce より厳密に大きくなければなりません。これが古い署名済み コマンドの再利用を防ぎます。
- それを運ぶブロックより 300 秒を超えて先行することはできません。この余裕は通常の時計のずれを吸収しつつ、 nonce を遠い未来に据え置くことは許しません。
初回登録なら、現在時刻のタイムスタンプであれば何でも構いません。
価格
価格を持つのは LST だけです。整数の zatoshi（1 ZEC = 100,000,000 zatoshi）で、ゼロより大きくなければ
なりません。
すでに出品済みの名前を新しい価格で出し直すことは許されています — もう 1 度 LST を送ってください。最も
新しいものが有効になります。
サイズの上限
ZCash のメモはちょうど 512 バイトで、コマンド全体がその中に収まらなければなりません。固定部分が占める 量は予測できます：
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
残るおよそ 295 バイトを名前と宛先アドレスで分け合います。レシーバーが複数ある Unified Address は長くなり 得るので、名前がとても長い場合、とても長いアドレスは収まらないかもしれません。クライアントはこの予算を 計算し、ユーザーが支払う前に警告すべきで、後からトランザクションを失敗させるべきではありません。
支払い
有効性はメモと同じくらい金額によって決まります：
REGは名前の長さに応じた登録料をちょうど支払わなければなりません。UPD、CHG、LST、ULTは変更料をちょうど支払わなければなりません。BUYは出品価格をちょうど支払わなければなりません。
長さはゾーンを除いたラベルで数えます：ab.zcash は 2 文字の名前です。
支払いが不足または超過したコマンドは処理されません。操作と公開鍵が読み取れる場合、金額は内部残高に計上 され、出金できます — 質問と回答を参照してください。
順序
コマンドは ZCash が生成した順序で処理されます。ブロック高、次にブロック内のトランザクションインデックス、 次に入力インデックスの順です。レジストラは順序を選べませんし、すべての独立したインデクサーに別のルートを 計算させることなく並べ替えることもできません。
競合する操作 — 同じ名前に対する 2 つの REG、または同じ出品に対する 2 つの BUY — では、その順序で最初の
ものが勝ち、残りの金額は内部残高へ返金されます。
具体例
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.
数分のうちにコマンドはバッチにまとめられ、証明され、アンカーされます。それ以降 richard.zcash はどの
インデクサー経由でも解決でき、しかもあなた自身で検証できるマークル証明が添えられます。