Client-Side Validation

يتحقق كل مستلم وفق قواعد protocol المحدد من جزء السجل الذي يقود إلى الحالة المستلمة فقط. هذه partial replication؛ فلا يحتاج بقية المشاركين إلى معرفة الرسم الخاص الكامل للعقد أو حفظه. [4]

تُنقل البيانات المطلوبة خارج Bitcoin كحزمة من السجل والـproofs. لا يجوز للمستلم قبول الرصيد الحالي فقط؛ بل يتحقق من تسلسل state transitions حتى أصل موثوق ومن ارتباط كل خطوة بالـon-chain commitment المقابل. [4]

Single-use seal هو commitment مجرد لا يمكن إغلاقه بصورة صالحة على message مختارة إلا مرة واحدة. يمكن أن يمثل Bitcoin UTXO هذا الختم؛ إذ يكون إنفاقه proof عامًا مرتبًا بالـconsensus للإغلاق، بينما لا يقيّم Bitcoin معنى البيانات الخاصة. [3]

يثبت Proof-of-Publication commitment موجزًا في ترتيب transactions العام ويجعل محاولة استخدام الختم نفسه في transitions متعارضة قابلة للكشف. لكن miners وfull nodes يتحققون من قواعد Bitcoin لا من business logic المخفية خلف hash. [2]

Client-Side Validation نموذج تصميم عام وليس مرادفًا لـRGB. يسجل سجل LNP/BP معيار LNPBP-9 بصفته informational draft، وتوفر المكتبات المرتبطة interfaces للـcommitments وserialization وsingle-use seals؛ وتحدد البروتوكولات الفعلية حالتها وقواعدها فوق ذلك. [5]

تنقل الخصوصية والتوسع واجب حفظ البيانات إلى مالكيها. إذا لم يسلّم المرسل السجل كاملًا أو فقد المستلم جزءًا مطلوبًا، فلا يستطيع blockchain العام إعادة بنائه من commitment وقد ينتهي التحقق المحلي بلا حالة قابلة للإثبات. [4]

يرى الجمهور عادة Bitcoin transaction وcommitment قصيرًا فقط، لا العقد كاملًا. يقلل ذلك البصمة العامة للبيانات لكنه لا يضمن إخفاء الهوية؛ فقد ينشئ التوقيت والأطراف وطريقة نقل البيانات وبنية anchors المعروفة metadata. [1]

يتطلب التحقق protocol الدقيق وgenesis أو schema موثوقًا وتعريف seal وcommitment scheme والسجل المترابط كاملًا وحالة Bitcoin transaction وإصدار software. وجود hash على on-chain وحده لا يثبت صلاحية asset أو قيمته أو ملكيته. [5]