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