このページでは、送金が Rand を通過する際に、誰が何を担うのかを説明します。証明の生成は高コストで、検証は低コストです。そのため、作業はこの境界で分担されています。証明を作るのは送信者側です。validator は、証明を検証し、順序付けし、投票するだけです。aggregator は、有効化されると、多数の証明を1つにまとめます。図はウォレットから最終ブロックまでの1件の送金を追っています。図の後の各節では、各ロールを順に取り上げます。
1件の送金の経路
- ウォレットが送金を構築します。 入力ノートを選び、そのMerkle witnessを取得し、4つの出力を作って、それぞれをML-KEM-768のエンベロープで封印します。続いて、トランザクションのバインディング(証明を除くすべてに対するハッシュ)を計算します(トランザクション)。
- ウォレットが認可の証明を自分で生成します。 これは、spend keyと新しいsaltに対するティア10の証明で、所要時間は数秒です。spend keyに触れる証明はこれだけで、常にウォレット自身のマシン上で生成されます。
- バンドル証明は、メモリのある場所で生成します。 ティア14のこの証明は、所有権、メンバーシップ、ナリファイア、残高を示すもので、ピーク時に約6 GBを使用します。デスクトップアプリと、約8 GBのメモリを持つスマートフォンは、自分で生成します。それより小さい端末は、ペアリングしたプルーバーに処理を任せます。ペアリング先は、自分で運用するプルーバーか、
prover.randprotocol.orgのvalidatorのプールです。どちらに対しても、送るのはviewing keyとsaltで、spend keyは決して送りません(証明)。 - RPCノードが検証します。 ウォレットの送信先となったノードは、バンドルダイジェストを再計算し、バインディングに対して両方の証明を検証し、手数料を確認します。その後で初めて、トランザクションをピアにゴシップします(証明、メンプール)。
- validatorが順序付けして確定させます。 そのビューのリーダーは、まだ適用可能なトランザクションを、KiBあたりの手数料が高いものから順に取り、ブロックを提案します。すべてのvalidatorが、ブロック内のすべての証明を再検証して投票します。連続する3つのビューでquorum certificateが3つ連鎖すると、ブロックはコミットされます。これには、チェーン20の26台のvalidatorのうち18台がオンラインである必要があります(コンセンサス)。
- ブロックが確定し、誰でも検証できます。
rand_getTransactionがブロックを返した時点で、トランザクションは確定です。後から同期するノードは、署名を信頼するのではなく、すべての証明書とすべての証明を再検証します。
ロール
| ロール | 役割 | 証明を生成するか | 見えるもの | 実行方法 |
|---|---|---|---|---|
| ウォレット | 送金とコールを構築、認可、送信し、自分のキーでチェーンをスキャンする | 認可の証明は常に生成。バンドル証明は、端末にメモリがある場合に生成 | 自分のノートに関するすべて | クライアントページのアプリ、または rand。チェーン20では、Rand Walletまたは rand v0.6.8以降 |
| 委任プルーバー | ペアリングされたウォレットのためにバンドル証明を生成する。すべての応答は、何かが送信される前にウォレットが検証する | バンドル証明のみ | ペアリングされたウォレットのviewing key。過去と将来を含む全履歴が見える。使うことはできない | rand-prover run、または rand-node run --prover |
| validatorのプルーバープール | 独自のプルーバーを持たないウォレットのために、1つの名前と1つのキーの背後で、4台のホスト(validator 2台と、証明専用のマシン2台)が運用する委任プルーバー。手数料なし | バンドル証明のみ | ペアリングしたすべてのウォレットについて、他の委任プルーバーと同じ | prover.randprotocol.org、フィンガープリント RGTF-7HKJ-XZFV-GQ1J |
| RPCノード(オブザーバー) | 同期し、すべての証明を再検証し、JSON-RPCを提供し、検証済みのトランザクションをゴシップする。投票はしない | しない | 公開フィールドのみ:コミットメント、ナリファイア、封印されたエンベロープ、証明 | rand-node run |
| validator | オブザーバーの機能すべてに加えて、自分のビューでの提案と、HotStuffでの投票を行う | しない | 公開フィールドのみ | rand-node run --validator |
| aggregator | 確定したバンドル証明のウィンドウに対して1つの再帰証明を生成し、封印ブロックのために送信する | する。ネットワーク上で最大の証明 | 公開フィールドと証明のみ | rand-node aggregate --watch。aggregation セクションを持つチェーン上で実行 |
証明の生成とバリデーションは別々の仕事であり、validatorにプルーバー用のハードウェアは不要です。プールの4台のうち2台は、プルーバーをサービスとして併せて運用するvalidatorです。残りの2台は、validatorキーを持たない専用のプルーバーマシンです。プールの運用は、バリデーションの一部ではありません。各ロールの規模と、ティアごとに実測した証明のメモリ使用量は、validatorとaggregatorのハードウェアに記載しています。
各ロールが知り得ること
送金のプライバシーは、ネットワークを信頼することではなく、誰がどのキーを持つかで決まります。
- validator、RPCノード、エクスプローラーに見えるのは、すべてのノードに見えるものです。コミットメント、ナリファイア、封印されたエンベロープ、手数料、証明です。金額、アセット、送信者、受信者は見えません。
- 委任プルーバー(プールを含む) には、viewing keyが送られます。それを使えば、ペアリングされたウォレットの全履歴を読めます。ただし、spend keyに対する認可の証明はウォレットのマシン上で生成されるため、使うことはできません。プールとペアリングするということは、その運用者に履歴を見せることを選ぶということです。非公開にしたい場合は、自分の端末で証明を生成するか、自分のプルーバーを運用してください。
- 委任プルーバーはウォレットを欺けません。 ウォレットは、受け取ったすべての証明からダイジェストを読み取り、サイズを確認し、ローカルで検証します。そのため、誤った証明がノードに届くことはありません。
集約:実装済み、未有効化
現在、すべてのブロックはすべての生の証明を含んでおり、送金1件あたり約2.85 MBです。そのため、20 MiBのブロックに入る送金は約7件です。ブロック集約は、fullnodeによるこの問題への答えです。aggregatorは、確定したブロックのウィンドウからバンドル証明を取得し(rand_getUnsealed)、それらすべてを検証する1つの再帰証明を生成して、送信します。それを含むブロックが、そのウィンドウを封印します。これにより、validatorはN個の証明の代わりに1つの集約を検証すればよくなり、ノードは対象となった生の証明を破棄できます。aggregatorはボンドを預け入れる許可不要のロールで、GPUクラスのマシンで動作し、対象となるバンドルの証明分の報酬と、新規発行されるRANDによるブロック補助金を受け取ります。
実装とマージは済んでいますが、有効にはなっていません。ジェネシスに aggregation セクションが必要ですが、チェーン20にはそれがないため、rand_status はすべての集約カウンターをゼロと報告します。有効化する前に、現在の制約セットのもとでバンドルの形状を再測定し、再帰検証器に対して偽造集約の演習を行う必要があります。また、認可を分離したチェーンでは、封印されるのはバンドル証明のみで、認可の証明は封印されません(証明)。