Compact Block Filters

تفتح آنا محفظة هاتفها بعد انقطاع. يحتاج التطبيق إلى معرفة ما إذا كان أحد قد دفع لها منذ الاتصال الأخير أو أُنفِق بعض أموالها. وبدلًا من تنزيل جميع المعاملات، ينزل مرشحات صغيرة ويقارنها بشروط المخرجات التي يتابعها. والمخرج جزء من المعاملة يحدد مبلغًا وشروط إنفاقه لاحقًا. عند التطابق يطلب التطبيق الكتلة كاملة ويبحث عن المعاملة الفعلية. ولا ينبغي زيادة الرصيد اعتمادًا على تطابق المرشح وحده. فالمرشح ليس كشف حساب ولا دليل ملكية. وقبل البحث يزامن العميل ترويسات الكتل، أي بياناتها التعريفية الموجزة، وترويسات المرشحات المترابطة. [1]

في النهج الأقدم BIP 37، كان العميل يرسل إلى عقدة متصلة به مرشحًا مبنيًا على البيانات التي يريد متابعتها. هنا ينعكس الاتجاه: يقدم الخادم مرشح الكتلة وتبحث آنا محليًا. ويحصل العملاء على المحتوى نفسه للكتلة ونوع المرشح نفسيهما، فلا يلزم كشف السكربتات المطلوبة مباشرة لكل خادم. لكن هذا لا يحقق إخفاء الهوية: فقد يرى الطرف الآخر عنوان IP وتوقيت الاتصال والكتل الكاملة التي تطلبها المحفظة لاحقًا. توزيع التنزيلات بين أطراف مختلفة يقلل المعلومات المتجمعة لدى طرف واحد، لكنه لا يلغي كل طرق الربط بينها. [1]

تختار Compact Block Filters الكتل الجديرة بالفحص. أما Compact Blocks وفق BIP 152 فتحل مشكلة أخرى: تقليل بيانات نقل الكتلة باستخدام معرّفات قصيرة لمعاملات يعرفها المستقبِل غالبًا. ويستخرجها من Mempool، مجموعته المحلية للمعاملات غير المؤكدة، ثم يطلب الناقص منها. لا تتحقق أي من الأداتين وحدها من جميع قواعد Bitcoin. أما Full Node، أي العقدة الكاملة، فتتحقق مستقلّة من الكتل والمعاملات وفق قواعد الشبكة. والمحفظة الخفيفة التي تفحص الترويسات وإدراج معاملتها فقط تجري فحصًا أضيق. توفير البيانات والتحقق الكامل خاصيتان مختلفتان. [1] [5]

يحدد BIP 158 التنسيق. يتضمن مرشح basic سكربت scriptPubKey الذي يحدد شروط الإنفاق للمخرجات الجديدة، باستثناء ما يبدأ بـ OP_RETURN. ويشمل أيضًا سكربتات المخرجات السابقة التي تُنفق داخل الكتلة. وفيما يتعلق بالمدخلات، فالاستثناء هو coinbase، أول معاملة في الكتلة لتوزيع مكافأة المعدّن، إذ لا تنفق مخرجات سابقة عادية. أما مخرجاتها الجديدة فتخضع لقواعد الإدراج نفسها المطبقة على بقية المخرجات الجديدة. وتُحذف العناصر الفارغة. يجب أن تحول المحفظة العنوان إلى السكربت الصحيح؛ فلا يكفي البحث عن نصه المطبوع. وليس المرشح محرك بحث عام لمعرّفات المعاملات txid أو بيانات witness مثل التوقيعات أو الملاحظات الاعتباطية. [2] [3]

قد تنزل آنا كتلة ثم تجد أن لا شيء فيها يخصها. هذا التطابق الكاذب مقايضة معتادة للحصول على مرشح صغير، وليس وحده دليل خلل. تقنيًا تُحوّل العناصر إلى بصمات عددية، وتُرتب، ثم تُحفظ الفروق بترميز Golomb-Rice المقتصد. ولنوع basic تكون القيم P=19 وM=784931. احتمال تطابق استعلام واحد عن عنصر غير موجود يقارب 1/M؛ وكلما زادت العناصر المتابعة زادت فرص التطابق. ليست هذه نسبة خطأ ثابتة للمحفظة كلها. والمرشح المبني بصورة صحيحة لا يفوّت عنصرًا مشمولًا. لكن النتيجة السلبية موثوقة فقط مع مرشح صحيح ونوع بيانات مشمول واستعلام صحيح. [2]

يحدد BIP 157 نقل المرشحات وترويساتها المترابطة. تصل كل ترويسة بين hash، أي البصمة التشفيرية للمرشح الحالي، والترويسة السابقة. وتغيير المرشح يكسر الرابط المتوقع. لكن هذه السلسلة ليست جزءًا من ترويسة كتلة Bitcoin، ولا يثبت التعدين محتواها مباشرة. يستطيع طرف غير أمين إعداد مرشحات زائفة مع بصمات مترابطة محسوبة بصورة صحيحة. هو لا يغير Bitcoin، لكنه قد يخفي معلومات عن عميل معزول. لذا يجب أن يصاحب فحص الترابط الحسابي التحقق من صحة البيانات نفسها. [1]

يعتمد BIP 157 على مقارنة أطراف متعددة مع وجود مصدر أمين واحد على الأقل. وعند اختلافها يستطيع العميل تحديد أول نقطة خلاف وفحص المرشح مقابل البيانات الأصلية. وقد لا تكفي الكتلة الجديدة وحدها لبناء basic؛ إذ تلزم أيضًا سكربتات المخرجات السابقة التي تنفقها معاملاتها. وتحتاج إعادة التنظيم إلى معالجة خاصة: تنتقل الشبكة إلى فرع آخر من كتل صالحة له عمل تراكمي أكبر. يجب أن تربط المحفظة المرشحات بالفرع الجديد وتحدّث السجل والرصيد. فالارتفاع نفسه، أي الموضع نفسه في السلسلة، لا يعني بالضرورة الكتلة نفسها. [1] [3]

تحتاج المحفظة إلى مرشحات متاحة وطريقة للحصول على الكتل الكاملة المختارة. قد تحذف عقدة كتلًا قديمة بعد إنشاء مرشحاتها، وعندئذ يلزم مصدر آخر لتوفيرها. في Bitcoin Core يعيد getblockfilter مرشح كتلة محددة وترويسته عند تفعيل الفهرس المناسب. وتوافر الأمر لا يثبت وجود خدمة P2P عامة للعقد الأخرى أو إتاحة التاريخ كاملًا. كما أن مرشحات الكتل الموجودة لا تعلن المعاملات غير المؤكدة في Mempool. ولإظهار دفعة قيد الانتظار يحتاج التطبيق إلى آلية أخرى. هذه التفاصيل التشغيلية تحدد هل تعمل المحفظة الخفيفة جيدًا فعلًا. [1] [4]