Zamiast globalnie publikować wszystkie dane kontraktu, uczestnicy przekazują wymaganą historię off-chain, samodzielnie sprawdzają reguły oraz kontrolują w Bitcoin kryptograficzne commitments i zamknięcia single-use seals.
Każdy odbiorca według reguł konkretnego protokołu sprawdza tylko część historii prowadzącą do otrzymanego stanu. To częściowa replikacja: pozostali uczestnicy nie muszą znać ani przechowywać całego prywatnego grafu kontraktu. [4]
Potrzebne dane są przekazywane poza Bitcoin jako pakiet historii i dowodów. Odbiorca nie może przyjąć jedynie bieżącego salda; musi sprawdzić ciąg przejść aż do zaufanego początku oraz powiązanie każdego kroku z właściwym on-chain commitment. [4]
Single-use seal to abstrakcyjny commitment, który można prawidłowo zamknąć nad wybraną wiadomością tylko raz. Bitcoin UTXO może pełnić rolę takiej pieczęci: jego wydanie jest publicznym, uporządkowanym przez consensus dowodem zamknięcia, choć Bitcoin nie ocenia znaczenia prywatnych danych. [3]
Proof-of-Publication kotwiczy krótki commitment w publicznej kolejności transakcji i pozwala wykryć próbę użycia tej samej pieczęci do sprzecznych przejść. Minerzy i full nodes sprawdzają reguły Bitcoin, a nie logikę biznesową ukrytą za hash. [2]
Client-Side Validation jest ogólnym modelem projektowym, a nie synonimem RGB. Rejestr LNP/BP wymienia LNPBP-9 jako informacyjny draft, a powiązane biblioteki udostępniają interfejsy commitments, serializacji i single-use seals; konkretne protokoły definiują własny stan i reguły. [5]
Prywatność i skalowanie przenoszą obowiązek przechowywania danych na ich właścicieli. Jeśli nadawca nie dostarczy całej historii lub odbiorca utraci potrzebną część, publiczny blockchain nie odtworzy jej z commitment i lokalna walidacja może zostać bez możliwego do udowodnienia stanu. [4]
Publicznie widać zwykle tylko transakcję Bitcoin i krótki commitment, nie cały kontrakt. Ogranicza to globalny ślad danych, ale nie gwarantuje anonimowości: czas, kontrahenci, sposób przekazania danych i rozpoznawalna struktura anchors mogą tworzyć metadata. [1]
Weryfikacja wymaga dokładnego protokołu, zaufanego genesis lub schema, definicji seal, commitment scheme, pełnej powiązanej historii, statusu transakcji Bitcoin i wersji software. Sam hash on-chain nie dowodzi ważności, wartości ani własności aktywa. [5]
Pełniejszy obraz uzyskasz, czytając to hasło razem z UTXO, Podwójne wydanie, Hash, Taproot, Sidechain, Reguły konsensusu. Do tego hasła prowadzą również odsyłacze z RGB Protocol, Taproot Assets.
01Czy Bitcoin full nodes wykonują Client-Side Validation?+
Nie. Full nodes sprawdzają transakcję Bitcoin i jej reguły consensus; odbiorca lokalnie sprawdza prywatne dane i ich reguły właściwym klientem.