Client-Side Validation

각 수신자는 특정 protocol rule에 따라 자신이 받을 state로 이어지는 이력 부분만 검증한다. 이는 부분 복제이므로 다른 참여자는 contract의 전체 비공개 graph를 알거나 보관할 필요가 없다. [4]

필요한 data는 이력과 proof package로 Bitcoin 밖에서 전달된다. 수신자는 현재 잔액만 받아들이면 안 되며 신뢰할 수 있는 시작점까지 state transition이 이어지는지와 각 단계가 해당 on-chain commitment에 묶이는지 검증해야 한다. [4]

Single-use seal은 선택한 message 위에서 유효하게 한 번만 닫을 수 있는 추상 commitment다. Bitcoin UTXO가 이런 seal이 될 수 있다. 이를 spend하면 공개되고 consensus 순서가 부여된 닫힘 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이 필요하다. Hash가 on-chain에 있다는 사실만으로 asset의 유효성, 가치, 소유권이 증명되지는 않는다. [5]