بعد تحديث Dusk، عندما نقرّت على متصفح السلسلة على السلسلة للتحقق من عدد التأكيدات، اكتشفت تفاصيلًا سهلة الإغفال: في Dusk، عبارة “تم تأكيد الكتلة” ليست مجرد مفتاح بسيط، بل درجات حالة تصعد طبقة فوق طبقة.
يفهم معظم الناس الحتمية على أنها خياران فقط: إما غير مؤكدة، أو مؤكدة ولا يمكن عكسها. لكن تصميم Rolling Finality مختلف تمامًا. لكي تصل كتلة من لحظة تولّدها إلى أن تصبح مقفلة بالكامل، تمر بأربع مراحل: أولًا accepted (تمت القبول)، وفي هذه المرحلة لا يزال من الممكن استبدالها بكتل مرشحة ناتجة عن تكرارات سابقة؛ ثم attested (تمت المصادقة)، ولا يمكن الوصول إليها إلا بعد فشل كل التكرارات السابقة، ولا تعود إلى أن تُستبدل؛ ثم confirmed (تم التأكيد)، وهذه الخطوة تتطلب “تكديس” عددٍ لاحق من الكتل؛ وأخيرًا final (نهائية)، بشرط أن تكون كتلته الأب قد أصبحت نهائية، عندها فقط يمكن أن تصبح هي نهائية.
أكثر ما هو غير بديهي في هذه الآلية هو: عدد الكتل اللاحقة اللازمة لترقية كتلة معيّنة ليس رقمًا ثابتًا. توجد في القواعد متغير n، يمثل عدد مرات التكرار “غير الناجحة” قبل هذه الكتلة. كلما زاد n، احتجت إلى مزيد من كتل التأكيد اللاحقة، ويُحسب ذلك وفق 2n. بمعنى آخر: كلما كانت ولادة الكتلة أكثر التباسًا، احتاجت إلى وقت أطول بعد ذلك لتصبح مقفلة فعلًا. لذلك حتى لو كتب المحفظة “تم التأكيد”، فقد يكون مستوى الإقفال الحقيقي مختلفًا تمامًا.
ميزة هذا التصميم هي أن العقد يمكنها تقييم قيمة “جدارة الثقة” لكتلة ما بشكل أدق، بدل أن تكون الصورة بالأبيض والأسود. لكن الكلفة واضحة أيضًا: المستخدم العادي لا يمكنه معرفة إلى أي مستوى وصلت معاملته حاليًا. المحفظة تعرض فقط تنبيهًا واحدًا “تم التأكيد”، وتُخفي هذه الطبقات تمامًا. وفي حال حدوث تفرّع متطرف، هل يمكن استغلال هذا الفارق في المعلومات؟ صعب الجزم.
هل أنتم عادةً تفحصون بشكل خاص إلى أي مستوى تأكيد وصلت معاملتكم، أم تصدقون فورًا ما تقوله المحفظة؟ تفضلوا بالنقاش في قسم التعليقات.#dusk $DUSK @Dusk
يفهم معظم الناس الحتمية على أنها خياران فقط: إما غير مؤكدة، أو مؤكدة ولا يمكن عكسها. لكن تصميم Rolling Finality مختلف تمامًا. لكي تصل كتلة من لحظة تولّدها إلى أن تصبح مقفلة بالكامل، تمر بأربع مراحل: أولًا accepted (تمت القبول)، وفي هذه المرحلة لا يزال من الممكن استبدالها بكتل مرشحة ناتجة عن تكرارات سابقة؛ ثم attested (تمت المصادقة)، ولا يمكن الوصول إليها إلا بعد فشل كل التكرارات السابقة، ولا تعود إلى أن تُستبدل؛ ثم confirmed (تم التأكيد)، وهذه الخطوة تتطلب “تكديس” عددٍ لاحق من الكتل؛ وأخيرًا final (نهائية)، بشرط أن تكون كتلته الأب قد أصبحت نهائية، عندها فقط يمكن أن تصبح هي نهائية.
أكثر ما هو غير بديهي في هذه الآلية هو: عدد الكتل اللاحقة اللازمة لترقية كتلة معيّنة ليس رقمًا ثابتًا. توجد في القواعد متغير n، يمثل عدد مرات التكرار “غير الناجحة” قبل هذه الكتلة. كلما زاد n، احتجت إلى مزيد من كتل التأكيد اللاحقة، ويُحسب ذلك وفق 2n. بمعنى آخر: كلما كانت ولادة الكتلة أكثر التباسًا، احتاجت إلى وقت أطول بعد ذلك لتصبح مقفلة فعلًا. لذلك حتى لو كتب المحفظة “تم التأكيد”، فقد يكون مستوى الإقفال الحقيقي مختلفًا تمامًا.
ميزة هذا التصميم هي أن العقد يمكنها تقييم قيمة “جدارة الثقة” لكتلة ما بشكل أدق، بدل أن تكون الصورة بالأبيض والأسود. لكن الكلفة واضحة أيضًا: المستخدم العادي لا يمكنه معرفة إلى أي مستوى وصلت معاملته حاليًا. المحفظة تعرض فقط تنبيهًا واحدًا “تم التأكيد”، وتُخفي هذه الطبقات تمامًا. وفي حال حدوث تفرّع متطرف، هل يمكن استغلال هذا الفارق في المعلومات؟ صعب الجزم.
هل أنتم عادةً تفحصون بشكل خاص إلى أي مستوى تأكيد وصلت معاملتكم، أم تصدقون فورًا ما تقوله المحفظة؟ تفضلوا بالنقاش في قسم التعليقات.#dusk $DUSK @Dusk