アカウントとアドレス
ZooBC では、鍵がそのままアカウントです。ネイティブのアカウントは Ed25519 公開鍵で識別され、ZBC_ で始まる 66 文字のアドレスとして書かれます。アドレスを発行する者はいません。ウォレットが鍵からアドレスを導き出し、それはオフラインでもできます。すべてのアドレスにはチェックサムが含まれているため、誤って入力されたアドレスは、何かが送られる前に拒否されます。
アドレスの見た目
ネイティブのアドレスは、プレフィックス ZBC、アンダースコア、そして 8 文字ずつ 7 つのグループに分けた 56 文字から成ります。
ZBC_57J5D5QV_OPO4JILA_RQW2JC77_OOIDM4VM_BHFCLTKB_2DOFOR4L_Z24K7SFRこの例は zoobc.how のクイズのためにハッシュから作られたものです。誰もその鍵を持っていないため、決してコインを送らないでください。
56 文字は、大文字の A から Z と数字の 2 から 7 から成るアルファベットである base32 で書かれた 35 バイトです。アカウントを識別する 32 バイトに、3 バイトのチェックサムが続きます。
32 バイトは鍵そのもの
チェーンの内部では、アカウントはテキストではありません。4 バイトのタイプ番号に、タイプによって長さが決まるペイロードが続いたものです。タイプ 0 はネイティブの ZooBC アカウントで、そのペイロードはアカウントの Ed25519 公開鍵そのものであり、そのハッシュではありません。したがって、誰でもアドレスから直接鍵を読み取ることができます。バージョン 0.5.8 以降、ノードの API はネイティブのアカウントについて、アドレスだけから /api/v1/accounts/<address>/pubkey に答えます。
他のチェーンは別の方法をとっており、ZooBC はそれらのアドレスを使うときにはそれに従います。Ethereum アカウントのペイロードは鍵の Keccak-256 ハッシュの末尾 20 バイトで、従来型の Bitcoin（P2PKH）アカウントのペイロードは鍵の 20 バイトの HASH160 です。ZooBC は Bitcoin、Ethereum、Solana、Polkadot、Cardano、Ripple、Tron、Tezos のアカウントを受け入れ、それぞれ元のチェーンと同じ書き方で書かれ、元のチェーンの署名方式で検証されます（鍵とアカウントタイプ）。
チェックサムが誤入力を見つける
チェックサムは、32 バイトのペイロードに 3 文字のプレフィックスを続けたものに対する SHA3-256 の最初の 3 バイトです。ウォレットでも、コマンドラインツール でも、ノードの API でも、アドレスをデコードするものはチェックサムを再計算し、一致しなければそのアドレスを拒否します。ランダムな誤入力が別の有効なアドレスになるのは、およそ 2^24 回、つまり 1,670 万回に 1 回だけです。クイズのための確認として、上の例のアドレスの 1 文字を変えた 1,736 通りすべてを試したところ、すべてが拒否されました。
拒否はトランザクションが作られる前に起こるため、何も送られません。コンセンサス自体がテキストをデコードすることはありません。トランザクションはアドレスをバイト列として運び、チェックサムはテキストをバイト列に変換するツールが確認します。「最も近いアカウント」を探す仕組みはなく、誤っているが有効なアドレスに送られたコインが自然に戻ってくることはありません。
アドレスの書き方
デコードは有効文字ルールに従います。アンダースコア、ハイフン、空白文字は改行も含めてすべて取り除かれ、残ったものが大文字に変換されます。したがって ZBC_57J5D5QV_…、zbc-57j5d5qv-…、区切り文字がまったくないアドレス、メールの中で 2 行に折り返されたアドレスは、すべて同じ 32 バイトにデコードされ、その後チェックサムが通常どおり確認されます。区切り文字や大文字は、人が読んだりコピーしたりしやすくするためだけに存在します。
プレフィックス
プレフィックスの 3 文字は、その鍵が何のためのものかを示します。
| プレフィックス | 意味 |
|---|---|
ZBC_ | アカウント（タイプ 0） |
ZNK_ | ノード鍵（ノードの鍵） |
ZBR_ | リレー鍵（リレー） |
ZBG_ | ゲートウェイ鍵（ゲートウェイ） |
ZBS_ | データセットオブジェクト（タイプ 10、データセット） |
API は、トランザクション ID について ZTX_ 形式も受け付けます。
チェックサムはプレフィックスも対象にしているため、同じ 32 バイトを 2 つのプレフィックスで書くと、プレフィックスの後の最初の 51 文字は共通で、最後の 5 文字だけが異なります。例の鍵をノード鍵として書くと、末尾は …_2DOFOR4L_Z24K7SFR ではなく …_2DOFOR4L_Z24FR5JM になります。末尾を再計算せずに手作業でプレフィックスを入れ替えるとチェックサムが壊れるため、その書き換えは見破られます。ノード自身のアカウントは、そのノード鍵の ZBC_ 形式です。
鍵のないアドレス
ネイティブのアドレスの中には、鍵ではないものもあります。対応する秘密鍵が存在しないため、署名によってそこから支出することはできず、そのコインはプロトコル自身のルールの下でのみ動きます。
- プロトコルのプール：ロンジェビティプール
ZBCLONGV、ストレージプールZBCSTORE、アプリプールZBCAPPS。それぞれゼロで 32 バイトに埋めた ASCII の名前です（プール）。 - アカウントグループ。それを設立したトランザクションのハッシュで名前が付けられます（アカウントグループ）。
- マルチシグネチャアカウント。そのしきい値と参加者のハッシュです（マルチシグネチャ）。
- データセットオブジェクト。それを作成したトランザクションのハッシュです（データセット）。
すべてが公開されている
すべてのノードが完全な状態を保持しており、その API はアカウントも鍵も API キーもなしに誰にでも答えます。GET /api/v1/accounts/<address> は残高を返し、その下のルート /history、/transactions、/movements は、アカウントが行ったことと、支払ったレントや獲得した報酬を含む残高のすべての変化をその原因とともに一覧表示します。エクスプローラーは同じデータをウェブページとして表示します（エクスプローラーとアーカイブノード）。
チェーンが記録しないのは、あなたが誰かということです。アドレスは鍵であって名前ではなく、誰かがその結び付きを作らない限り、チェーン上の何物もそれを人物に結び付けません。したがって ZooBC でのプライバシーは、残高を隠すことではなく、アドレスの使い方から生まれます。行動するには鍵が必要ですが、見るだけなら決して必要ありません。
ZBC を保有するアカウントは少額のレントを支払い、残高でそれをまかなえないアカウントはプルーニングされます（アカウントレントとプルーニング）。