النهائية في البلوكتشين: متى تنتهي المعاملة حقًّا؟

المقال كاملًا

أوّل سؤال يُطرَح عند بناء نظام يقبل الدفع على سلسلة كتل هو عادةً: كم تستغرق المعاملة حتى تُؤكَّد؟ وهذا ليس السؤال الصحيح. السؤال الصحيح: كم تستغرق حتى تصير غير قابلة للعكس؟

والفجوة بين الاثنين هي الفرق بين قبض ثمن قهوة وقبض ثمن سيّارة.

التأكيد ليس النهائية

دخول المعاملة في كتلة تأكيدٌ. لكنّ تلك الكتلة قد تفقد صلاحيتها في بعض السلاسل إن ظهرت على الشبكة سلسلة أطول، فتُعكَس المعاملات التي فيها. فالتأكيد الأوّل إذن ليس ضمانًا بل قولًا احتماليًّا.

ومع مرور الوقت وتراكم الكتل فوقها يتقلّص احتمال العكس — لكنّه لا يبلغ الصفر نظريًّا أبدًا. وهذا ما يُسمّى النهائية الاحتمالية: «انتظر مدّة كافية يصر الأمر آمنًا بما يكفي».

ماذا تغيّر النهائية الحتمية

في بعض تصاميم الإجماع تصير الكتلة نهائية لحظة موافقة أغلبية المدقّقين عليها، ولا يمكن عكسها. والانتظار هنا بلا فائدة: فإمّا أن تكون المعاملة نهائية وإمّا أنّها لم تقع أصلًا. وتزول المنطقة الرمادية.

لماذا يهمّ هذا كثيرًا في جانب الدفع

إن كنت تسلّم سلعة مادّية أو تفتح خدمة فورًا، فقد قبلت دفعة قابلة للعكس. ويُسمّى هذا في عالم البطاقات التقليدي «ردّ المبلغ»، وتدير المتاجر هذا الخطر منذ سنين. أمّا على السلسلة فالخطر يتوقّف على نموذج النهائية في الشبكة التي اخترتها.

والبند الأخير من جانب المنتج وهو أكثرها إغفالًا. فشاشة تقول «جارٍ المعالجة» دون إخبار المستخدم كم سينتظر تجربةٌ سيّئة مهما كان الانتظار الفعليّ قصيرًا.

التوافق محور منفصل

نموذج النهائية وبيئة التطوير خياران مستقلّان. فقد تقدّم شبكة نهائية سريعة وحتمية وتكون في الوقت نفسه متوافقة مع EVM، وعندئذٍ تعمل عقود Solidity والمحافظ وأدوات التطوير القائمة كما هي.

وهذا يفصل عمليًّا القرار المعماريّ عن الفريق: فتختار نموذج النهائية الذي تقتضيه بنيتك، ويواصل الفريق العمل بالأدوات التي يعرفها.

باختصار

من المصطلحات: الحسم النهائي · التوافق مع EVM

← كل المقالات