كلما واجهت Dusk مشكلة، زاد اهتمامي بمن يتولى زمام استعادة الشبكة
عند قراءة جزء الـ consensus الخاص بـ Dusk، أرى أن الآلية العادية ليست أكثر ما يستدعي القلق. ما هو مثير للاهتمام هو اللحظة التي لا تتمكن فيها الشبكة من الوصول إلى quorum باستمرار.
بعد 16 iteration فاشلة، ينتقل Succinct Attestation إلى وضع الطوارئ. يتم إلغاء timeout لكل خطوة، ويمكن فتح عدة iterations في الوقت نفسه لزيادة فرصة العثور على block صالح. إذا وصل أكثر من candidate إلى consensus في آن واحد، يتم تفضيل block الخاصة بالـ iteration الأقل.
يساعد هذا التصميم الشبكة على عدم التعطل فقط بسبب بعض الـ provisioners البطيئين أو الذين فقدوا الاتصال. لكن ذلك جعلني منتبهًا أيضًا إلى خط فاصل آخر: عندما تسوء ظروف الشبكة، تصبح إمكانية الاستعادة أكثر اعتمادًا بشكل واضح على توزيع الـ stake.
في السيناريو الأخير، لا يتم إنشاء emergency block إلا عندما يطلبها فريق الـ provisioner وأن تمتلك الأغلبية من إجمالي stake في الشبكة. وفي حين يرغب المرء في المشاركة مباشرة في الـ consensus، يحتاج الـ provisioner حاليًا إلى stake بحد أدنى 1.000 DUSK.
لذلك لا أنظر إلى الـ staking فقط على أنه وسيلة لكسب المكافآت. بل إنه يحدد أيضًا من يملك وزناً عندما يحتاج النظام إلى الخروج من حالة غير طبيعية.
برأيي، الاختبار الأهم لـ Dusk ليس يومًا تعمل فيه الشبكة بسلاسة. بل هو عندما يزيد الازدحام، وتتأخر بعض الـ nodes، وتستمر اللجان (committees) في التبدل—وهل تتمكن الشبكة من التعافي دون أن يتم حشر سلطة اتخاذ القرار بشكل مفرط في مجموعة كبيرة من الـ stake.
قد تكون آلية recovery مضمونة تقنيًا.
لكن إذا كانت سلطة إنقاذ الشبكة تتزايد تركّزًا مع الـ stake، فالتـ decentralization هي ما ينبغي قياسه بدقة أكبر.
@Dusk $DUSK #dusk
$ONDO $BTC
عند قراءة جزء الـ consensus الخاص بـ Dusk، أرى أن الآلية العادية ليست أكثر ما يستدعي القلق. ما هو مثير للاهتمام هو اللحظة التي لا تتمكن فيها الشبكة من الوصول إلى quorum باستمرار.
بعد 16 iteration فاشلة، ينتقل Succinct Attestation إلى وضع الطوارئ. يتم إلغاء timeout لكل خطوة، ويمكن فتح عدة iterations في الوقت نفسه لزيادة فرصة العثور على block صالح. إذا وصل أكثر من candidate إلى consensus في آن واحد، يتم تفضيل block الخاصة بالـ iteration الأقل.
يساعد هذا التصميم الشبكة على عدم التعطل فقط بسبب بعض الـ provisioners البطيئين أو الذين فقدوا الاتصال. لكن ذلك جعلني منتبهًا أيضًا إلى خط فاصل آخر: عندما تسوء ظروف الشبكة، تصبح إمكانية الاستعادة أكثر اعتمادًا بشكل واضح على توزيع الـ stake.
في السيناريو الأخير، لا يتم إنشاء emergency block إلا عندما يطلبها فريق الـ provisioner وأن تمتلك الأغلبية من إجمالي stake في الشبكة. وفي حين يرغب المرء في المشاركة مباشرة في الـ consensus، يحتاج الـ provisioner حاليًا إلى stake بحد أدنى 1.000 DUSK.
لذلك لا أنظر إلى الـ staking فقط على أنه وسيلة لكسب المكافآت. بل إنه يحدد أيضًا من يملك وزناً عندما يحتاج النظام إلى الخروج من حالة غير طبيعية.
برأيي، الاختبار الأهم لـ Dusk ليس يومًا تعمل فيه الشبكة بسلاسة. بل هو عندما يزيد الازدحام، وتتأخر بعض الـ nodes، وتستمر اللجان (committees) في التبدل—وهل تتمكن الشبكة من التعافي دون أن يتم حشر سلطة اتخاذ القرار بشكل مفرط في مجموعة كبيرة من الـ stake.
قد تكون آلية recovery مضمونة تقنيًا.
لكن إذا كانت سلطة إنقاذ الشبكة تتزايد تركّزًا مع الـ stake، فالتـ decentralization هي ما ينبغي قياسه بدقة أكبر.
@Dusk $DUSK #dusk
$ONDO $BTC
