Compact Block Filters

تنتظر آنا دفعة في محفظة هاتفها. المحفظة تطبيق أو جهاز لاستقبال البيتكوين وإرساله. الكتل مجموعات من المعاملات، لكن الهاتف لا يحتاج إلى تنزيلها كلها كاملة. يستطيع أولًا فحص مرشحات صغيرة، كما يستعين القارئ بفهرس كتاب قبل فتح الصفحة المناسبة. يتلقى الجميع الملخص نفسه للكتلة ونوع المرشح نفسيهما؛ أما اختيار ما يخص آنا فيحدث داخل هاتفها. توزع الوثيقتان التقنيتان BIP 157 وBIP 158 العمل: الأولى تحدد الحصول على المرشحات وفحصها، والثانية محتواها وبناءها. تتحقق المحفظة أولًا من رؤوس الكتل، أي سجلاتها الأساسية التي تصلها في سلسلة، ثم تجلب بيانات فحص المرشحات والمرشحات نفسها. عند التطابق تنزّل الكتلة كاملة وتبحث عن المعاملة الحقيقية. أما Compact Blocks في BIP 152، رغم تشابه الاسم، فتعالج مشكلة مختلفة: نقل الكتل الجديدة بسرعة بين العقد. العقدة برنامج يتحقق من المعاملات والكتل ويتواصل مع المشاركين الآخرين في الشبكة. [1] [2] [5] [6]

تنشئ معاملة Bitcoin مخرجات، أي مبالغ مع شروط لإنفاقها لاحقًا. يسمى الكود الذي يعبّر عن هذه الشروط scriptPubKey. أما مدخل المعاملة الجديدة فيشير إلى مخرج سابق تنفقه. لذلك يشمل مرشح basic ذي المعرف 0x00 سكربتات المخرجات الجديدة وسكربتات المخرجات السابقة المنفقة داخل الكتلة. تستطيع آنا بذلك البحث عن استلام الأموال وإنفاقها. تُستبعد سكربتات المخرجات الجديدة التي تبدأ بالتعليمة OP_RETURN، التي تجعل المخرج غير قابل للإنفاق. ويُستبعد المدخل الخاص لمعاملة coinbase التي تخصص مكافأة المعدّن دون إنفاق مخرج سابق. تُحذف العناصر الفارغة ويُحسب العنصر المتكرر مرة واحدة. ليست هذه قائمة بكل معرفات المعاملات txid أو العناوين النصية أو بيانات witness مثل التوقيعات. يتطلب البناء الصحيح بيانات المخرجات السابقة المنفقة أيضًا، وليس الكتلة الجديدة وحدها. [2]

قد يرسل خادم إلى آنا ملخصًا يحذف دفعتها عمدًا. لذلك تفحص المحفظة أيضًا ارتباط المرشح بما سبقه. قيمة hash بصمة رقمية قصيرة للبيانات. يؤدي تطبيق SHA-256 مرتين على المرشح المحفوظ إلى double-SHA256 الخاص به. تُضم هذه البصمة إلى رأس المرشح السابق ويُكرر الحساب نفسه لإنتاج الرأس التالي. لذلك يغيّر تعديل مرشح قديم بيانات الفحص اللاحقة أيضًا. لكن رأس الكتلة الذي يحميه التعدين لا يحتوي على بصمة لهذه السلسلة المساعدة من المرشحات. إذا قدمت كل الخوادم المتصلة السلسلة الزائفة نفسها، فقد تتوافق بصماتها تمامًا. الاتساق الرياضي وحده لا يثبت مطابقة الملخص للكتلة الحقيقية. [1]

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

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

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

للحجم الصغير مقابل: قد يجيب المرشح «ربما نعم» مع أن العنصر غير موجود في الكتلة. هذه نتيجة إيجابية خاطئة، أو false positive. عندها تنزّل آنا كتلة بلا حاجة، لكن محفظتها لا تجد الدفعة المفترضة ولا يجوز أن تحتسبها. المرشح الصحيح لا يفوّت عنصرًا تشمله قواعده فعلًا؛ هذه الخاصية لا تجعل البيانات المختلقة من خادم مخادع موثوقة. تقنيًا يحوّل SipHash-2-4 العناصر إلى أرقام ضمن نطاق حجمه N × M، حيث N عدد العناصر. تُرتب الأرقام وتُحفظ فروقها باقتصاد بترميز Golomb-Rice. يضبط P=19 الترميز، ويؤثر M=784931 في التطابق العشوائي، واحتماله لاستعلام واحد عن عنصر خارج المجموعة يقارب 1/M. البايت وحدة شائعة لقياس حجم البيانات. مفتاح SipHash هو أول 16 بايت من بصمة الكتلة بترتيب little-endian، أي البايتات الأقل أهمية أولًا. ليس هذا مفتاح المحفظة السري. يحوّل SipHash العناصر هنا إلى أرقام للمرشح، ولا يشفّرها لإخفائها. يبدأ المرشح المحفوظ بالعدد N بصيغة CompactSize للأعداد الصحيحة غير السالبة. [2]

عند المراجعة بتاريخ 2026-10-17، تحمل الوثيقتان حالة Deployed، أي إن البروتوكول مستخدم، وليس أن كل محفظة تدعمه. يخص مثال الإعداد التالي Bitcoin Core 29.0 تحديدًا. ينشئ -blockfilterindex فهرسًا محليًا. ويتطلب توفير المرشحات للعقد الأخرى -peerblockfilters وفهرس basic؛ وتعلن العلامة NODE_COMPACT_FILTERS هذه القدرة. عبر واجهة البرمجة RPC يعيد getblockfilter الحقلين filter وheader لكتلة مختارة. لذلك لا يثبت نجاح طلب RPC وحده إتاحة المرشحات للعقد الأخرى عبر الشبكة. ولمن يقرأ المواصفة: تنقل getcfilters/cfilter المرشحات، وتنقل getcfheaders/cfheaders بيانات الترابط، وتوفر getcfcheckpt/cfcheckpt نقاط فحص السلسلة المساعدة. هذه أسماء رسائل شبكية، وليست أوامر يحتاج مستخدم محفظة الهاتف إلى كتابتها. [3] [4]