Orphan Block

تُسمّى الكتلة السابقة أحيانًا الكتلة الأم. في حالة ⁦Orphan Block⁩ الحقيقية، لا تعرفها عقدة يانا، فلا تستطيع إكمال التحقق من الترابط. أما ⁦Stale Block⁩ فقد تكون أمّها معروفة والكتلة كلها صالحة؛ لكن العقدة تتبع فرعًا آخر بوصفه التاريخ النشط. يميّز ⁦Bitcoin Developer Guide⁩ هذين المعنيين صراحةً. لذلك، حين ترى يانا ⁦orphan⁩ في مستكشف الكتل، تسأل أولًا: هل السابقة مفقودة، أم أن الكتلة لم تبقَ في السلسلة الرئيسية فحسب؟ [1]

يظهر الفرق أيضًا في ⁦Bitcoin Core⁩، وهو برنامج لتشغيل عقدة تتحقق من الكتل والمعاملات وفق قواعد ⁦Bitcoin⁩. في ⁦Bitcoin Core 29⁩ تبحث ⁦AcceptBlockHeader⁩ عن السابقة عبر ⁦hashPrevBlock⁩، الإشارة إلى بصمتها المعرّفة. إذا لم يوجد سجل في الفهرس، تعيد ⁦prev-blk-not-found⁩. وإذا كانت الكتلة الأم معروفة وموسومة بأنها غير صالحة، تكون النتيجة ⁦bad-prevblk⁩. تعني الأولى «ينقصني السياق»، والثانية «أنت تبني على كتلة غير صالحة». إحضار السابقة المفقودة يتيح فحوصًا أخرى، لكنه لا يضمن وحده قبول الكتلة كاملةً. [2]

للكتلة ترويسة، أي مجموعة قصيرة من معلومات الهوية والارتباط، وجسم يحتوي المعاملات. أدخل ⁦Bitcoin Core 0.10.0⁩ مزامنة ⁦headers-first⁩: تُجلب الترويسات وتُفحص أولًا، ثم يمكن تنزيل الكتل بالتوازي. لذا قد تعرف عقدة يانا ترويسة السابقة من دون أن تكون الكتلة كاملةً على القرص. غياب جسم الكتلة ليس هو جهل سابقتها؛ والخلط بينهما قد يجعل تنزيلًا عاديًا يبدو لغزًا. [3]

يساعد الأمر ⁦getchaintips⁩ في ⁦Bitcoin Core 29⁩ يانا على معرفة نهايات الفروع التي تعرفها عقدتها. تشير ⁦active⁩ إلى السلسلة النشطة، و⁦valid-fork⁩ إلى فرع غير نشط جرى التحقق منه بالكامل. تعني ⁦valid-headers⁩ أن الكتل متاحة لكنها لم تخضع للتحقق الكامل، بينما تعني ⁦headers-only⁩ أن بعض الكتل غير متاحة. وتشير ⁦invalid⁩ إلى فرع يحتوي كتلة غير صالحة. هذه إذن ليست قائمة بنتائج تعاني المشكلة نفسها. وحتى عبارة ⁦orphaned branches⁩ في المساعدة لا تلغي هذه الفروق. [4]

لنتخيل كتلتين مختلفتين ⁦A⁩ و⁦B⁩ عند الارتفاع ⁦900000⁩. هذا مثال توضيحي من عندنا، لا وصف لواقعة محددة. الارتفاع موضع في السلسلة، ولذلك يمكن لكتل متنافسة أن تشترك فيه. تميّز يانا بينها بواسطة ⁦hash⁩، بصمة تعريف الكتلة، و⁦previousblockhash⁩، الإشارة إلى سابقتها. عند الاختيار بين فروع صالحة، يحسم العمل التراكمي الأمر، لا الارتفاع وحده. وتعرضه واجهة ⁦RPC⁩، التي تُرسل عبرها أوامر إلى البرنامج، باسم ⁦chainwork⁩: مجموع العمل المتوقع الموافق لصعوبات الكتل. [1] [5]

حين تستعلم يانا بواسطة ⁦getblock⁩ عن كتلة خارج السلسلة الرئيسية، قد يعرض ⁦Bitcoin Core 29⁩ القيمة ⁦confirmations = -1⁩. إنها علامة حالة خاصة، وليست عددًا عاديًا من التأكيدات. ليست عدًا تنازليًا ولا عمقًا سالبًا لإعادة تنظيم السلسلة. ولا تثبت غياب السابقة أيضًا. يجب قراءة القيمة مع هوية الكتلة وحالة الفرع؛ كما أن عقدة يانا قد لا تملك كل كتلة سبق أن شاهدها المشاركون الآخرون. [5]

تنشأ مكافأة الكتلة من معاملة أولى خاصة تسمّى ⁦coinbase⁩، ولا علاقة لها بمنصة التداول التي تحمل الاسم نفسه. يسجّل مخرج المعاملة مبلغًا من بيتكوين والشروط التي يجب استيفاؤها لإنفاقه. في ⁦Bitcoin Core 29⁩ تساوي ⁦COINBASE_MATURITY⁩ قيمة ⁦100⁩: يمكن إنفاق مخرج أُنشئ عند الارتفاع ⁦H⁩ لأول مرة في كتلة صالحة عند ⁦H+100⁩. المهم فرق الارتفاع، لا الدقائق المنقضية. لكن شرط الانتظار هذا لا يعوّض الانضمام إلى السلسلة النشطة. ما دامت كتلة المكافأة على فرع غير نشط، فمخرجها غير موجود في مجموعة ⁦UTXO⁩ النشطة، أي سجل المخرجات غير المنفقة. ولا تعيد الكتل الإضافية في موضع آخر ذلك المال تلقائيًا. [6] [7] [1] [8]

تحفظ يانا ⁦hash⁩ الكتلة وسابقتها وحالة الفرع وإصدار البرنامج. وتضيف ردود ⁦getchaintips⁩ و⁦getblock⁩ ووقت الحصول عليها. تسجّل هذا الوقت منفصلًا عن حقل ⁦time⁩ في الترويسة: الطابع الزمني للكتلة ليس لحظة مشاهدة حاسوبها لها. يساعد السجل على مقارنة ملاحظات أخرى، لكنه لا يثبت وحده هجومًا أو عطلًا محددًا في الشبكة أو نسبة عالمية لكتل ⁦orphan⁩. فهو يصف أولًا حالة عقدة واحدة في لحظة معينة. [4] [5]