すべての contract data を全世界へ公開せず、参加者は必要な履歴を off-chain で渡し、自ら rule を検証して、Bitcoin 上の暗号学的 commitments と single-use seals の close を確認する。
各受取人は特定 protocol の rule に従い、受け取る state に至る履歴部分だけを検証する。これは部分複製であり、他の参加者は contract の非公開 graph 全体を知ったり保存したりする必要がない。 [4]
必要 data は履歴と proof の package として Bitcoin 外で渡される。受取人は現在残高だけを受け入れず、信頼できる起点までの state transition の連鎖と、各 step が対応する on-chain commitment に結び付くことを検証する。 [4]
Single-use seal は選んだ message に対して有効に一度だけ close できる抽象 commitment である。Bitcoin UTXO は seal として使え、その spend は公開され consensus 順に並ぶ close proof になるが、Bitcoin は非公開 data の意味を評価しない。 [3]
Proof-of-Publication は短い commitment を公開 transaction 順序に anchor し、同じ seal を矛盾する transition に使う試みを検出可能にする。ただし miner と full node が検証するのは Bitcoin rule であり、hash の背後にある business logic ではない。 [2]
Client-Side Validation は一般的な設計モデルで、RGB の別名ではない。LNP/BP registry は LNPBP-9 を informational draft とし、関連 library は commitments、serialization、single-use seals の interface を提供する。具体的 protocol はその上に固有 state と rule を定義する。 [5]
Privacy と scaling は data 保存の責任を所有者へ移す。送信者が完全な履歴を渡さない、または受取人が必要部分を失うと、公開 blockchain は commitment から復元できず、ローカル検証は証明可能な state を得られないことがある。 [4]
一般公開されるのは Bitcoin transaction と短い commitment で、contract 全体ではない。これは全体の data footprint を減らすが匿名性を保証せず、timing、counterparty、data 配送、識別可能な anchor 構造が metadata を生み得る。 [1]
検証には正確な protocol、信頼できる genesis または schema、seal 定義、commitment scheme、完全に連結した履歴、Bitcoin transaction の状態、software version が必要である。On-chain に hash があるだけでは asset の妥当性、価値、所有権を証明しない。 [5]
理解を深めるには、この項目とあわせて次もお読みください UTXO, 二重支払い, Hash, Taproot, Sidechain, コンセンサスルール. 次の項目からも参照されています RGB Protocol, Taproot Assets.