Initial Block Download

تشغّل في منزلك Full Node، أي برنامجاً يتحقق بنفسه من كتل Bitcoin ومعاملاته. تجمع الكتلة معاملات في دفعة تُضاف إلى السجل المشترك. لدى المشاركين الآخرين سجل طويل، أما عقدتك الجديدة فلا تعرفه بعد. تحصل أولاً على ترويسات الكتل: سجلات موجزة تربط الكتل ببعضها. وتتضمن أيضاً Proof of Work، وهو دليل على عمل حسابي أُنجز. يبحث المعدّنون عن هذا الدليل بتكرار الحسابات، بينما يستطيع الآخرون فحص النتيجة بسرعة. تشبه قائمة الترويسات فهرس كتاب: يساعدك على معرفة الطريق، لكن امتلاكه لا يعني أنك قرأت كل الصفحات وفحصتها. [1] [7]

إذا عرض الجيران فروعاً مختلفة للسجل، فلا تحسم العقدة الأمر بعدّ الأصوات. تتيح لها الترويسات مقارنة العمل الحسابي المتراكم واختيار فرع مرشح لمزيد من التحقق. زيادة عدد الكتل لا تعني بالضرورة زيادة العمل. وحتى العمل الكبير لا يعفي المعاملات غير الصالحة من القواعد؛ لا بد من فحص محتوى الفرع المختار. [1] [2] [6]

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

تقارن العقدة محتوى الكتلة ببصمة المعاملات في ترويستها، والتي تنتجها بنية Merkle Tree. وتفحص أيضاً تسلسل الإنفاق، مثلاً، وما إذا كانت مكافأة المعدّن تتجاوز المبلغ المسموح. وتطبّق القواعد التي كانت سارية عند تلك النقطة من السجل. يثبت التوقيع الرقمي الإذن بالدفع باستخدام مفتاح خاص، وهو قيمة عددية سرية، دون الكشف عن المفتاح. أما فحوص التواقيع القديمة وشروط الإنفاق الأخرى فلها إعداد خاص هو assumevalid، سنوضحه لاحقاً. الترويسات أو ملف من جار يبدو موثوقاً لا تحل محل هذه الفحوص مجتمعة. [2] [3]

مع معالجة كل كتلة، تزيل العقدة المخرجات التي أُنفقت وتضيف مخرجات جديدة. المخرج مبلغ محدد مع شروط لاستخدامه لاحقاً. وإذا لم يُنفق بعد، يسمى UTXO. وتسمح مجموعة هذه المخرجات بفحص الدفعة التالية من دون مراجعة السجل كله من البداية في كل مرة. ليست هذه قائمة حسابات مصرفية ولا نسخة من جميع المعاملات السابقة. [2] [3]

في ظروف محددة، يستطيع Bitcoin Core تجاوز فحوص سكربتات قديمة، أي فحوص التواقيع وشروط الإنفاق الأخرى. يحدد إعداد assumevalid كتلة معروفة جرى التحقق من سجلها خارجياً؛ وتهم كذلك صلتها بالكتل السابقة، والعمل الكافي، والعمق. تبقى الفحوص الضرورية الأخرى، لكن جزءاً من نتيجة التحقق يُفترض مسبقاً. لذا فالافتراض الخاطئ ليس بلا مخاطر. يعطّل assumevalid=0 هذا التحسين مقابل عمل إضافي على حاسوبك. [2]

تحذف Pruned Node ملفات الكتل القديمة بعد معالجتها، وتحتفظ بمجموعة UTXO الحالية والبيانات الضرورية الأخرى. في IBD المعتاد تظل تحصل على السجل وتعالجه، لكنها لا تحتفظ به كاملاً بصورة دائمة. هذا يوفر مساحة التخزين، وليس بالضرورة حجم التنزيل الأول. وقد تستلزم مهمة لاحقة تحتاج إلى كتل محذوفة الحصول عليها من جديد. [2] [7]

يراعي Bitcoin Core v29.0، من بين أمور أخرى، عمر أحدث كتلة مقبولة، وحداً أدنى للعمل المتراكم، وحالة التحميل. متى أصبح هذا المؤشر التشغيلي false (أي إن المزامنة الأولى انتهت)، لا يعود إلى true (أي إنها ما زالت جارية) خلال التشغيل نفسه. إنه يساعد في توجيه سلوك البرنامج، ولا يثبت عدم وجود كتلة أحدث في أي مكان. وحتى انقطاع الاتصال لاحقاً لا يجعله مؤشراً موثوقاً على حداثة الحالة. [2] [5]

الاتصال السريع مفيد، لكن الحاسوب يحتاج أيضاً إلى الحساب والكتابة على القرص. تتأثر المدة بالمعالج والذاكرة والتخزين وتوفر الجيران. في المخرجات التقنية للأمر getblockchaininfo، يقدّر verificationprogress تقدم التحقق؛ ليس وعداً بعدد الدقائق المتبقية، ولا مجرد نسبة البايتات المنزّلة. بعد إغلاق البرنامج بطريقة سليمة، يمكن عند تشغيله مجدداً متابعة التقدم المحفوظ بدلاً من البدء من الصفر كل مرة. [5] [7]

يتيح AssumeUTXO استخدام لقطة UTXO مدعومة، أي حالة محفوظة عند كتلة محددة. يقارن البرنامج محتواها ببصمة متوقعة، ويمكنه الوصول منها إلى الحاضر مبكراً بينما يعالج السجل في الخلفية. ثم يقارن أيضاً الحالة الناتجة عن ذلك التحقق التاريخي. ليست هذه قاعدة بيانات عشوائية من شخص غريب، ولا وسيلة لتجنب فحص الماضي إلى الأبد. القابلية للاستخدام مبكراً واكتمال التحقق التاريخي مرحلتان مختلفتان. [4] [8]