台帳
所有権は、データベースの約束ではなく状態機械です。どの残高も、有効な状態遷移を順番に当てはめた結果です。
トークンが何もないところから作られたり、二重に使われたりしないのは、なぜでしょう?
QLYP の残高は、誰かが打ち込んだ数字ではありません。決まった起点からチェーンの履歴をたどり、公開されたルールのもとで、有効な操作をすべて順番に当てはめた結果です。明日、別のマシンでやり直しても、同じ台帳になります。
単位は勝手に増えない
どの資産でも、すべてのブロックのあとで次の式が成り立ちます。
保存則
利用可能 + 予約 = ミント済み ≤ 最大供給量
ミントは、供給量と保有者の残高を一緒に増やします。送金は、ある残高から引いて別の残高に足します。オファーは、単位を利用可能な残高から予約へ移します。売れれば単位は買い手へ移り、予約が解除されれば売り手に戻ります。どの経路でも、新しい単位は生まれません。
- 01 / 05
Alice が 1,000 をミント
ミントすると、発行済みの供給量と Alice の利用可能残高が一緒に増えます。ほかに単位を生み出す方法はありません。残高を書き換えられる管理者もいません。
- 02 / 05
Bob に 400 をオファー
有効なオファーを作ると、400 単位が利用可能残高から予約へ移ります。単位は消えず、供給量にも数えられたままですが、Alice はもうそれを使えません。
- 03 / 05
700 を送ろうとする
使えるのは 600 だけなので、送金は拒否されます。ジャーナル(記録)には判定が残りますが、何も動きません。一部だけの送金も起きず、連番も進みません。予約された単位を二重に使うことはできません。
- 04 / 05
Bob がオファーを買う
Bob の正規の購入によって予約が決済され、400 単位が Bob に渡ります。受け渡しはチェーンの履歴に当てはめるルールであり、サーバーが送ると決めるものではありません。
- 05 / 05
後片付けでは何も変わらない
あとで使用済みの提案を片付けても、Alice にもう一度入金されることはありません。チケットはすでに決済済みだからです。どの段階でも、利用可能と予約の合計は、ミントした 1,000 に等しくなります。
状態が覚えていること
| 部分 | 記録する内容 |
|---|---|
| 資産 | 作成者、変更できない定義、これまでにミントされた供給量 |
| 残高 | アカウントと資産ごとの、使える数量 |
| 連番 | アカウントごとに、次に受け入れられる QLYP の連番 |
| 予約 | 各オファーのロット。作成から、売却、取り消し、期限切れまで |
| シンボル | 各シンボルを最初に取得した有効なトークン |
| ジャーナル | すべての操作の判定(受理か拒否か)。あとから確認できます |
上の式に加えて、ルールは、残高がマイナスにならないこと、すべてのシンボルがその資産を指していること、各部分が互いに食い違っていないことも確かめます。これで防げるのは使いすぎだけではありません。同じ台帳の中のどんな食い違いも見つけられます。
順番にリプレイし、有効なときだけ確定する
確定したブロックは、それぞれ直前の状態のコピーに当てはめられます。拒否された操作は、ジャーナルに判定を 1 行残すだけで、ほかには何も起こしません。一部だけの送金も、連番が進むこともありません。ブロック全体を当てはめ終え、すべてのチェックがまだ成り立っているときにだけ、新しい状態が古い状態と入れ替わります。
形式が壊れた操作や、承認のない操作は、単に拒否されます。チェーンのつながりが切れている、受領記録のつじつまが合わない、知らないランタイムに出会った、といった場合は話が違います。これは整合性の問題なので、インデクサーはもっともらしい台帳をでっち上げるのではなく、止まります。
管理者はいません
ルールには、残高を編集する機能も、あとから変えられる発行ポリシーも、自動のブリッジもありません。受け入れられた状態遷移の外で残高を書き込む実装は、QLYP の台帳を計算しているとは言えません。