233 / 691ORPH

Orphan Block

كتلة ذات أصل غير معروف؛ ويُستخدم أيضًا وصفًا ملتبسًا لكتلة في فرع جانبي

قد يشير Orphan Block إلى غياب سياق الكتلة الأصل، أو بصورة غير دقيقة إلى كتلة منافسة خارج السلسلة النشطة. يحدد هذا الفرق ما تحققت منه العقدة فعلًا وما يمكن استنتاجه من مخرجاتها.

بالمعنى الضيق، Orphan Block هي كتلة لا تعرف العقدة المراقبة كتلتها الأصل. وفي الاستعمال الأوسع تختلط بكتلة stale في فرع غير نشط؛ لذلك لا يحدد الاسم وحده صلاحيتها أو سبب الحالة.

يميّز Bitcoin Developer Guide صراحة بين Orphan Block ذات الأصل غير المعروف وStale Block في فرع منافس. قد تكون الثانية صالحة ويكون أصلها معروفًا. عند قراءة مستكشف أو تقرير مجمع تعدين، حدد أولًا المعنى الذي يستخدمه الكاتب؛ فكلمة orphan وحدها لا تحسم هذا الفرق. [Bitcoin Developer Guide — Block height and forks]

يبحث Bitcoin Core 29 عن hashPrevBlock في الفهرس داخل AcceptBlockHeader. غياب السجل يعيد prev-blk-not-found، بينما الأصل الموسوم بأنه غير صالح يؤدي إلى bad-prevblk. هاتان نتيجتان مختلفتان. الحصول على الأصل يتيح فحوصًا سياقية إضافية، لكنه لا يضمن بمفرده قبول الكتلة كاملة. [Bitcoin Core 29 — Header acceptance]

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

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

مثال توضيحي: قد تحمل كتلتان مختلفتان A وB الارتفاع 900000. لا يحدد الرقم الفائز أو هوية فريدة؛ سجّل hash وpreviousblockhash. الاختيار بين الفروع الصالحة يتبع العمل المتراكم، الموصوف في RPC باسم chainwork، لا مجرد الارتفاع. رقم المثال لا يدعي وجود تفرع تاريخي معين. [Bitcoin Developer Guide — Block height and forks] [Bitcoin Core 29 — getblock]

يعيد getblock في Bitcoin Core 29 القيمة confirmations = -1 لكتلة خارج السلسلة الرئيسية. هذه ليست عمق إعادة تنظيم سالبًا ولا دليلًا على غياب الأصل. اقرأها مع التجزئة وبيانات الفرع وحالة العقدة المحلية؛ فمخرجات عقدة واحدة لا تسرد كل ما استقبلته العقد الأخرى. [Bitcoin Core 29 — getblock]

قيمة COINBASE_MATURITY في Bitcoin Core 29 هي 100. إنها تقيد إنفاق مخرج coinbase وفق العمق بالكتل، لا وفق دقائق الانتظار. مرور الوقت أو ظهور كتل إضافية في مكان آخر لا يعيد مكافأة فرع stale خارج التاريخ النشط؛ فالنضج لا يحل محل الإدراج في السلسلة. [Bitcoin Core 29 — Coinbase maturity] [Bitcoin Developer Guide — Block height and forks]

لسجلك الخاص، اجمع getchaintips وgetblock مع تجزئة الكتلة وأصلها وحالة الفرع وإصدار العقدة ووقت المراقبة. سجّل وقت المراقبة منفصلًا عن حقل time في الترويسة. لا تثبت مخرجات واحدة هجومًا أو معدل كتل يتيمة عالميًا أو عطل شبكة محددًا؛ فذلك يحتاج ملاحظات إضافية. [Bitcoin Core 29 — getchaintips] [Bitcoin Core 29 — getblock]

للحصول على صورة أوضح، اقرأ هذا المدخل مع Stale Block, Reorg, Block propagation, Proof of Work. تشير إلى هذا المدخل أيضًا Stale Block.

DOC · 001Bitcoin Developer Guide — Block height and forksتوثيق ↗DOC · 002Bitcoin Core 29 — Header acceptanceمصدر أولي ↗DOC · 003Bitcoin Core 0.10.0 — Headers-first synchronizationمصدر أولي ↗DOC · 004Bitcoin Core 29 — getchaintipsتوثيق ↗DOC · 005Bitcoin Core 29 — getblockتوثيق ↗DOC · 006Bitcoin Core 29 — Coinbase maturityمصدر أولي ↗
المصادر أولًا · ليست نصيحة استثمارية