أدى مشاهدتي لعملية إنهاء جولة على Dusk إلى توقّفي عندما لاحظت كيف يتعامل آلية «الإثبات الموجز» فعليًا مع التحقق في الوقت الفعلي. تمتلك بعض $DUSK ، وتُقفل الحد الأدنى من الرهان لتصبح مُقدِّم خدمات عبر عقد الرهان، وتتوقع التغيّر الكبير المعتاد في المحققين (validator churn)، لكن @DuskFoundation صمّم ذلك ليعتمد على «الاختيار العشوائي الحتمي» خفيف الوزن بدلاً من القوة الغاشمة للمحققين. يجعل هذا #Dusk يشعر أقل كوحش PoS ضخم يتعثر، وأكثر كقرعة مُحكمة وغير تفاعلية من لجانٍ دوّارة.
ما الذي انفتح في ذهني أثناء تتبّع الكتل؟ الفصل بين مراحل الاقتراح والتحقق والتصديق النهائي (ratification). بدلًا من الاعتماد على فيض البث عبر الشبكة بالكامل، يتم استخراج لجنة ذات 64 رصيدًا عبر التسجيل بنقاط SHA3، ثم يتم اعتمادها عبر توقيعات BLS مُجمّعة، وتُقفل الشهادات/الإثباتات (attestations) بأقل قدر من التكاليف. منطق المعالجة عند الفشل (fallback) ومرونة «النهائية المتدفقة» يعني أنه إذا توقفت تكرارية ما أو حدثت تفرعات (forks) تحت وطأة التأخر (latency)، فإن الشهادات/الإثباتات السابقة تتدخل لإصلاح حالة سلسلة الكتلة بشكل حتمي.
تقوم معظم سلاسل PoS برقع مشكلات التأخر عبر رمي مزيد من العتاد على المشكلة أو الاعتماد على اختصارات مُنسّق مركزي (centralized sequencer). رؤية مقدِّمي الخدمات يتناوبون عبر مقاعد اللجنة دون الحاجة إلى تنسيق تفاعلي غيّرت منظوري حول مدى نحافة طبقة تسوية مُنظّمة يمكن أن تعمل فعليًا.
ومع ذلك، لا يزال يراودني سؤال: كيف يتصرف هذا الاختيار العشوائي الحتمي عندما تصطدم سيناريوهات الحواف بضغوط معاملات شديدة في العالم الحقيقي؟ إذا فشلت تكرارات متتالية وتفعّلت «وضع الطوارئ» فتبدأ تكرارات متعددة في آن واحد، هل تحافظ بنية العقوبة التحفيزية على اصطفاف مقدِّمي الخدمات، أم أن تأخر الشبكة سينتهي بدفع الكثير من عمليات التراجع/الرجوع (fallback rollbacks)؟
@Dusk #dusk $DUSK
ما الذي انفتح في ذهني أثناء تتبّع الكتل؟ الفصل بين مراحل الاقتراح والتحقق والتصديق النهائي (ratification). بدلًا من الاعتماد على فيض البث عبر الشبكة بالكامل، يتم استخراج لجنة ذات 64 رصيدًا عبر التسجيل بنقاط SHA3، ثم يتم اعتمادها عبر توقيعات BLS مُجمّعة، وتُقفل الشهادات/الإثباتات (attestations) بأقل قدر من التكاليف. منطق المعالجة عند الفشل (fallback) ومرونة «النهائية المتدفقة» يعني أنه إذا توقفت تكرارية ما أو حدثت تفرعات (forks) تحت وطأة التأخر (latency)، فإن الشهادات/الإثباتات السابقة تتدخل لإصلاح حالة سلسلة الكتلة بشكل حتمي.
تقوم معظم سلاسل PoS برقع مشكلات التأخر عبر رمي مزيد من العتاد على المشكلة أو الاعتماد على اختصارات مُنسّق مركزي (centralized sequencer). رؤية مقدِّمي الخدمات يتناوبون عبر مقاعد اللجنة دون الحاجة إلى تنسيق تفاعلي غيّرت منظوري حول مدى نحافة طبقة تسوية مُنظّمة يمكن أن تعمل فعليًا.
ومع ذلك، لا يزال يراودني سؤال: كيف يتصرف هذا الاختيار العشوائي الحتمي عندما تصطدم سيناريوهات الحواف بضغوط معاملات شديدة في العالم الحقيقي؟ إذا فشلت تكرارات متتالية وتفعّلت «وضع الطوارئ» فتبدأ تكرارات متعددة في آن واحد، هل تحافظ بنية العقوبة التحفيزية على اصطفاف مقدِّمي الخدمات، أم أن تأخر الشبكة سينتهي بدفع الكثير من عمليات التراجع/الرجوع (fallback rollbacks)؟
@Dusk #dusk $DUSK

