#dusk $DUSK @Dusk
في الأنظمة المالية التقليدية، لمنع إعادة معالجة نفس التعليمة عدة مرات، يعتمد المرء على آلية بدائية لكن فعّالة: رقم تسلسلي أو رقم شيك. تمر كل تعليمة عبر رقم فريد، ويكتفي النظام بتسجيل الإرسال الأول؛ أما أي إرسال تكرر لاحقًا فيُرفض تلقائيًا. هذه الآلية “ترابية” وبسيطة إلى حد ما، لكن خلال عقود من الزمن كانت البنية التحتية المالية تعتمد على هذا الحل البدائي، وقد حال دون وقوع أغلب حوادث السداد/التصفية المكررة بسبب الأخطاء.
في نموذج حساب Moonlight الخاص بـ Dusk، يتم فعل الشيء نفسه تقريبًا: يحتفظ كل حساب بعدّاد nonce (عداد). يجب أن تكون كل معاملة جديدة رقمها nonce أكبر بمقدار 1 تمامًا عن nonce الحالي. وبعد الإرسال، يرتفع nonce. وبهذا، حتى لو تم بث نفس معاملة موقّعة بشكل متكرر أو إرسالها من جديد، فإن الشبكة ستقبل الإرسال الأول فقط، أما اللاحق فسيُرفض مباشرة. يبدو هذا التصميم أبسط ما يمكن—بسيط لدرجة أن كثيرين ربما لا ينتبهون لوجوده أصلًا—لكن هذه الآلية الأساسية، بالذات، هي ما يحدد ما إذا كانت السلسلة قادرة على أن يثق بها معالِجون ومؤسسات مسؤولة عن تسويات أموال حقيقية.
منذ أن دخلت هذا المجال قبل سنوات، رأيت أكثر من مرة حالات نتجت عن سوء التعامل مع التعليمات المكررة بسبب الأنظمة القديمة: تم خصم نفس التحويل أكثر من مرة، ثم اضطر الجميع لاحقًا إلى المرور بإجراءات مطوّلة للمطابقة والاسترداد. في التمويل التقليدي تُصنَّف هذه المشكلات غالبًا على أنها “حادث تشغيلي”، ولا تَظهر كثيرًا في الأخبار. لكن بالنسبة للمؤسسة المعنية والعميل، فإن التعامل معها ليس أمرًا هينًا. إذا كانت سلسلة هدفها خدمة تسويات المؤسسات لا تضع آلية منع إعادة الإرسال (replay) الأساسية هذه بشكل متين، فلن يكون لأي شيء آخر—حتى لو تراكمت عليه إثباتات معرفة صفرية—معنى كبير. المؤسسات لا تهتم بمدى تقدم التشفير لديك؛ أول سؤال هو: “هل يمكن أن تُخصم أموالي مرتين بسبب التكرار؟”.
هذا النوع من التصميم لا يبدو مثيرًا عند الحديث عنه، ولا توجد نقاط تُلتقط لإرسالها كتغريدة. لكن العكس هو الصحيح: مدى صلابة تنفيذ هذه الآليات البسيطة هو نقطة البداية التي من خلالها أقيّم ما إذا كانت جذور السلسلة متينة أم لا، وليس نقطة النهاية.
برأيك عند تقييم مدى موثوقية سلسلة ما، هل يجب أن تبدأ من مثل هذه الآليات الأساسية البسيطة، أم أن تنظر أولًا إلى كم من التقنيات الجديدة والمبهرة تمتلكها؟
في الأنظمة المالية التقليدية، لمنع إعادة معالجة نفس التعليمة عدة مرات، يعتمد المرء على آلية بدائية لكن فعّالة: رقم تسلسلي أو رقم شيك. تمر كل تعليمة عبر رقم فريد، ويكتفي النظام بتسجيل الإرسال الأول؛ أما أي إرسال تكرر لاحقًا فيُرفض تلقائيًا. هذه الآلية “ترابية” وبسيطة إلى حد ما، لكن خلال عقود من الزمن كانت البنية التحتية المالية تعتمد على هذا الحل البدائي، وقد حال دون وقوع أغلب حوادث السداد/التصفية المكررة بسبب الأخطاء.
في نموذج حساب Moonlight الخاص بـ Dusk، يتم فعل الشيء نفسه تقريبًا: يحتفظ كل حساب بعدّاد nonce (عداد). يجب أن تكون كل معاملة جديدة رقمها nonce أكبر بمقدار 1 تمامًا عن nonce الحالي. وبعد الإرسال، يرتفع nonce. وبهذا، حتى لو تم بث نفس معاملة موقّعة بشكل متكرر أو إرسالها من جديد، فإن الشبكة ستقبل الإرسال الأول فقط، أما اللاحق فسيُرفض مباشرة. يبدو هذا التصميم أبسط ما يمكن—بسيط لدرجة أن كثيرين ربما لا ينتبهون لوجوده أصلًا—لكن هذه الآلية الأساسية، بالذات، هي ما يحدد ما إذا كانت السلسلة قادرة على أن يثق بها معالِجون ومؤسسات مسؤولة عن تسويات أموال حقيقية.
منذ أن دخلت هذا المجال قبل سنوات، رأيت أكثر من مرة حالات نتجت عن سوء التعامل مع التعليمات المكررة بسبب الأنظمة القديمة: تم خصم نفس التحويل أكثر من مرة، ثم اضطر الجميع لاحقًا إلى المرور بإجراءات مطوّلة للمطابقة والاسترداد. في التمويل التقليدي تُصنَّف هذه المشكلات غالبًا على أنها “حادث تشغيلي”، ولا تَظهر كثيرًا في الأخبار. لكن بالنسبة للمؤسسة المعنية والعميل، فإن التعامل معها ليس أمرًا هينًا. إذا كانت سلسلة هدفها خدمة تسويات المؤسسات لا تضع آلية منع إعادة الإرسال (replay) الأساسية هذه بشكل متين، فلن يكون لأي شيء آخر—حتى لو تراكمت عليه إثباتات معرفة صفرية—معنى كبير. المؤسسات لا تهتم بمدى تقدم التشفير لديك؛ أول سؤال هو: “هل يمكن أن تُخصم أموالي مرتين بسبب التكرار؟”.
هذا النوع من التصميم لا يبدو مثيرًا عند الحديث عنه، ولا توجد نقاط تُلتقط لإرسالها كتغريدة. لكن العكس هو الصحيح: مدى صلابة تنفيذ هذه الآليات البسيطة هو نقطة البداية التي من خلالها أقيّم ما إذا كانت جذور السلسلة متينة أم لا، وليس نقطة النهاية.
برأيك عند تقييم مدى موثوقية سلسلة ما، هل يجب أن تبدأ من مثل هذه الآليات الأساسية البسيطة، أم أن تنظر أولًا إلى كم من التقنيات الجديدة والمبهرة تمتلكها؟
A. 从基础机制看起,地基不稳一切白搭
100%
B. 看新技术,基础机制大家都差不多
0%
C. 两者都看,但基础机制该是一票否决项
0%
2 الأصوات • تمّ إغلاق التصويت