عندما يهبط السوق فجأة في وقت مبكر، فإن أخطر شيء ليس التأخر في تنفيذ الصفقة 10 ثوانٍ، بل أن تظن أنها تمت—ثم بعد دقائق يخبرك النظام: تلك الصفقة لم تُحتسب
وهذا أيضًا أكثر ما أهتم به عندما واصلت تفكيك آلية الإجماع عند @Dusk . تحب كثير من السلاسل العامة الترويج بعدد المعاملات التي يمكنها معالجتها في كل ثانية، لكن السوق المالي يهتم بأمر آخر: في اللحظة التي تظهر على الشاشة فيها عبارة «اكتمل»، هل انتقلت ملكية الأصول فعليًا بشكل نهائي أم لا.
لم تجعل «Dusk» في «Succinct Attestation» عقدة واحدة مسؤولة عن إنتاج الكتل ومنح نفسها ختمًا بنفسها، بل قسمت كل جولة إجماع إلى ثلاث بوابات.
الأولى هي الاقتراح. يختار النظام منشئ الكتلة من بين المساهمين المرهِنين، فيقوم بتنظيم المعاملات وبث الكتلة المرشحة.
الثانية هي التحقق. يقوم المجلس الذي تم اختياره عشوائيًا بفحص ما إذا كانت الكتلة صحيحة، ثم يصوّت على النتيجة. هنا يتم الإجابة عن سؤال: «هل يمكن لهذه المعاملات أن تدخل إلى السجل؟
الثالثة هي الموافقة. تعيد مجموعة أخرى من اللجان تأكيد نتيجة التحقق، وبعد بلوغ العدد المطلوب من الأصوات يتم تشكيل الإثبات واكتمال التأكيد النهائي. بمعنى آخر، لم يتم تسليم «طرح السؤال» و«التصحيح» و«التوقيع النهائي» بالكامل إلى المجموعة نفسها.
كنت أتساءل سابقًا إن كانت التصميمات على ثلاث مراحل ستجعل العملية ثقيلة جدًا، ثم أدركت أن Dusk تراهن على تقليل اتصالات الشبكة على مستوى الشبكة بأخذ لجان عشوائية أصغر، مع الحفاظ على حكمين مستقلين. حاليًا تقدّم الصفحة الرسمية أن زمن «النهائية» يقارب 10 ثوانٍ. بمجرد إتمام موافقة الكتلة، تصبح النتيجة حتمية؛ وفي الظروف العادية لا يحتاج المستخدمون إلى الاستمرار في العد لعدة تأكيدات، ولا داعي للقلق من أن إعادة تنظيم السلسلة ستعيد الصفقة التي تم قبولها بالفعل إلى الوراء.
هذا مهم جدًا للمعاملات المالية. افترض أن «ساق الأصول» تُظهر أن التسليم تم، لكن «ساق الدفع» تفشل بسبب إعادة التنظيم. عندها لا يكون أمام المؤسسة مجرد تحويل فاشل واحد، بل تصادمًا في وقت واحد بين ملكية الأصل وسجلات المحاسبة ومسؤولية الطرف المقابل. ما تقلّله النهائية الحتمية فعلًا هو نافذة المخاطر بعد إتمام الصفقة مباشرة، حيث «لا تعرف إن كان الأمر سيُحسب أم لا».
لكن وجود ثلاث بوابات لا يعني أمانًا مطلقًا. ما زال يتعين التحقق عبر بيانات طويلة المدى: هل حجم اللجان العشوائية كافٍ؟ وهل العقد متركزة؟ وهل يمكن الحفاظ على نهائية مستقرة في حال ازدحام الشبكة؟ مهما كان تصميم البروتوكول جميلًا، يجب أن يصمد أمام تعطل العقد والأحمال القصوى من المرور.
لذلك عندما أنظر إلى $DUSK ، لن أكتفي بمجرد رقم «10 ثوانٍ» المذكور في الإعلان. ما أريده أكثر هو النهائية المتصلة، ومعدل مشاركة اللجان، ونسبة الدورات غير الطبيعية.
#dusk
وهذا أيضًا أكثر ما أهتم به عندما واصلت تفكيك آلية الإجماع عند @Dusk . تحب كثير من السلاسل العامة الترويج بعدد المعاملات التي يمكنها معالجتها في كل ثانية، لكن السوق المالي يهتم بأمر آخر: في اللحظة التي تظهر على الشاشة فيها عبارة «اكتمل»، هل انتقلت ملكية الأصول فعليًا بشكل نهائي أم لا.
لم تجعل «Dusk» في «Succinct Attestation» عقدة واحدة مسؤولة عن إنتاج الكتل ومنح نفسها ختمًا بنفسها، بل قسمت كل جولة إجماع إلى ثلاث بوابات.
الأولى هي الاقتراح. يختار النظام منشئ الكتلة من بين المساهمين المرهِنين، فيقوم بتنظيم المعاملات وبث الكتلة المرشحة.
الثانية هي التحقق. يقوم المجلس الذي تم اختياره عشوائيًا بفحص ما إذا كانت الكتلة صحيحة، ثم يصوّت على النتيجة. هنا يتم الإجابة عن سؤال: «هل يمكن لهذه المعاملات أن تدخل إلى السجل؟
الثالثة هي الموافقة. تعيد مجموعة أخرى من اللجان تأكيد نتيجة التحقق، وبعد بلوغ العدد المطلوب من الأصوات يتم تشكيل الإثبات واكتمال التأكيد النهائي. بمعنى آخر، لم يتم تسليم «طرح السؤال» و«التصحيح» و«التوقيع النهائي» بالكامل إلى المجموعة نفسها.
كنت أتساءل سابقًا إن كانت التصميمات على ثلاث مراحل ستجعل العملية ثقيلة جدًا، ثم أدركت أن Dusk تراهن على تقليل اتصالات الشبكة على مستوى الشبكة بأخذ لجان عشوائية أصغر، مع الحفاظ على حكمين مستقلين. حاليًا تقدّم الصفحة الرسمية أن زمن «النهائية» يقارب 10 ثوانٍ. بمجرد إتمام موافقة الكتلة، تصبح النتيجة حتمية؛ وفي الظروف العادية لا يحتاج المستخدمون إلى الاستمرار في العد لعدة تأكيدات، ولا داعي للقلق من أن إعادة تنظيم السلسلة ستعيد الصفقة التي تم قبولها بالفعل إلى الوراء.
هذا مهم جدًا للمعاملات المالية. افترض أن «ساق الأصول» تُظهر أن التسليم تم، لكن «ساق الدفع» تفشل بسبب إعادة التنظيم. عندها لا يكون أمام المؤسسة مجرد تحويل فاشل واحد، بل تصادمًا في وقت واحد بين ملكية الأصل وسجلات المحاسبة ومسؤولية الطرف المقابل. ما تقلّله النهائية الحتمية فعلًا هو نافذة المخاطر بعد إتمام الصفقة مباشرة، حيث «لا تعرف إن كان الأمر سيُحسب أم لا».
لكن وجود ثلاث بوابات لا يعني أمانًا مطلقًا. ما زال يتعين التحقق عبر بيانات طويلة المدى: هل حجم اللجان العشوائية كافٍ؟ وهل العقد متركزة؟ وهل يمكن الحفاظ على نهائية مستقرة في حال ازدحام الشبكة؟ مهما كان تصميم البروتوكول جميلًا، يجب أن يصمد أمام تعطل العقد والأحمال القصوى من المرور.
لذلك عندما أنظر إلى $DUSK ، لن أكتفي بمجرد رقم «10 ثوانٍ» المذكور في الإعلان. ما أريده أكثر هو النهائية المتصلة، ومعدل مشاركة اللجان، ونسبة الدورات غير الطبيعية.
#dusk
