Chuyển tới nội dung chính

Định dạng lệnh

Mọi thao tác zNS đều là một giao dịch ZCash được che chắn gửi tới địa chỉ giao thức của nhà đăng ký, trong đó số tiền là khoản thanh toán còn memo là lệnh đã ký. Cả hai cùng đi trong một ghi chú, nên ý định và thanh toán gắn chặt không tách rời — không có mã tham chiếu hay hóa đơn riêng nào phải đối chiếu.

Trang này mô tả đúng định dạng truyền. Một lệnh dựng theo nó sẽ được cả nhà đăng ký lẫn mạch không tiết lộ tri thức chấp nhận.

Cấu trúc

Mọi lệnh đều là ASCII phân tách bằng dấu hai chấm, bắt đầu bằng dấu hiệu giao thức và phiên bản:

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

Các trường ở giữa phụ thuộc vào thao tác:

Thao tácBố cục memoSố tiền phải trả
REG đăng kýzNS:1:REG:{name}:{address}:{pubkey}:{nonce}:{sig}phí đăng ký theo độ dài tên
UPD đổi địa chỉzNS:1:UPD:{name}:{address}:{pubkey}:{nonce}:{sig}phí thay đổi
CHG chuyển chủ sở hữuzNS:1:CHG:{name}:{new_pubkey}:{nonce}:{sig}phí thay đổi
LST rao bánzNS:1:LST:{name}:{pubkey}:{price}:{nonce}:{sig}phí thay đổi
ULT gỡ khỏi chợzNS:1:ULT:{name}:{pubkey}:{nonce}:{sig}phí thay đổi
BUY muazNS:1:BUY:{name}:{address}:{pubkey}:{nonce}:{sig}đúng giá niêm yết

Với CHG, {new_pubkey} là khóa của chủ sở hữu tiếp nhận, còn chữ ký do chủ sở hữu chuyển giao tạo ra — chính chủ sở hữu hiện tại cho phép việc chuyển giao.

Thông điệp được ký

Chữ ký bao trùm lệnh không gồm phần :{signature} ở cuối — tức là mọi thứ từ dấu hiệu giao thức cho tới hết nonce:

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

Các quy tắc rất chặt, và một ứng dụng khách sai bất kỳ điều nào cũng sẽ tạo ra chữ ký bị mạch từ chối:

  • pubkeyhex chữ thường, 64 ký tự.
  • price chỉ xuất hiện với LST.
  • address chỉ xuất hiện với REG, UPDBUY.
  • pricenonce ở hệ thập phân, không có số 0 dẫn đầu, không dấu và không đệm.
  • Chữ ký là Ed25519 trên đúng những byte đó, mã hóa hex, 128 ký tự.

Việc kiểm chứng là nghiêm ngặt: chữ ký không chuẩn tắc và khóa bậc nhỏ đều bị từ chối.

Quy tắc các trường

Tên

Quy tắcGiá trị
Ký tựa-z, 0-9, dấu gạch nối
Độ dài1–64 ký tự tính cả vùng
Chữ hoa/thườngchỉ chữ thường — tên được lưu và băm ở dạng chữ thường
Dấu gạch nốikhông ở đầu, không ở cuối, không bao giờ đôi
Vùng.zcash, .zec, .private, .secure, .safe

Chỉ cho phép đúng một dấu chấm, ngăn nhãn với vùng.

Địa chỉ đích

Địa chỉ mà một tên phân giải tới phải là Unified Address trên mainnet có bộ nhận Orchard. Địa chỉ không có bộ nhận đó sẽ bị từ chối.

Lý do mang tính thực tiễn chứ không tùy tiện: nhà đăng ký nhận và chi trả qua vật liệu khóa Orchard, vốn theo ZIP 229 cũng bao trùm bể Ironwood. Không thể trả tiền cho một địa chỉ thiếu bộ nhận Orchard, nên nó không dùng được cho hoàn tiền lẫn doanh thu bán hàng.

mẹo

Ironwood không thêm bộ nhận mới

Ironwood là một bể giá trị mới, không phải định dạng địa chỉ mới. Các ví chuyển ghi chú vào đó, còn địa chỉ nhận vẫn là địa chỉ Orchard. Unified Address của một ví hiện đại vẫn hoạt động bình thường.

Nonce

Nonce là dấu thời gian Unix tính bằng giây tại thời điểm bạn ký.

  • Nó phải lớn hơn nghiêm ngặt so với nonce đang được ghi cho tên đó. Đây chính là thứ ngăn việc phát lại một lệnh đã ký từ trước.
  • Nó không được vượt trước khối chứa nó quá 300 giây; khoảng đệm này hấp thụ sai lệch đồng hồ thông thường mà không cho phép đặt một nonce ở quá xa trong tương lai.

Với lần đăng ký đầu tiên, bất kỳ dấu thời gian hiện tại nào cũng được.

Giá

Chỉ LST mang giá. Đó là một số nguyên zatoshi (1 ZEC = 100.000.000 zatoshi) và phải lớn hơn 0.

Được phép rao bán lại một tên đã niêm yết ở mức giá mới — hãy gửi thêm một lệnh LST. Lệnh gần nhất sẽ thắng.

Giới hạn kích thước

Một memo ZCash chiếm đúng 512 byte, và toàn bộ lệnh phải vừa trong đó. Các phần cố định tiêu tốn một lượng dự đoán được:

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

Còn lại khoảng 295 byte chia cho tên và địa chỉ đích. Một Unified Address có nhiều bộ nhận có thể rất dài, nên với một cái tên rất dài thì một địa chỉ rất dài có thể không vừa. Ứng dụng khách nên tính toán hạn mức này và cảnh báo trước khi người dùng trả tiền, thay vì để giao dịch thất bại sau đó.

Thanh toán

Số tiền quyết định tính hợp lệ không kém gì memo:

  • REG phải trả đúng phí đăng ký tương ứng độ dài tên.
  • UPD, CHG, LST, ULT phải trả đúng phí thay đổi.
  • BUY phải trả đúng giá niêm yết.

Độ dài được đo trên nhãn, không tính vùng: ab.zcash là tên 2 ký tự.

Lệnh trả thiếu hoặc trả thừa sẽ không được xử lý. Nếu thao tác và khóa công khai đọc được, số tiền sẽ được ghi có vào số dư nội bộ của bạn và có thể rút — xem Hỏi & Đáp.

Thứ tự

Các lệnh được xử lý theo thứ tự mà ZCash tạo ra chúng: chiều cao khối, rồi chỉ số giao dịch trong khối, rồi chỉ số đầu vào. Nhà đăng ký không chọn thứ tự và không thể đảo thứ tự mà không khiến mọi trình lập chỉ mục độc lập tính ra một gốc khác.

Với các thao tác tranh chấp — hai lệnh REG cho cùng một tên, hoặc hai lệnh BUY cho cùng một niêm yết — lệnh đầu tiên theo thứ tự đó thắng, số tiền của những lệnh còn lại được hoàn về số dư nội bộ.

Ví dụ có lời giải

Đăng ký 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.

Trong vài phút, lệnh được gom lô, chứng minh và neo lại. Từ đó trở đi, richard.zcash phân giải được qua bất kỳ trình lập chỉ mục nào, kèm một bằng chứng Merkle mà bạn tự kiểm chứng được.