#dusk $DUSK @Dusk
تتبّعتُ كيف يتم فعليًا اعتماد كتلة Dusk هذا الأسبوع، لأنني أردت أن أفهم ماذا يحتوي مصطلح "التحقق (attestation)" بالضبط — ليس فقط أن تم الوصول إلى النصاب، بل كيف تبدو البينة من الناحية البنيوية.
يتضمن تصميم الإجماع تأكيدًا على مرحلتين بعد اقتراح مرشح للكتلة: التحقق (Validation)، حيث يصوّت أعضاء اللجنة بـ "صحيح (Valid)" أو "غير صحيح (Invalid)"، ثم التصديق (Ratification)، حيث تؤكد لجنة ثانية نتيجة التحقق. إذا وصلت كلتا المرحلتين إلى النصاب، يتم إنتاج تحقق ناجح.
ما الذي يوجد داخل التحقق: نوع تصويت الوصول إلى النصاب (Valid أو Invalid أو NoCandidate أو NoQuorum)، بالإضافة إلى توقيعات BLS المجمّعة من مرحلتي التحقق والتصديق. ومعه bitset (مجموعة بتات). هذا الجزء هو ما لم أره موضحًا في أي ملخصات.
يشير الـ bitset إلى أي أعضاء لجنة تم تضمين توقيعاتهم ضمن عملية التجميع. إذا كانت اللجنة هي [P0, P1, P2, P3] والـ bitset هو [0, 1, 0, 1]، فهذا يعني أن P1 وP3 قد وقّعا.
هذا الجزء ثابت. تحقق واحد مُدمج يحمل كل ما يلزم للتحقق من بلوغ النصاب — التصويت، البينة المجمّعة، وسجل الانتماء — دون أن تتزايد الأحجام بشكل خطّي مع حجم اللجنة.
الأصعب في التفكير هو ما يحدث عندما تتراكم التحققات. يحتاج بلوك مُعلَن أنه "مؤكّد" إلى كتل خلفية كافية، وكل واحدة منها تحمل تحققها الخاص. إذا كانت التحققات كبيرة فعليًا، أو إذا احتاجت العقد إلى تخزين السجل الكامل للاتتاشات للمزامنة، فهناك تكلفة تخزين وعرض نطاق لا تظهر عند وصف الوصول إلى النصاب وحده.
أعتقد فعلًا أن الـ bitset هو الجزء الأذكى فعلًا — فهو ما يجعل تجميع BLS عمليًا عندما تحتاج لاحقًا إلى التحقق بدقة من من وقّع، وليس فقط أن العتبة قد تحققت.
ما لم أستطع حسمه بعد هو ما إذا كانت التحققات الفاشلة تحمل البنية المجمّعة نفسها على مرحلتين مثل التحققات الناجحة — أم أن نتيجة الفشل من مجرد مرحلة واحدة تكفي لإغلاق التكرار دون الحاجة إلى إتمام المرحلتين. @Dusk
$DUSK #dusk
تتبّعتُ كيف يتم فعليًا اعتماد كتلة Dusk هذا الأسبوع، لأنني أردت أن أفهم ماذا يحتوي مصطلح "التحقق (attestation)" بالضبط — ليس فقط أن تم الوصول إلى النصاب، بل كيف تبدو البينة من الناحية البنيوية.
يتضمن تصميم الإجماع تأكيدًا على مرحلتين بعد اقتراح مرشح للكتلة: التحقق (Validation)، حيث يصوّت أعضاء اللجنة بـ "صحيح (Valid)" أو "غير صحيح (Invalid)"، ثم التصديق (Ratification)، حيث تؤكد لجنة ثانية نتيجة التحقق. إذا وصلت كلتا المرحلتين إلى النصاب، يتم إنتاج تحقق ناجح.
ما الذي يوجد داخل التحقق: نوع تصويت الوصول إلى النصاب (Valid أو Invalid أو NoCandidate أو NoQuorum)، بالإضافة إلى توقيعات BLS المجمّعة من مرحلتي التحقق والتصديق. ومعه bitset (مجموعة بتات). هذا الجزء هو ما لم أره موضحًا في أي ملخصات.
يشير الـ bitset إلى أي أعضاء لجنة تم تضمين توقيعاتهم ضمن عملية التجميع. إذا كانت اللجنة هي [P0, P1, P2, P3] والـ bitset هو [0, 1, 0, 1]، فهذا يعني أن P1 وP3 قد وقّعا.
هذا الجزء ثابت. تحقق واحد مُدمج يحمل كل ما يلزم للتحقق من بلوغ النصاب — التصويت، البينة المجمّعة، وسجل الانتماء — دون أن تتزايد الأحجام بشكل خطّي مع حجم اللجنة.
الأصعب في التفكير هو ما يحدث عندما تتراكم التحققات. يحتاج بلوك مُعلَن أنه "مؤكّد" إلى كتل خلفية كافية، وكل واحدة منها تحمل تحققها الخاص. إذا كانت التحققات كبيرة فعليًا، أو إذا احتاجت العقد إلى تخزين السجل الكامل للاتتاشات للمزامنة، فهناك تكلفة تخزين وعرض نطاق لا تظهر عند وصف الوصول إلى النصاب وحده.
أعتقد فعلًا أن الـ bitset هو الجزء الأذكى فعلًا — فهو ما يجعل تجميع BLS عمليًا عندما تحتاج لاحقًا إلى التحقق بدقة من من وقّع، وليس فقط أن العتبة قد تحققت.
ما لم أستطع حسمه بعد هو ما إذا كانت التحققات الفاشلة تحمل البنية المجمّعة نفسها على مرحلتين مثل التحققات الناجحة — أم أن نتيجة الفشل من مجرد مرحلة واحدة تكفي لإغلاق التكرار دون الحاجة إلى إتمام المرحلتين. @Dusk
$DUSK #dusk