鍵とアカウントタイプ
ZooBC のアカウントを管理するのは署名であって、ユーザー名やパスワードや API キーでは決してありません。どの署名かは、アカウントのタイプによって決まります。ネイティブの Ed25519 のアカウントに加えて、ZooBC は Bitcoin、Ethereum、Solana、Polkadot、Cardano、Ripple、Tron、Tezos が書くのと同じ形式でアドレスが書かれたアカウントを受け入れ、それぞれのチェーン独自の方式でその署名を確認します。したがって Bitcoin や Ethereum の鍵は、元のチェーンでのアドレスと同じアドレスで、ZooBC のアカウントを管理できます。そのアカウントは ZooBC 自身の台帳にある別のもので、ZBC を保有します。
アドレスはタイプとペイロード
アドレスは、4 バイトのタイプ番号(リトルエンディアン)に、タイプによって意味と長さが決まるペイロードが続いたものです(アカウントとアドレス)。ネイティブのアカウントではペイロードは Ed25519 公開鍵そのもの、Ethereum のアカウントでは鍵の Keccak-256 ハッシュの末尾 20 バイト、Bitcoin の P2PKH のアカウントでは鍵の HASH160 です。
| タイプ | アカウント | 書き方 | 署名できるか |
|---|---|---|---|
| 0 | ZooBC、Ed25519 | ZBC_… | はい |
| 1 | Bitcoin レガシー(HASH160) | — | はい |
| 2 | Empty(「受取人なし」) | — | いいえ |
| 3 | Estonia eID(予約) | — | いいえ |
| 4 | Ethereum | 0x… | はい |
| 5 | Bitcoin P2PKH | 1… | はい |
| 6 | Bitcoin P2SH(P2SH-P2WPKH として検証) | 3… | はい |
| 7 | Bitcoin P2WPKH | bc1q…、42 文字 | はい |
| 8 | Bitcoin P2WSH(スクリプト) | bc1q…、62 文字 | いいえ |
| 9 | Bitcoin Taproot | bc1p… | はい |
| 10 | データセットオブジェクト | ZBS_… | いいえ |
| 11 | Solana | Solana と同じ | はい |
| 12 | Polkadot | Polkadot と同じ | はい |
| 13 | Cardano | addr1… | はい |
| 14 | Ripple | r… | はい |
| 15 | Tron | T… | はい |
| 16 | Tezos | tz1… | はい |
鍵なしアドレスも署名できません。プロトコルのプール、アカウントグループ、マルチシグネチャアカウントには鍵がないため、その資金はプロトコルのルールの下でのみ動きます。
ネイティブのテキスト形式は、ZBC_ に、8 文字ずつ 7 つのグループに分けた 56 文字の base32 が続いたものです。32 バイトの鍵に、プレフィックスも対象にする 3 バイトの SHA3-256 のチェックサムを加えたものです。読み取るときには、区切り文字、空白、大文字と小文字の違いは無視されます。同じ 32 バイトの鍵は、ノード鍵(ZNK_)、リレー鍵(ZBR_)、ゲートウェイ鍵(ZBG_)として書くこともできます。
すべての方式に 1 つのダイジェスト
どのアカウントタイプも、同じチェーン束縛ダイジェストに署名します。
digest = SHA3-256("ZBC-TX" ‖ genesis hash ‖ unsigned transaction bytes)
受け入れられるのはこのダイジェストだけで、素のバイト列に対する署名は拒否されます。ジェネシスハッシュがすべての署名を 1 つのチェーンに結び付けます(チェーン束縛署名)。一部の方式は、元のチェーンが求めるとおり、ダイジェストをさらにもう一度ハッシュします。
署名方式
- Ed25519 で 32 バイトのダイジェストに署名するのは、ZooBC(タイプ 0)と Solana(11)です。Cardano(13)と Tezos(16)も Ed25519 で署名しますが、そのアドレスはハッシュなので、署名フィールドは鍵も運びます。2 バイトの長さ、鍵、署名から成る 98 バイトです。鍵は BLAKE2b-28(Cardano)または BLAKE2b-20(Tezos)によってアドレスに結び付けられます。
- Bitcoin 方式の secp256k1 ECDSA は、タイプ 1、5、6、7 と Ripple(14)です。署名フィールドは鍵を運びます。2 バイトの長さ、33 または 65 バイトの鍵、そして 64 バイトの署名(r と s)です。鍵の HASH160 がアドレスと等しくなければならず、署名されるメッセージはダイジェストのダブル SHA-256 で、low-s の署名だけが受け入れられます。
- Ethereum 方式の secp256k1 ECDSA は、Ethereum(4)と Tron(15)です。ダイジェストの Keccak-256 ハッシュに対する 65 バイトの署名(r、s、v)です。鍵は署名から復元されてそのアドレスが比較され、high-s の署名は拒否されます。
- BIP-340 Schnorr は Taproot(9)で、x 座標のみの出力鍵を使います。Taproot の調整はウォレットが適用します。
- sr25519 は Polkadot(12)で、署名コンテキスト "substrate" の下で使います。
Taproot のアカウントは、ジェネシス以降のすべてのチェーンで、SendZBC によって ZBC を受け取ることもできます。
保存されていない鍵を検証する
Ethereum 形式のアドレスは 20 バイトのハッシュにすぎず、公開鍵はチェーン上のどこにも保存されていません。Ethereum の署名は復元可能です。署名されたメッセージと 65 バイトの署名から、それを生成した唯一の公開鍵を誰でも計算できます。ノードはまさにそれを行い、復元した鍵の Keccak-256 ハッシュの末尾 20 バイトを取り、それがアドレスと等しい場合にのみ署名を受け入れます。high-s の署名は拒否されるため、署名を第 2 の有効な形に改変することはできません。登録の手順も外部への問い合わせも必要なく、0x のアカウントは受け取るのと同じように自由に送ることができます。
中に入れて運ばれる外部のトランザクション
外部のアカウントを持つ送信者は、元のチェーンのネイティブなトランザクションを、ZooBC トランザクションのメッセージフィールドに入れることもできます。この経路では、ノードは ZooBC のダイジェストの代わりに、外部のトランザクションとその署名を確認します。
- Ethereum(タイプ 4):アクセスリストが空の、EIP-1559、EIP-2930、またはレガシー(EIP-155)のトランザクション。復元された署名者が送信者で、その
toが受取人で、wei で表した値を 10^10 で割ったものが金額でなければなりません(MetaMask と Ethereum 形式のアクセス)。 - Solana(タイプ 11):lamports が金額に等しい System の送金。
- Bitcoin(タイプ 7 と 5):入力 1 つ、出力 1 つまたは 2 つ、マイナー手数料ゼロ。出力 0 が受取人に支払い、出力 1 があればお釣りを送信者に返します。
このような運び手のメッセージは最大 4,096 バイトで、そのトランザクションは延命の支払いを運ぶことができません(トランザクションのエンベロープ)。
ネイティブの鍵の導出
ネイティブの鍵は、BIP-39 のリカバリーフレーズから導出されます。2,048 ラウンドの PBKDF2-HMAC-SHA512 の後、m/44'/883'/n' に沿って SLIP-0010 の Ed25519 で導出し、すべての段階は強化導出です。883 は ZooBC のコインタイプです。