افترضت أن عملية الرهان على سلسلة تعمل بإثبات الحصة تعني أن مفتاحًا واحدًا يتحكم بكل شيء: أُدخل DUSK، وأستلم المكافآت، ويتكفل نفس المفتاح بذلك من البداية إلى النهاية.
لكن وثائق المشغّل الخاصة بـ Dusk تقسم ذلك إلى جزأين.
مفتاح الإجماع هو المفتاح الذي يستخدمه العقد للتوقيع والتصويت في الإجماع. يجب أن يكون موجودًا على عقدة متصلة بالإنترنت وأن يشارك أثناء تشغيل المُحقِّق (validator). أما مفتاح المالك فهو منفصل: إنه المفتاح الذي يمكنه إلغاء الرهان أو سحب الأموال، وتقول الوثائق إنه لا يحتاج إلى لمس العقدة على الإطلاق.
الفائدة الأمنية لا تكمن فقط في وجود مفتاحين. بل في أن صلاحية المشاركة في الإجماع وصلاحية سحب الأموال لا يلزم أن تعيشا في نفس المكان. إذا تم اختراق مفتاح الإجماع لأن الخادم الذي يعمل عليه تعرض للاختراق، يمكن للمهاجم التدخل في المشاركة في الإجماع، لكن ما زال لا يستطيع إلغاء الرهان أو سحب الرهان. وهذه الصلاحية لم تكن موجودة أصلًا على الجهاز المكشوف للإنترنت. وهذا يعني أن السؤال الأمني الحقيقي ليس فقط مقدار ما تم رهنه. بل أين تجلس صلاحية سحب الرهن فعليًا بالنسبة للجهاز المُعرّض للمهاجمين.
لكن توجد حيلة لا تُخفيها الوثائق: هذا الفصل ليس هو الإعداد الافتراضي. إذا راهنت دون تحديد مالك منفصل، فإن مفتاح الإجماع يصبح تلقائيًا مالكًا أيضًا — مفتاح واحد، وحد واحد، والعودة إلى النموذج الذي افترضته في البداية. الإعداد الأكثر أمانًا هو اختيار يتعين على المشغّل أن يفعله بوعي، وليس شيئًا يجبره عليه البروتوكول.
"حد أمني يجب تفعيله يقدّم ضمانًا مختلفًا عن ضمان مدمج في المسار الافتراضي، حتى عندما يكون كلاهما متاحًا تقنيًا."
ما أود معرفته فعلًا: كم عدد المُقدّمين/الموفّرين النشطين الذين يعملون بمفتاح مالك منفصل مقارنة بالإعداد الافتراضي، لأن ذلك سيخبرني ما إذا كان يتم اعتماد الحدّ الأقوى بالفعل، وليس مجرد أن يكون متاحًا.
#dusk $DUSK @Dusk
لكن وثائق المشغّل الخاصة بـ Dusk تقسم ذلك إلى جزأين.
مفتاح الإجماع هو المفتاح الذي يستخدمه العقد للتوقيع والتصويت في الإجماع. يجب أن يكون موجودًا على عقدة متصلة بالإنترنت وأن يشارك أثناء تشغيل المُحقِّق (validator). أما مفتاح المالك فهو منفصل: إنه المفتاح الذي يمكنه إلغاء الرهان أو سحب الأموال، وتقول الوثائق إنه لا يحتاج إلى لمس العقدة على الإطلاق.
الفائدة الأمنية لا تكمن فقط في وجود مفتاحين. بل في أن صلاحية المشاركة في الإجماع وصلاحية سحب الأموال لا يلزم أن تعيشا في نفس المكان. إذا تم اختراق مفتاح الإجماع لأن الخادم الذي يعمل عليه تعرض للاختراق، يمكن للمهاجم التدخل في المشاركة في الإجماع، لكن ما زال لا يستطيع إلغاء الرهان أو سحب الرهان. وهذه الصلاحية لم تكن موجودة أصلًا على الجهاز المكشوف للإنترنت. وهذا يعني أن السؤال الأمني الحقيقي ليس فقط مقدار ما تم رهنه. بل أين تجلس صلاحية سحب الرهن فعليًا بالنسبة للجهاز المُعرّض للمهاجمين.
لكن توجد حيلة لا تُخفيها الوثائق: هذا الفصل ليس هو الإعداد الافتراضي. إذا راهنت دون تحديد مالك منفصل، فإن مفتاح الإجماع يصبح تلقائيًا مالكًا أيضًا — مفتاح واحد، وحد واحد، والعودة إلى النموذج الذي افترضته في البداية. الإعداد الأكثر أمانًا هو اختيار يتعين على المشغّل أن يفعله بوعي، وليس شيئًا يجبره عليه البروتوكول.
"حد أمني يجب تفعيله يقدّم ضمانًا مختلفًا عن ضمان مدمج في المسار الافتراضي، حتى عندما يكون كلاهما متاحًا تقنيًا."
ما أود معرفته فعلًا: كم عدد المُقدّمين/الموفّرين النشطين الذين يعملون بمفتاح مالك منفصل مقارنة بالإعداد الافتراضي، لأن ذلك سيخبرني ما إذا كان يتم اعتماد الحدّ الأقوى بالفعل، وليس مجرد أن يكون متاحًا.
#dusk $DUSK @Dusk
