3つの表現
エンジン状態マーケット · アカウント · ポジション · 板 · クリアリングハウスブロックをまたいで存続 · 再構成
ブロックワーキングセットマーク · 触れたアカウント · 約定 · 準備中の出力1ブロックだけ存在 · ジャーナル
チェーン状態バージョン付きキーバリュー、Merkleで認証正本
これが防ぐ失敗メモリ上のビューがコミット済みの内容からずれたエンジンは、そのまま答えを返し続けます。その答えはすべて誤っており、ずれが表に出るのは決済の段階です。
エンジン状態はコミット済みの記録から導出できなければならず、その逆であってはならない
キー
チェーン状態はキーでアドレス指定されます。取引に関する状態は、名前が付き、バージョンが明示された名前空間にまとめられます。たとえば手数料設定、無期限先物のインデックス、レバレッジティア表、管理ロールの一覧です。 バージョンの接尾辞は飾りではありません。設定の形が変わると、そのキーは新しいバージョンへ移り、旧スキーマで書かれた状態を移行中も読めるように以前のキーが残されます。特定のバージョンをハードコードして再確認しない読み手は、移行後も古い設定を黙って読み続けます。現在のキーを解決する読み手はそうなりません。設定をクライアントのコードに固定するのではなく、チェーンから読むべき理由がこれです。手数料ティアのサービスがサイクルごとにライブの手数料設定を読み直しているのも、まさにこの理由によります。クライアントに焼き込まれたティア表は、いずれネットワークが適用している表と食い違います。
バージョン
コミットされたブロックごとに、バージョンが1つ進みます。状態の値は書き込まれた時点のバージョンに紐づけて保存されるため、ストアが持つのは「現在の状態」だけではなく「任意のバージョン時点の状態」です。 この性質が、いくつものことを同時に可能にしています。- 証明を、現在に対してだけでなく特定のバージョンに対して生成できます。
- リプレイを、ジェネシスからだけでなく任意のバージョンから開始できます。
- 読み取りは過去に向けられます。ポジションの履歴を再構成するインデクサーは、ログを走査しているのではなく古いバージョンを問い合わせています。
- プルーニングは、構造上の制約ではなく、どこまで遡って保持するかというポリシーの判断になります。
最終的にコミットされるもの
カーネルの実行は、ブロックごとに2種類のものを生み出します。各トランザクションは、それ自身に紐づいた書き込みとイベントを持ちます。単一のユーザートランザクションに属さない効果（資金調達フロー、保険基金の移動、ブロック単位のカウンタ）は、専用のシステムチャネルへ送られます。 この2つの間で失われるものはありません。カーネル内部の実行効果で、トランザクションの出力にもシステムチャネルにも現れないものは存在しません。この完全性があるからこそ、コミット済みの記録は要約ではなく全体像として扱えます。マッチングがバッチで走った場合でもイベントを原因のトランザクションまで辿れるのは、このためです。次に読む
ストレージと証明
コミット済みの状態が物理的にどう保存され、認証され、プルーニングされるのかです。
ステートシンク
チェーンを一度も見たことのないノードが、どうやって追いつくのかです。
IntentionKernel
エンジン状態とブロックワーキングセットが存在する場所です。
インデクサー
コミット済みの状態を、照会可能なものに変えます。