اقتراح الكتلة

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

المتطلبات الأساسية

اقتراح الكتلة هو جزء من بروتوكول إثبات الحصة. للمساعدة في فهم هذه الصفحة، نوصي بقراءة المزيد عن إثبات الحصة وبنية الكتلة.

من ينتج الكتل؟

تقوم حسابات المُدقِّقين باقتراح الكتل. تتم إدارة حسابات المُدقِّقين بواسطة مشغلي العقد الذين يقومون بتشغيل برمجيات المُدقِّق كجزء من عميل التنفيذ وعميل الإجماع الخاصين بهم، وقاموا بإيداع ما لا يقل عن 32 ETH في عقد الإيداع. ومع ذلك، يكون كل مُدقِّق مسؤولاً عن اقتراح بلوك في بعض الأحيان فقط. يقيس إيثريوم الوقت بالفترات (slots) والعصور (epochs). تبلغ مدة كل فترة اثنتي عشرة ثانية، وتتكون كل 32 فترة (6.4 دقيقة) من عصر واحد. كل فترة هي فرصة لإضافة بلوك جديد على إيثريوم.

الاختيار العشوائي

يتم اختيار مُدقِّق واحد بشكل شبه عشوائي لاقتراح بلوك في كل فترة. لا يوجد شيء اسمه عشوائية حقيقية في البلوك تشين لأنه إذا قامت كل عقدة بتوليد أرقام عشوائية حقيقية، فلن يتمكنوا من التوصل إلى إجماع. بدلاً من ذلك، الهدف هو جعل عملية اختيار المُدقِّق غير متوقعة. يتم تحقيق العشوائية على إيثريوم باستخدام خوارزمية تسمى RANDAO والتي تمزج التجزئة (هاش) من مقترح الكتلة مع بذرة (seed) يتم تحديثها مع كل بلوك. تُستخدم هذه القيمة لاختيار مُدقِّق معين من إجمالي مجموعة المُدقِّقين. يتم تحديد اختيار المُدقِّق مسبقًا بعصرين كطريقة للحماية من أنواع معينة من التلاعب بالبذرة.

على الرغم من أن المُدقِّقين يضيفون إلى RANDAO في كل فترة، إلا أن قيمة RANDAO العالمية يتم تحديثها مرة واحدة فقط في كل عصر. لحساب فهرس مقترح الكتلة التالي، يتم مزج قيمة RANDAO مع رقم الفترة لإعطاء قيمة فريدة في كل فترة. إن احتمالية اختيار مُدقِّق فردي ليست ببساطة 1/N (حيث N = إجمالي المُدقِّقين النشطين). بدلاً من ذلك، يتم وزنها بناءً على الرصيد الفعال من ETH لكل مُدقِّق. الحد الأقصى للرصيد الفعال هو 32 ETH (هذا يعني أن balance < 32 ETH يؤدي إلى وزن أقل من balance == 32 ETH، لكن balance > 32 ETH لا يؤدي إلى وزن أعلى من balance == 32 ETH).

يتم اختيار مقترح كتلة واحد فقط في كل فترة. في الظروف العادية، يقوم منتج كتلة واحد بإنشاء وإصدار بلوك واحد في فترته المخصصة. يعد إنشاء كتلتين لنفس الفترة مخالفة تستوجب العقوبة، وغالبًا ما تُعرف باسم "المراوغة" (equivocation).

كيف يتم إنشاء الكتلة؟

يُتوقع من مقترح الكتلة بث بلوك سلسلة المنارة موقّع يُبنى فوق أحدث رأس للسلسلة وفقًا لرؤية خوارزمية اختيار الانقسام التي يتم تشغيلها محليًا لديه. تطبق خوارزمية اختيار الانقسام أي إقرارات في قائمة الانتظار متبقية من الفترة السابقة، ثم تجد البلوك الذي يحتوي على أكبر وزن متراكم من الإقرارات في تاريخه. هذا البلوك هو الأصل (parent) للبلوك الجديد الذي أنشأه المقترح.

يقوم مقترح الكتلة بإنشاء بلوك عن طريق جمع البيانات من قاعدة بياناته المحلية ورؤيته للسلسلة. تظهر محتويات البلوك في المقتطف أدناه:

1class BeaconBlockBody(Container):
2    randao_reveal: BLSSignature
3    eth1_data: Eth1Data
4    graffiti: Bytes32
5    proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
6    attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
7    attestations: List[Attestation, MAX_ATTESTATIONS]
8    deposits: List[Deposit, MAX_DEPOSITS]
9    voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
10    sync_aggregate: SyncAggregate
11    execution_payload: ExecutionPayload
إظهار الكل

يأخذ الحقل randao_reveal قيمة عشوائية قابلة للتحقق ينشئها مقترح الكتلة عن طريق توقيع رقم العصر الحالي. eth1_data هو تصويت لرؤية مقترح الكتلة لعقد الإيداع، بما في ذلك جذر شجرة ميركل (Merkle trie) للإيداعات وإجمالي عدد الإيداعات التي تتيح التحقق من الإيداعات الجديدة. graffiti هو حقل اختياري يمكن استخدامه لإضافة رسالة إلى البلوك. proposer_slashings و attester_slashings هي حقول تحتوي على إثبات بأن مُدقِّقين معينين قد ارتكبوا مخالفات تستوجب العقوبة وفقًا لرؤية المقترح للسلسلة. deposits هي قائمة بإيداعات المُدقِّقين الجديدة التي يدركها مقترح الكتلة، و voluntary_exits هي قائمة بالمُدقِّقين الذين يرغبون في الخروج والذين سمع عنهم مقترح الكتلة على شبكة النشر (gossip network) الخاصة بطبقة الإجماع. sync_aggregate هو متجه يوضح المُدقِّقين الذين تم تعيينهم مسبقًا في لجنة المزامنة (مجموعة فرعية من المُدقِّقين الذين يقدمون بيانات العميل الخفيف) وشاركوا في توقيع البيانات.

يتيح execution_payload تمرير المعلومات حول المعاملات بين عميل التنفيذ وعميل الإجماع. execution_payload عبارة عن كتلة من بيانات التنفيذ التي يتم تداخلها داخل بلوك سلسلة المنارة. تعكس الحقول الموجودة داخل execution_payload بنية الكتلة الموضحة في الورقة الصفراء لإيثريوم، باستثناء عدم وجود كتل ommers ووجود prev_randao بدلاً من difficulty. يتمتع عميل التنفيذ بإمكانية الوصول إلى مجمع محلي من المعاملات التي سمع عنها على شبكة النشر الخاصة به. يتم تنفيذ هذه المعاملات محليًا لإنشاء شجرة حالة محدثة تُعرف باسم حالة ما بعد التنفيذ (post-state). يتم تضمين المعاملات في execution_payload كقائمة تسمى transactions ويتم توفير حالة ما بعد التنفيذ في حقل state-root.

يتم جمع كل هذه البيانات في بلوك سلسلة المنارة، وتوقيعها، وبثها إلى أقران مقترح الكتلة، الذين يقومون بنشرها إلى أقرانهم، وهكذا.

اقرأ المزيد عن تشريح الكتل.

ماذا يحدث للكتلة؟

تتم إضافة البلوك إلى قاعدة البيانات المحلية لمقترح الكتلة ويتم بثه إلى الأقران عبر شبكة النشر الخاصة بطبقة الإجماع. عندما يتلقى مُدقِّق البلوك، فإنه يتحقق من البيانات الموجودة بداخله، بما في ذلك التحقق من أن البلوك له الأصل الصحيح، ويتوافق مع الفترة الصحيحة، وأن فهرس المقترح هو المتوقع، وأن كشف RANDAO صالح وأن المقترح لم يتعرض للعقوبة. يتم فك حزمة execution_payload، ويعيد عميل التنفيذ الخاص بالمُدقِّق تنفيذ المعاملات في القائمة للتحقق من تغيير الحالة المقترح. بافتراض أن البلوك يجتاز كل هذه الفحوصات، يضيف كل مُدقِّق البلوك إلى سلسلته الأساسية (canonical chain). ثم تبدأ العملية مرة أخرى في الفترة التالية.

مكافأة الكتلة

يتلقى مقترح الكتلة مدفوعات مقابل عمله. هناك base_reward (مكافأة أساسية) تُحسب كدالة لعدد المُدقِّقين النشطين وأرصدتهم الفعالة. ثم يتلقى مقترح الكتلة جزءًا من base_reward مقابل كل إقرار صالح مدرج في البلوك؛ كلما زاد عدد المُدقِّقين الذين يقرون بالبلوك، زادت مكافأة مقترح الكتلة. هناك أيضًا مكافأة للإبلاغ عن المُدقِّقين الذين يجب معاقبتهم، وتساوي 1/512 * effective balance لكل مُدقِّق معاقب.

المزيد عن المكافآت والعقوبات