---
title: "المفاتيح في إثبات الحصة (⁦PoS⁩) على إيثيريوم"
description: "شرح للمفاتيح المستخدمة في آلية إجماع إثبات الحصة (⁦PoS⁩) على إيثيريوم"
lang: ar
---

تؤمن إيثيريوم أصول المستخدمين باستخدام علم التشفير بالمفتاح العام والخاص. يُستخدم المفتاح العام كأساس لعنوان إيثيريوم — أي أنه مرئي لعامة الناس ويُستخدم كمعرف فريد. يجب أن يكون المفتاح الخاص (أو "السري") متاحًا فقط لمالك الحساب. يُستخدم المفتاح الخاص لـ "توقيع" المعاملات والبيانات بحيث يمكن لعلم التشفير إثبات أن الحامل يوافق على إجراء معين لمفتاح خاص محدد.

يتم إنشاء مفاتيح إيثيريوم باستخدام [علم التشفير بالمنحنى الإهليلجي](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography).

ومع ذلك، عندما تحولت إيثيريوم من [إثبات العمل (PoW)](/developers/docs/consensus-mechanisms/pow) إلى [إثبات الحصة (PoS)](/developers/docs/consensus-mechanisms/pos)، تمت إضافة نوع جديد من المفاتيح إلى إيثيريوم. لا تزال المفاتيح الأصلية تعمل تمامًا كما كانت من قبل — لم تكن هناك تغييرات على المفاتيح القائمة على المنحنى الإهليلجي التي تؤمن الحسابات. ومع ذلك، احتاج المستخدمون إلى نوع جديد من المفاتيح للمشاركة في إثبات الحصة (PoS) عن طريق تخزين <span dir="ltr">ETH</span> وتشغيل المُدَقِّقين. نشأت هذه الحاجة من تحديات التوسع المرتبطة بتمرير العديد من الرسائل بين أعداد كبيرة من المُدَقِّقين والتي تطلبت طريقة تشفير يمكن تجميعها بسهولة لتقليل مقدار الاتصال المطلوب للشبكة للوصول إلى الإجماع.

يستخدم هذا النوع الجديد من المفاتيح [مخطط توقيع **<span dir="ltr">Boneh-Lynn-Shacham (BLS)</span>**](https://wikipedia.org/wiki/BLS_digital_signature). يتيح <span dir="ltr">BLS</span> تجميعًا فعالًا للغاية للتوقيعات ولكنه يسمح أيضًا بالهندسة العكسية لمفاتيح المُدَقِّق الفردية المجمعة وهو مثالي لإدارة الإجراءات بين المُدَقِّقين.

## نوعا مفاتيح المُدَقِّق {#two-types-of-keys}

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

### مفتاح المُدَقِّق {#validator-key}

يتكون مفتاح توقيع المُدَقِّق من عنصرين:

- مفتاح المُدَقِّق **الخاص**
- مفتاح المُدَقِّق **العام**

الغرض من مفتاح المُدَقِّق الخاص هو توقيع العمليات على السلسلة مثل مقترحات الكتل والتصديقات. وبسبب هذا، يجب الاحتفاظ بهذه المفاتيح في محفظة ساخنة.

تتميز هذه المرونة بميزة نقل مفاتيح توقيع المُدَقِّق بسرعة كبيرة من جهاز إلى آخر، ومع ذلك، إذا فُقدت أو سُرقت، فقد يتمكن السارق من **التصرف بشكل ضار** بعدة طرق:

- التسبب في اقتطاع المُدَقِّق عن طريق:
  - كونه مُقترِحًا وتوقيع كتلتين مختلفتين من كتل المنارة لنفس الخانة
  - كونه مُصَدِّقًا وتوقيع تصديق "يحيط" بتصديق آخر
  - كونه مُصَدِّقًا وتوقيع تصديقين مختلفين لهما نفس الهدف
- فرض خروج طوعي، مما يوقف المُدَقِّق عن التخزين، ويمنح حق الوصول إلى رصيده من <span dir="ltr">ETH</span> لمالك مفتاح السحب

يتم تضمين **مفتاح المُدَقِّق العام** في بيانات المعاملة عندما يودع المستخدم <span dir="ltr">ETH</span> في عقد وديعة التخزين. يُعرف هذا باسم _بيانات الوديعة_ ويسمح لإيثيريوم بتحديد المُدَقِّق.

### بيانات اعتماد السحب {#withdrawal-credentials}

يتمتع كل مُدَقِّق بخاصية تُعرف باسم _بيانات اعتماد السحب_. يحدد البايت الأول من هذا الحقل المكون من <span dir="ltr">32-byte</span> نوع الحساب: يمثل `0x00` بيانات اعتماد <span dir="ltr">BLS</span> الأصلية (ما قبل شابيلا، غير قابلة للسحب)، ويمثل `0x01` بيانات الاعتماد القديمة التي تشير إلى عنوان تنفيذ، ويمثل `0x02` نوع بيانات الاعتماد المركبة الحديثة.

يجب على المُدَقِّقين الذين لديهم مفاتيح <span dir="ltr">BLS</span> من نوع `0x00` تحديث بيانات الاعتماد هذه للإشارة إلى عنوان تنفيذ من أجل تنشيط مدفوعات الرصيد الزائد أو السحب الكامل من التخزين. يمكن القيام بذلك عن طريق توفير عنوان تنفيذ في بيانات الوديعة أثناء إنشاء المفتاح الأولي، _أو_ باستخدام مفتاح السحب في وقت لاحق لتوقيع وبث رسالة `BLSToExecutionChange`.

[المزيد حول بيانات اعتماد سحب المُدَقِّق](/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/)

### مفتاح السحب {#withdrawal-key}

سيكون مفتاح السحب مطلوبًا لتحديث بيانات اعتماد السحب للإشارة إلى عنوان تنفيذ، إذا لم يتم تعيينه أثناء الإيداع الأولي. سيمكن هذا من بدء معالجة مدفوعات الرصيد الزائد، وسيسمح أيضًا للمستخدمين بسحب حصة التخزين الخاصة بهم من <span dir="ltr">ETH</span> بالكامل.

تمامًا مثل مفاتيح المُدَقِّق، تتكون مفاتيح السحب أيضًا من مكونين:

- مفتاح السحب **الخاص**
- مفتاح السحب **العام**

فقدان هذا المفتاح قبل تحديث بيانات اعتماد السحب إلى النوع `0x01` يعني فقدان الوصول إلى رصيد المُدَقِّق. لا يزال بإمكان المُدَقِّق توقيع التصديقات والكتل لأن هذه الإجراءات تتطلب مفتاح المُدَقِّق الخاص، ومع ذلك لا يوجد حافز يُذكر إذا فُقدت مفاتيح السحب.

يتيح فصل مفاتيح المُدَقِّق عن مفاتيح حساب إيثيريوم تشغيل مُدَقِّقين متعددين بواسطة مستخدم واحد.

![validator key schematic](validator-key-schematic.png)

**ملاحظة**: يتطلب الخروج من مهام التخزين وسحب رصيد المُدَقِّق حاليًا توقيع [رسالة خروج طوعي (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) باستخدام مفتاح المُدَقِّق. ومع ذلك، فإن [<span dir="ltr">EIP-7002</span>](https://eips.ethereum.org/EIPS/eip-7002) هو مقترح سيسمح للمستخدم بتشغيل خروج المُدَقِّق وسحب رصيده عن طريق توقيع رسائل الخروج باستخدام مفتاح السحب في المستقبل. سيؤدي هذا إلى تقليل افتراضات الثقة من خلال تمكين المخزنين الذين يفوضون <span dir="ltr">ETH</span> إلى [مزودي التخزين كخدمة](/staking/saas/#what-is-staking-as-a-service) من البقاء متحكمين في أموالهم.

## اشتقاق المفاتيح من عبارة الاسترداد {#deriving-keys-from-seed}

إذا كان كل <span dir="ltr">32 ETH</span> مخزنة تتطلب مجموعة جديدة من مفتاحين مستقلين تمامًا، فستصبح إدارة المفاتيح صعبة الاستخدام بسرعة، خاصة للمستخدمين الذين يشغلون مُدَقِّقين متعددين. بدلاً من ذلك، يمكن اشتقاق مفاتيح مُدَقِّق متعددة من سر مشترك واحد، ويسمح تخزين هذا السر الواحد بالوصول إلى مفاتيح مُدَقِّق متعددة.

تعد [العبارات التذكيرية (Mnemonics)](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) والمسارات ميزات بارزة يواجهها المستخدمون غالبًا عندما [يصلون](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) إلى محافظهم. العبارة التذكيرية هي تسلسل من الكلمات التي تعمل كبذرة أولية لمفتاح خاص. عند دمجها مع بيانات إضافية، تُنشئ العبارة التذكيرية تجزئة تُعرف باسم "المفتاح الرئيسي". يمكن التفكير في هذا كجذر لشجرة. يمكن بعد ذلك اشتقاق الفروع من هذا الجذر باستخدام مسار هرمي بحيث يمكن أن توجد العقد الفرعية كمجموعات من تجزئة العقدة الأصلية ومؤشرها في الشجرة. اقرأ عن معايير [<span dir="ltr">BIP-32</span>](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) و[<span dir="ltr">BIP-19</span>](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) لإنشاء المفاتيح المستندة إلى العبارات التذكيرية.

تحتوي هذه المسارات على الهيكل التالي، والذي سيكون مألوفًا للمستخدمين الذين تفاعلوا مع محافظ الأجهزة:

```
m/44'/60'/0'/0`
```

تفصل الشرطات المائلة في هذا المسار مكونات المفتاح الخاص على النحو التالي:

```
master_key / purpose / coin_type / account / change / address_index
```

يمكّن هذا المنطق المستخدمين من إرفاق أكبر عدد ممكن من المُدَقِّقين بـ **عبارة تذكيرية** واحدة لأن جذر الشجرة يمكن أن يكون مشتركًا، ويمكن أن يحدث التمايز عند الفروع. يمكن للمستخدم **اشتقاق أي عدد من المفاتيح** من العبارة التذكيرية.

```
[m / 0]
     /
    /
[m] - [m / 1]
    \
     \
      [m / 2]
```

يتم فصل كل فرع بـ `/` لذا فإن `m/2` يعني البدء بالمفتاح الرئيسي واتباع الفرع 2. في المخطط أدناه، يتم استخدام عبارة تذكيرية واحدة لتخزين ثلاثة مفاتيح سحب، كل منها مرتبط بمُدَقِّقين اثنين.

![validator key logic](multiple-keys.png)

## قراءة إضافية {#further-reading}

- [منشور مدونة مؤسسة إيثيريوم بواسطة كارل بيكهويزن (Carl Beekhuizen)](https://blog.ethereum.org/2020/05/21/keys)
- [إنشاء مفتاح <span dir="ltr">EIP-2333 BLS12-381</span>](https://eips.ethereum.org/EIPS/eip-2333)
- [<span dir="ltr">EIP-7002</span>: عمليات الخروج التي يتم تشغيلها بواسطة طبقة التنفيذ](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge)
- [إدارة المفاتيح على نطاق واسع](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale)