---
title: "قواعد اختيار الفرع: الفروع الصالحة والوزن والرأس القانوني"
description: "تربط قاعدة اختيار الفرع بين العرض المحلي المتحقق منه لدى العقدة والرأس القانوني الحالي. يجب تحليل صلاحية المرشحين والنسب والعمل التراكمي أو وزن التصويت ونقاط التحقق والتوقيت وكسر التعادل وآثار إعادة التنظيم والنهائية كل على حدة."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# قواعد اختيار الفرع: الفروع الصالحة والوزن والرأس القانوني

> لأغراض تعليمية فقط؛ لا يشكل ذلك نصيحة استثمارية أو توصية استثمارية. قد تؤدي الاستثمارات إلى خسائر.

<a id="answer"></a>

## الإجابة المباشرة

قاعدة اختيار الفرع هي إجراء البروتوكول الذي يحوّل العرض المحلي المتحقق منه لدى العقدة للكتل ورسائل الإجماع المتنافسة إلى رأس قانوني حالي. ناتجها مؤقت ونسبي إلى المراقب: قد تختار عقدتان صادقتان رأسين مختلفين لفترة وجيزة لأنهما استلمتا كتلًا أو أصواتًا أو أحداث توقيت صالحة مختلفة. وعندما تتقارب عروضهما المقبولة ضمن افتراضات شبكة البروتوكول، يفترض أن تتقارب القاعدة أيضًا.

لا يجعل اختيار الفرع الكتلة غير الصالحة صالحة. تحدد فحوص انتقال الحالة والتفويض والإثبات والنسب وتوافر البيانات المرشحين المقبولين قبل مقارنة أوزانهم. كما أن الرأس المختار ليس نهائيًا بالضرورة. يحدد اختيار الفرع ما يجب تمديده الآن، بينما قد تحمي قاعدة نهائية سلفًا أقدم بدليل أمان أقوى. يمكن أن يكون استبدال الرأس الحالي تشغيلًا عاديًا، أما استبدال نقطة تحقق نهائية فيتجاوز حدًا مختلفًا في البروتوكول.

ليست «أطول سلسلة» معادلة عامة. تختار Bitcoin سلسلة صالحة ذات أكبر عمل: العمل المتوقع التراكمي لإثبات العمل، لا الارتفاع الخام، هو الحاسم. يبدأ LMD-GHOST في Ethereum من نقطة تحقق مبررة، ويرشح الفروع القابلة للحياة، ثم يتبع بصورة جشعة الابن ذي أكبر رصيد تصديق لأحدث الرسائل مع أي تعزيز مطبق للمقترح؛ ولا تسهم إلا أحدث رسالة مؤهلة من كل مدقق. وقد تستخدم بروتوكولات أخرى شهادات توافر أو أقفال القائد أو الجولات أو شهادات commit صريحة بدل منافسة دائمة بين أثقل الفروع.

تعتمد النتيجة على مدخلات دقيقة: السلسلة والشبكة، وإصدار الانقسام، والمرساة الموثوقة، والوقت أو الخانة الحالية، والكتل الصالحة المعروفة، وروابط الأصل، ولقطة العمل أو وزن التصويت، وأحدث الرسائل، وأدلة التصويت المتناقض، ونقاط التحقق المبررة والنهائية، وحالة التوافر، وتوقيت المقترح، وقواعد كسر التعادل الحتمية. شارة مستكشف الكتل أو نتيجة RPC واحدة هي ملاحظة لناتج عقدة واحدة، وليست القاعدة ولا دليلًا مستقلًا على مدخلاتها.

<a id="mechanism"></a>

## كيفية تحليل قاعدة اختيار الفرع

1. **ثبّت الهوية والإصدار.** سجل السلسلة والشبكة وانقسام الإجماع وإصدار العميل وكتلة genesis أو المرساة الموثوقة والارتفاع أو الخانة الحالية والقاعدة الدقيقة النشطة. لا تنقل منطق mainnet إلى testnet أو sidechain أو rollup أو مقترح مستقبلي.
2. **ابن رسم الكتل المقبولة.** تحقق من التجزئات والآباء وإثباتات الإجماع وانتقالات الحالة وحالة execution payload وتوافر البيانات المطلوب. علّم العقد المجهولة والمتفائلة وغير الصالحة والمشذبة صراحة؛ فالوزن لا ينقذ فرعًا غير صالح.
3. **أعد بناء النسب والقيود.** اعثر على السلف المشترك وتأكد من المرشحين المنحدرين من نقاط التحقق أو الأقفال أو الشهادات المطلوبة. افصل الشجرة الخام المرصودة عن الشجرة المرشحة التي يمكن للقاعدة النظر فيها فعلًا.
4. **أعد إنتاج كل مدخل للوزن.** في PoW فك ترميز الأهداف واجمع إثبات كل كتلة في عمل تراكمي. وفي قواعد التصويت تحقق من هوية المدقق ورصيده الفعال النشط أو أي وزن آخر ونطاق الرسالة والجذر المستهدف والخانة أو الحقبة واستبدال أحدث رسالة ومعالجة التصويت المتناقض وأي تعزيز مؤقت.
5. **نفّذ الاختيار وكسر التعادل بدقة.** طبق الاستدعاء التكراري أو المقارن المحدد عند كل تفرع، مستخدمًا تقريب البروتوكول وترتيبه الحتمي. سجل ما إذا كان تساوي الوزن يسمح بتفضيل محلي مؤقت بدل اعتباره اتفاقًا نهائيًا.
6. **سوّ تغييرات الرأس.** عند تغير الفائز، حدد الكتل المفصولة والمرفقة، وتراجع عن الحالة ثم أعد تشغيلها، وسوّ الإيصالات والسجلات وmempool، واحسب عمق إعادة التنظيم من السلف المشترك. أبق تسميات head وsafe وjustified وcommitted وfinalized منفصلة.
7. **اختبر النظام المنشور تحت الضغط وراقبه.** اختبر الكتل المتأخرة أو المحجوبة، والانقسامات، والأصوات القديمة، والتصويت المتناقض، والموازنة، وتوقيت المقترح، واختلاف العملاء، ونقاط التحقق الضعيفة، والبيانات غير المتاحة. قارن عقدًا مستقلة وأنذر عند تباعد غير متوقع للرؤوس أو إعادة تنظيم عميقة أو تعارض مع الحالة النهائية قبل أي إجراء لاحق غير قابل للعكس.

في Bitcoin Core الحالي، يقارن ترتيب المرشحين أولًا `nChainWork`؛ ثم يرتب المرشحين متساويي العمل وفق أسبق تسلسل قابل للتنشيط، مع كسر تعادل داخلي احتياطي. يمثل حقل RPC المسمى `blocks` ارتفاع سلسلة أكبر عمل التي تم التحقق منها بالكامل، بينما يحدد `bestblockhash` قمتها. وفي مواصفات اختيار الفرع الحالية لـ Ethereum، تبدأ `get_head(store)` من `justified_checkpoint`، وتجتاز شجرة مرشحة، وتختار عند كل خطوة الابن الذي يعظم `(get_weight(store, child), child.root)`. هذه تفاصيل خاصة بالبروتوكول والإصدار، وليست تعريفات عامة للإجماع.

<a id="example"></a>

## أمثلة محلولة

### 1. التحول وفق العمل التراكمي في Bitcoin

يشترك فرعان صالحان في السلف `C`. للرأسين الحاليين `chainwork(A)=240` و`chainwork(B)=235`، لذلك تختار العقدة `A` حتى إن جعل عرض الارتفاع البسيط الفرعين متشابهين. تضيف كتلة صالحة جديدة عملًا قدره `10` إلى الفرع B:

`chainwork(B') = 235 + 10 = 245`

لأن `245 > 240` يصبح B مرشح أكبر عمل. تفصل العقدة كتل A بعد `C`، وتصل B عبر `B'`، وتسوي المعاملات. لا يكفي العدد الخام للكتل عندما تختلف أهداف كل كتلة، كما أن تساوي العمل حالة مؤقتة لكسر التعادل وليس دليلًا على النهائية.

### 2. الاختيار الجشع لأثقل شجرة فرعية مرصودة

استخدم شجرة LMD-GHOST مبسطة جذرها نقطة التحقق المبررة `J`. ابناها هما `A` و`B`. تمنح أحدث رسائل المدققين المؤهلة شجرة A الفرعية كلها وزنًا `61` وشجرة B الفرعية وزنًا `39`، فتختار الخطوة الجشعة الأولى `A`. ولدى A ابنان هما `A_1` و`A_2` بوزني شجرة فرعية `34` و`27`؛ فتختار الخطوة التالية `A_1`.

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

### 3. استبدال أحدث رسالة

افترض أن أحدث الرسائل المؤهلة تمنح الفرع A في البداية وزنًا `55` والفرع B وزنًا `45`. ثم يرسل مدقق وزنه `20` رسالة أحدث مؤهلة تؤيد أحد أحفاد B. تزيل محاسبة أحدث رسالة دعم ذلك المدقق القديم من A وتضيفه إلى B:

`A: 55 - 20 = 35; B: 45 + 20 = 65`

يُحسب الوزن مرة واحدة، لا على الفرعين، ولذلك قد يتغير المسار المختار. هذا لا يجيز التصويت المتناقض: فإذا أثبت دليل attester slashing صالح تناقضًا، يتتبع مخزن Ethereum الحالي المدقق المتناقض ويستبعد وزنه من حساب التصديقات العادي.

### 4. ترشيح نقطة التحقق وتعزيز المقترح

افترض أن عقدة ترصد وزن أحدث رسالة خامًا قدره `70` على فرع يتعارض مع نقطة تحققها النهائية ووزنًا `30` على أحد الأحفاد القابلين للحياة. يستبعد الفرع المتعارض قبل اختيار الرأس؛ ولا تستطيع أغلبية الوزن الخام تجاوز قيد نقطة التحقق النهائية عبر اختيار الفرع العادي.

انظر الآن إلى ابنين قابلين للحياة في الخانة الحالية بوزني تصديق `35` و`50`. في إعداد Ethereum المشار إليه، يساوي تعزيز المقترح في وقته `40%` من وزن لجنة واحدة، لا 40 بالمئة من إجمالي الحصة. إذا كان وزن اللجنة `100` وطُبق التعزيز على الابن ذي الوزن 35، تصبح درجته للمقارنة `35 + 40 = 75`، فيتغلب على `50` في تلك الخطوة. التعزيز مؤقت وخاص بالانقسام؛ وليس صوت مدقق إضافيًا ولا نهائية.

<a id="risks"></a>

## المخاطر وإخفاقات المراجعة

### مجموعة المرشحين والأدلة

- مقارنة وزن الفروع قبل التحقق من الآباء وانتقالات الحالة والإثباتات وحالة payload أو البيانات المطلوبة.
- معاملة التنفيذ المجهول أو المتفائل أو البيانات غير المتاحة أو عرض الرؤوس فقط كحالة متحقق منها بالكامل.
- استخدام ارتفاع الكتلة أو الطابع الزمني أو عدد المعاملات أو الرسوم أو شهرة المستكشف بدل الوزن المحدد.
- جمع الصعوبة المعروضة بدل إعادة إنتاج إثبات كل كتلة والعمل التراكمي تحت الأهداف الصحيحة.
- احتساب كل الأصوات التاريخية بدل أحدث رسالة مؤهلة لكل مدقق وفق لقطة الوزن الصحيحة.
- تجاهل نطاق الرسالة وجذرها وخانتها وحقبتها وتوقيتها وتوقيعها وأدلة التصويت المتناقض وslashing.
- مقارنة فروع خام يجعلها مرشح نقطة التحقق أو القفل أو الشهادة أو التوافر في البروتوكول غير مؤهلة.
- تطبيق مواصفات مستقبلية أو معلمة شبكة أخرى أو تحسين تنفيذي بوصفه قانون الإجماع الحالي.

### الاختيار والإخفاق التشغيلي

- وصف قاعدة Bitcoin بأنها «أطول ارتفاع» خام أو قاعدة Ethereum بأنها تصويت بسيط للرأس بأغلبية الثلثين.
- استبدال الاستدعاء الجشع للشجرة الفرعية بدرجة عامة للأوراق، أو إغفال تعزيز المقترح والتقريب وكسر التعادل بالجذر.
- افتراض أن العقد ذات ترتيب الوصول أو الساعات أو عروض الرسائل المختلفة يجب أن تبلغ الرأس نفسه فورًا.
- الإخفاق في فصل الحالة والإيصالات والسجلات والفهارس ومدخلات mempool وإعادة تشغيلها صحيحًا أثناء إعادة التنظيم.
- السماح لتنفيذات العملاء بالاختلاف بشأن الصلاحية وقابلية نقاط التحقق للحياة وأحدث الرسائل والتوقيت وكسر التعادل.
- إغفال حالات الموازنة والحجب والتصويت المتناقض والانقسام وeclipse وتأخر التصويت وإعادة تنظيم المقترح.
- الوثوق في RPC واحد أو مستكشف أو relay أو عائلة عملاء أو سحابة أو مشغل مدققين بوصفه عرضًا مستقلًا للإجماع.

### النهائية وعدم تطابق التطبيق

- وصف الرأس المختار بأنه نهائي أو غير قابل للعكس أو آمن دون دليل النهائية المنفصل للبروتوكول.
- تحرير الودائع أو رسائل الجسور أو الصفقات غير القابلة للعكس على رأس مؤقت من دون سياسة تراعي القيمة.
- افتراض أن سلفًا نهائيًا يضمن صحة أو توافر كل رأس أو payload أو oracle أو نتيجة تطبيق أحدث.
- استخدام عدد ثابت من التأكيدات عبر سلاسل تختلف نماذج العمل والتصويت ونقاط التحقق والاسترداد فيها.
- معاملة نقاط التحقق الطارئة أو مراسي weak subjectivity أو social recovery كمدخلات عادية لاختيار الفرع بلا حدود ثقة.

<a id="misconceptions"></a>

## مفاهيم خاطئة شائعة

- **يفوز أطول فرع دائمًا.** قد يقارن البروتوكول العمل التراكمي أو أحدث الرسائل الموزونة أو الشهادات أو درجة أخرى؛ الارتفاع الخام ليس قاعدة عامة.
- **أثقل فرع مرصود صالح تلقائيًا.** ترشح الصلاحية والتوافر المرشحين قبل أن يختار الوزن بينهم.
- **اختيار الفرع والنهائية قاعدة واحدة.** يختار الأول الرأس الحالي للتمديد، وتحمي الثانية سلفًا وفق شروط أمان إضافية.
- **يبقى كل صوت للمدقق في المجموع إلى الأبد.** في قواعد أحدث رسالة، تحل رسالة مؤهلة أحدث محل دعم المدقق السابق لاختيار الفرع.
- **يثبت مستكشف واحد السلسلة القانونية.** إنه يبلغ عرض حزمة بنية تحتية واحدة؛ ولا يزال التحقق والتسوية المستقلان ضروريين.

<a id="related"></a>

## موضوعات ذات صلة

- [إعادة تنظيم السلسلة](/ar/crypto/chain-reorg/)
- [آليات الإجماع](/ar/crypto/consensus-mechanism/)
- [تعديل الصعوبة](/ar/crypto/difficulty-adjustment/)
- [النهائية](/ar/crypto/finality/)
- [الذاتية الضعيفة](/ar/crypto/weak-subjectivity/)

<a id="sources"></a>

## المصادر

- [Blockchain Technology Overview](https://doi.org/10.6028/NIST.IR.8202) - NIST (تاريخ الاطلاع: 2026-08-19)
- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (تاريخ الاطلاع: 2026-08-19)
- [Bitcoin Core: validation.h](https://github.com/bitcoin/bitcoin/blob/master/src/validation.h) - Bitcoin Core (تاريخ الاطلاع: 2026-08-19)
- [Bitcoin Core: blockstorage.cpp](https://github.com/bitcoin/bitcoin/blob/master/src/node/blockstorage.cpp) - Bitcoin Core (تاريخ الاطلاع: 2026-08-19)
- [Bitcoin Core RPC: getblockchaininfo](https://developer.bitcoin.org/reference/rpc/getblockchaininfo.html) - Bitcoin Project (تاريخ الاطلاع: 2026-08-19)
- [Ethereum Gasper](https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/) - Ethereum.org (تاريخ الاطلاع: 2026-08-19)
- [Ethereum Consensus Specifications: Fork Choice](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/fork-choice.md) - Ethereum Foundation (تاريخ الاطلاع: 2026-08-19)
- [CometBFT Byzantine Consensus Algorithm](https://docs.cometbft.com/v0.38/spec/consensus/consensus) - CometBFT (تاريخ الاطلاع: 2026-08-19)

Source: https://wiki.fcontext.com/ar/crypto/fork-choice-rule/index.mdx