データセット

データセットは、ZooBC にデータを置く最も簡単な方法です。プロパティ名とその値から成る小さなレコードで、あるアカウントが、通常は自分自身であるアカウントの下に書き込みます。すべてのノードがその行をチェーンの状態の一部として保持するため、どのアプリもどのノードの API からでもそれを読むことができます。アプリは行を、プロフィール、設定、リリースの告知、請求書、トークンのアイコンに使っています。

行

SetupAccountDataset トランザクション（タイプ 3）は 1 つの行を書き込み、その行は 3 つのものをキーとします。

• 設定者：トランザクションを送るアカウント
• 受取人：行が置かれるアカウント。通常は設定者自身です（空の受取人も有効なキーです）。
• プロパティ：1 から 256 バイトの名前で、空であることはありません。

値は最大 4,096 バイトを保持し、トランザクションの本体は最大 65,536 バイトです。行は版管理されています。同じキーに再び書き込むと現在の行が置き換えられ、RemoveAccountDataset（タイプ 259）は行を無効にします。

行は公開されています。誰でも読めるため、データセットは秘密を置く場所ではありません。大きなファイルを保持する方法でもありません。小さなファイルは チェーン上のファイル（DFS） へ、大きなファイルは 分散ストレージプール へ送られます。

誰が書いたかが重要

どのアカウントも、どの受取人の下にでも行を書くことができ、受取人の同意は求められません。誰でもどのアドレスにでも支払いを送れるのと同じです。したがって行は、その設定者が受取人について述べた声明です。チェーンは誰がいつそれを述べたかを証明しますが、その声明が正しいかどうかは知りえません。

ノードは GET /api/v1/accounts/<address>/datasets でアカウントの行を一覧表示し、?property=<prefix> で絞り込むこともできます。この一覧は、そのアドレスが設定者または受取人であるすべての行を返し、それぞれに role（setter、recipient、または both）のラベルを付けます。ユーザーの下に「verified = yes」を見つけたアプリは、設定者が自分の検証用アカウントなど信頼するアカウントである場合にのみそれを受け入れ、そのような行がなければ「未検証」と答えなければなりません（チェーンデータは信頼できない入力）。

オブジェクトとオーナー

すべての行は、それを作成したトランザクションのハッシュで名前が付けられたデータセットオブジェクトに属します。オブジェクトにはオーナー（最初は作成者）、保留中のオーナー、管理モードがあります。

• 引き渡しは 2 段階で行われます。オーナーが新しいオーナーを指定した TransferDataset（タイプ 42）を送ると、チェーンは保留中のオーナーを記録するだけです。引き渡しは、そのアカウントが AcceptDataset（タイプ 44）を送ったときに完了します。他の誰かからの AcceptDataset や、保留中のオーナーのいないオブジェクトに対する AcceptDataset は有料の空操作です。手数料は徴収され、何も変わりません。したがって、オブジェクトとそれに伴うレントを、求めていないアカウントに押し付けることは誰にもできず、新しいオーナーが受諾するまでは元のオーナーがオーナーのままです。
• 削除。 オーナーが送る DeleteDataset（タイプ 45）は、オブジェクトのすべての行を無効にし、オブジェクトのデポジットはロンジェビティプールに回収されます。
• ポリシー。 SetDatasetPolicy（タイプ 43）は、オブジェクトに管理モード（オーナーのみ、ホワイトリスト、ブラックリスト、オープン）とアクセスリストを保存しますが、それを読むコンセンサスのルールはないため、何も制限しません。

各オブジェクトにはデポジットアドレスもあります。タイプ 10 のアカウントで ZBS_… と書かれ、そのバイト列は 0A000000 にオブジェクト ID が続いたものです。誰でも通常の SendZBC で資金を入れることができるため、ユーザーのグループが共有のレコードを一緒に存続させることができます。それは資金を持つ通常のアカウントなので、アカウントレントとプルーニング も支払います。GET /api/v1/dataset-address/<hash or ZBS_ address> がそれを表示します。

レント

課金期間（mainnet では 172,800 ブロック、約 30 日）ごとに 1 回、チェーンは各オブジェクトにその有効な行のバイト数に応じて課金します。

bytes = sum of (property + value) over the object's active rows
rent  = ceil(bytes × price per MiB ÷ 1,048,576), then × storage multiplier, rounded up

開始時の価格は 1 MiB あたり 5,000,000 アトミック単位（0.05 ZBC）で、保存乗数は 1.0 から始まります。行のちょうど 1 MiB は 1 期間あたりちょうど 0.05 ZBC を支払います。14 バイトのプロパティと 300 バイトの値からなる合計 314 バイトの行は 1,498 単位を支払います。314 × 5,000,000 ÷ 1,048,576 は 1,497.27 で、課金の各段階で切り上げられるからです。

レントはまずデポジットから、次にオーナーの残高から引かれます。両方を合わせても支払えない場合、オブジェクトのすべての行は無効になり、残ったデポジットはロンジェビティプールに入ります。受取人が課金されることは決してありません。データセットのレントはすべてロンジェビティプールに入金され、プールはすべてのブロックでその一部をノードに支払います。ZBC は決してバーンされません。

課金期間はスナップショットの間隔に従います。価格は席が投票で決め、1 アトミック単位まで下げることができます。価格はスナップショットサイクルごとに 1 回、制限の範囲内で、集計対象の席の票の平均へ動きます（価格投票）。

予約されたプレフィックス

いくつかのプロパティのプレフィックスは予約されており、チェーンはその行を受け入れる前に確認します。この判定はプロパティの先頭の生のバイト列を比較するため、invoice: は inv: ではありません。

したがってトークンのアイコンは、URL の向こうではなく、チェーン上の行の中にあります。これらの確認のどれにも誰かの署名は関わりません。すべてのノードが同じルールを適用します。

関連項目

• チェーン上のファイル（DFS）
• チェーンデータは信頼できない入力
• データ保持のための支払い（ロンジェビティ）
• アカウントレントとプルーニング
• データとストレージ