#dusk أثناء مراجعتي هذا الأسبوع لبيانات التفاعلات على السلسلة، كدت أقع في فخّ تصميم أساسي. عادةً ما نظن أن البيانات ما إن تُجمّع، يكفي الانتظار حتى يُضاف بضعة كتل لنضمن استقرارها تمامًا. بصراحة، كنت أتعامل مع الأمر بهذه العفوية أيضًا. لكنني قضيت الليلة الماضية أتمعّن في قواعد «النهائية المتدحرجة» (Rolling Finality) لدى Dusk، فأدركت فجأة أن هذا الانتظار العشوائي القائم على الحدس ينطوي على متغيرات خفية. $DUSK

تقسّم هذه الشبكة الحالات إلى مراحل دقيقة للغاية. ثمة قاعدة شديدة المكر: حتى لو أُنتجت الكتلة بسلاسة، فإن تعثّر إحدى الجولات قبل التوصل إلى الإجماع، أي وجود محاولات سابقة فاشلة، يجعل النظام يكتفي بمنحها وسم القبول المبدئي. هذه الحالة أشبه بعامل مؤقت؛ فمن الممكن نظريًا أن تحلّ محلها في أي لحظة بيانات مرشحة ذات ترتيب أفضل. أما الحصول على اعتماد نهائي، فقواعده أشد صرامة بكثير مما قد تظن. $BTC

الحساب هنا لا يقوم ببساطة على انتظار عدد ثابت من الكتل، بل يتطلب انتظار ضعف عدد المحاولات الفاشلة. لنفترض أن العملية تعثرت مرتين في البداية؛ عندها يجب انتظار أربع كتل جديدة بعد ذلك حتى تُعتمد نهائيًا. وهذا يعني أن معاملتي تحويل كلتيهما مسجلتان على السلسلة قد تختلفان تمامًا من حيث مقاومة الإلغاء: إحداهما أُنجزت بسلاسة، والأخرى بعد تعثرات متكررة. والفارق بينهما في مستوى الهشاشة واضح جدًا. $ETH

من منظور المؤسسات التي تجري تسويات التسليم مقابل الدفع (DvP)، يُعد هذا المنطق الوقائي الديناميكي محكمًا بالفعل، لكنه يعني أيضًا أن وقت التأكيد يصبح مجهولًا. لا تشكّل المخاطر خلال تلك الثواني أهمية تُذكر للاعبين العاديين الذين يجرون تحويلات صغيرة ومتكررة للتسلية. لكن حين يتعلق الأمر بتحويل مبالغ كبيرة، فمن الأفضل التعامل بحذر مع هذه الآلية. لكل شيء وجهان؛ فتعزيز الأمان إلى أقصى حد يعني بطبيعة الحال التنازل عن شيء من الكفاءة المتوقعة. @Dusk

أما الآن، فعندما أجري تحويلات كبيرة بنفسي، لا أتمسك أبدًا بعدد ثابت من التأكيدات؛ بل أراجع العقدة مباشرةً لمعرفة قيمة n المحددة. أفضّل الانتظار مدة أطول على أن أخاطر قبل تجاوز فترة الهشاشة. بصراحة، إن فهم بعض آليات النظام الأساسية يجنّبك كثيرًا من الفخاخ الخفية. عند إجراء تحويلات كبيرة، ما المرحلة التي تقلقكم أكثر؟