اقتراح الكتلة
الكتل هي الوحدات الأساسية في سلسلة الكتل. الكتل هي وحدات منفصلة من المعلومات يتم تمريرها بين العقد، ويتم الإجماع عليها وإضافتها إلى قاعدة بيانات كل عقدة. تشرح هذه الصفحة كيفية إنتاجها.
المتطلبات الأساسية
اقتراح الكتلة هو جزء من بروتوكول إثبات الحصة (PoS). للمساعدة في فهم هذه الصفحة، نوصي بقراءة إثبات الحصة (PoS) وبنية الكتلة.
من ينتج الكتل؟
تقترح حسابات المُدَقِّقين الكتل. تُدار حسابات المُدَقِّقين بواسطة مشغلي العقد الذين يقومون بتشغيل برمجيات المُدَقِّق كجزء من عملاء التنفيذ وطبقة الإجماع الخاصة بهم، وقد أودعوا ما لا يقل عن 32 ETH في عقد الإيداع. ومع ذلك، يكون كل مُدَقِّق مسؤولاً عن اقتراح كتلة في بعض الأحيان فقط. تقيس إيثيريوم الوقت بالخانات والحقب. كل خانة تبلغ اثنتي عشرة ثانية، وتتكون الحقبة من 32 خانة (6.4 دقائق). كل خانة هي فرصة لإضافة كتلة جديدة على إيثيريوم.
الاختيار العشوائي
يتم اختيار مُدَقِّق واحد بشكل شبه عشوائي لاقتراح كتلة في كل خانة. لا يوجد شيء اسمه عشوائية حقيقية في سلسلة الكتل لأنه إذا قامت كل عقدة بتوليد أرقام عشوائية حقيقية، فلن تتمكن من التوصل إلى إجماع. بدلاً من ذلك، الهدف هو جعل عملية اختيار المُدَقِّق غير قابلة للتنبؤ. يتم تحقيق العشوائية على إيثيريوم باستخدام خوارزمية تسمى RANDAO والتي تمزج تجزئة من مقترح الكتلة مع بذرة يتم تحديثها مع كل كتلة. تُستخدم هذه القيمة لاختيار مُدَقِّق معين من إجمالي مجموعة المُدَقِّقين. يتم تحديد اختيار المُدَقِّق مسبقًا بحقبتين كطريقة للحماية من أنواع معينة من التلاعب بالبذرة.
على الرغم من أن المُدَقِّقين يضيفون إلى RANDAO في كل خانة، إلا أن قيمة RANDAO العالمية يتم تحديثها مرة واحدة فقط لكل حقبة. لحساب مؤشر مقترح الكتلة التالي، يتم مزج قيمة RANDAO مع رقم الخانة لإعطاء قيمة فريدة في كل خانة. احتمالية اختيار مُدَقِّق فردي ليست ببساطة 1/N (حيث N = إجمالي المُدَقِّقين النشطين). بدلاً من ذلك، يتم ترجيحها بناءً على رصيد ETH الفعال لكل مُدَقِّق. الحد الأقصى للرصيد الفعال هو 32 ETH (هذا يعني أن balance < 32 ETH يؤدي إلى وزن أقل من balance == 32 ETH، لكن balance > 32 ETH لا يؤدي إلى وزن أعلى من balance == 32 ETH).
يتم اختيار مقترح كتلة واحد فقط في كل خانة. في الظروف العادية، يقوم منتج كتلة واحد بإنشاء وإصدار كتلة واحدة في الخانة المخصصة له. إنشاء كتلتين لنفس الخانة هو مخالفة تستوجب الاقتطاع، وتُعرف غالبًا باسم "المراوغة".
كيف يتم إنشاء الكتلة؟
يُتوقع من مقترح الكتلة بث كتلة المنارة الموقعة التي تُبنى فوق أحدث رأس للسلسلة وفقًا لرؤية خوارزمية اختيار التفرع التي يتم تشغيلها محليًا لديه. تُطبق خوارزمية اختيار التفرع أي تصديقات في قائمة الانتظار متبقية من الخانة السابقة، ثم تعثر على الكتلة ذات الوزن المتراكم الأكبر من التصديقات في تاريخها. تلك الكتلة هي الأصل للكتلة الجديدة التي أنشأها المُقترِح.
يقوم مقترح الكتلة بإنشاء كتلة عن طريق جمع البيانات من قاعدة بياناته المحلية ورؤيته للسلسلة. تظهر محتويات الكتلة في المقتطف أدناه:
class BeaconBlockBody(Container):
randao_reveal: BLSSignature
eth1_data: Eth1Data
graffiti: Bytes32
proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
attestations: List[Attestation, MAX_ATTESTATIONS]
deposits: List[Deposit, MAX_DEPOSITS]
voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
sync_aggregate: SyncAggregate
execution_payload: ExecutionPayload
يأخذ الحقل randao_reveal قيمة عشوائية قابلة للتحقق ينشئها مقترح الكتلة عن طريق توقيع رقم الحقبة الحالي. eth1_data هو صوت لرؤية مقترح الكتلة لعقد الإيداع، بما في ذلك جذر شجرة ميركل للإيداع وإجمالي عدد الإيداعات التي تتيح التحقق من الإيداعات الجديدة. graffiti هو حقل اختياري يمكن استخدامه لإضافة رسالة إلى الكتلة. proposer_slashings وattester_slashings هما حقلان يحتويان على إثبات بأن مُدَقِّقين معينين قد ارتكبوا مخالفات تستوجب الاقتطاع وفقًا لرؤية المُقترِح للسلسلة. deposits هي قائمة بإيداعات المُدَقِّقين الجديدة التي يدركها مقترح الكتلة، وvoluntary_exits هي قائمة بالمُدَقِّقين الذين يرغبون في الخروج والذين سمع عنهم مقترح الكتلة على شبكة القيل والقال لطبقة الإجماع. sync_aggregate هو متجه يوضح المُدَقِّقين الذين تم تعيينهم مسبقًا في لجنة المزامنة (مجموعة فرعية من المُدَقِّقين الذين يخدمون بيانات العميل الخفيف) وشاركوا في توقيع البيانات.
يُمكّن execution_payload من تمرير المعلومات حول المعاملات بين عميل التنفيذ وعميل الإجماع. execution_payload هي كتلة من بيانات التنفيذ التي يتم تداخلها داخل كتلة المنارة. تعكس الحقول داخل execution_payload بنية الكتلة الموضحة في الورقة الصفراء لإيثيريوم، باستثناء أنه لا توجد كتل ommers ويوجد prev_randao بدلاً من difficulty. يتمتع عميل التنفيذ بإمكانية الوصول إلى مجمع محلي من المعاملات التي سمع عنها على شبكة القيل والقال الخاصة به. يتم تنفيذ هذه المعاملات محليًا لإنشاء شجرة حالة محدثة تُعرف باسم حالة ما بعد التنفيذ. يتم تضمين المعاملات في execution_payload كقائمة تسمى transactions ويتم توفير حالة ما بعد التنفيذ في الحقل state-root.
يتم جمع كل هذه البيانات في كتلة المنارة، وتوقيعها، وبثها إلى أقران مقترح الكتلة، الذين ينشرونها إلى أقرانهم، وهكذا.
اقرأ المزيد عن تشريح الكتل.
ماذا يحدث للكتلة؟
تتم إضافة الكتلة إلى قاعدة البيانات المحلية لمقترح الكتلة ويتم بثها إلى الأقران عبر شبكة القيل والقال لطبقة الإجماع. عندما يتلقى المُدَقِّق الكتلة، فإنه يتحقق من البيانات الموجودة بداخلها، بما في ذلك التحقق من أن الكتلة لها الأصل الصحيح، وتتوافق مع الخانة الصحيحة، وأن مؤشر المُقترِح هو المؤشر المتوقع، وأن كشف RANDAO صالح وأن المُقترِح لم يتعرض للاقتطاع. يتم فك حزم execution_payload، ويقوم عميل التنفيذ الخاص بالمُدَقِّق بإعادة تنفيذ المعاملات في القائمة للتحقق من تغيير الحالة المقترح. بافتراض أن الكتلة تجتاز كل هذه الفحوصات، يضيف كل مُدَقِّق الكتلة إلى سلسلته الأساسية. ثم تبدأ العملية مرة أخرى في الخانة التالية.
مكافآت الكتلة
يتلقى مقترح الكتلة مدفوعات مقابل عمله. هناك base_reward يتم حسابها كدالة لعدد المُدَقِّقين النشطين وأرصدتهم الفعالة. يتلقى مقترح الكتلة بعد ذلك جزءًا من base_reward لكل تصديق صالح مدرج في الكتلة؛ كلما زاد عدد المُدَقِّقين الذين يصدقون على الكتلة، زادت مكافأة مقترح الكتلة. هناك أيضًا مكافأة للإبلاغ عن المُدَقِّقين الذين يجب اقتطاعهم، وتساوي 1/512 * effective balance لكل مُدَقِّق تم اقتطاعه.