Finality

ما يراه بول أولًا هو أن محفظته علمت بالمعاملة. وهذا ليس إدراجها في كتلة. عندما تتكون الكتلة ثم تُبنى فوقها كتل أخرى، يصبح استبدال ذلك السجل محتاجًا إلى تجاوز مقدار أكبر من العمل. هكذا تقوى Finality عمليًا. لكن موارد المهاجم المحتمل وحالة الشبكة تظل مؤثرة. لا يصدر البروتوكول شهادة رياضية باستحالة الرجوع؛ على المستلم أن يقيّم قوة الأدلة التي يستند إليها لقبول دفعة بعينها. [1] [2]

تتحقق Full Node من قواعد Bitcoin بصورة مستقلة. ولا تقبل سجلًا لمجرد أنه طويل؛ تفحص صحته أولًا، ثم تختار من الفروع الصحيحة الفرع ذي أكبر عمل متراكم. المقصود هو العمل المثبت بالكتل، لا تصويت بحسب عدد الأشخاص أو ما يملكونه من عملات. زيادة العمل لا تجعل المعاملة غير الصحيحة صحيحة. لذلك يحتاج بول إلى الأمرين: التحقق من التزام الدفعة بالقواعد، ومعرفة مدى عمقها في السجل الصحيح المتبع حاليًا. [1]

في مثالنا تقع معاملة بول في الكتلة ذات الارتفاع ⁦800000⁩، ويبلغ ارتفاع طرف الفرع نفسه حاليًا ⁦800005⁩. الارتفاع هو موقع الكتلة، وليس وقتًا. نحسب ⁦800005 − 800000 + 1 = 6⁩ تأكيدات؛ فالكتلة التي تحمل المعاملة نفسها تدخل في الحساب. لسنا نعدّ فقط الكتل التي أضيفت بعدها. وإذا كانت الدفعة في mempool وحده، أي مجموعة المعاملات غير المؤكدة لدى تلك العقدة، فلديها ⁦0⁩ تأكيدات. الانتظار وحده لا يزيد العدد. [2] [3]

قد تعرف الشبكة كتلًا متنافسة لفترة وجيزة، ثم تتابع فرعًا صحيحًا آخر بعمل أكبر. يسمى هذا التغيير في السجل النشط إعادة تنظيم. في وثائق Bitcoin Core ⁦28.0⁩ يعيد استعلام ترويسة الكتلة getblockheader القيمة ⁦confirmations = -1⁩ عندما لا تكون الكتلة ضمن السلسلة النشطة. هذا وصف للكتلة، وليس إعلانًا عن فقدان كل دفعاتها. فقد تكون معاملة بول موجودة في الفرع الجديد أيضًا، أو تنتظر بلا تأكيد، أو تتعارض مع معاملة أخرى. لذا يجب فحص حالتها المحددة من جديد. [1] [3]

يذكر دليل المطورين ⁦6⁩ تأكيدات بوصفها عتبة شائعة للدفعات مرتفعة القيمة، ويشرح في الوقت نفسه ضرورة تقييم المخاطر. هذه قاعدة قبول يضعها المستلم، وليست لحظة تتغير عندها قواعد توافق Bitcoin. على بول مراعاة قيمة الدراجة والخسارة المحتملة وموثوقية التحقق؛ الرقم لا يقرر نيابة عنه. كما أن المتوسط القريب من ساعة لا يعني وصول ست كتل خلال ساعة في كل مرة. التعدين ليس له جدول ثابت، والتوصية العامة القديمة لا تضمن كل حالة. [2]

قد تكون لدى بول BTC مؤكدة، لكنه لا يزال مختلفًا مع المشتري بشأن تسليم الدراجة أو حالتها. تشترط PFMI، وهي المبادئ الدولية للبنى التحتية للأسواق المالية، تحديد لحظة واضحة للتسوية النهائية وحد لا يستطيع المشارك بعده إلغاء تعليماته. هذا إطار مختلف عن عدّ كتل Bitcoin. التأكيدات وحدها لا تحدد الأثر القانوني للعقد، ولا نهائية دفعة مصرفية، ولا انتقال ملكية السلعة. التحقق من الدفع مهم، لكنه لا يحل محل بقية شروط البيع. [4]

إذا اتفق بول والمشتري على رد المال، فعادةً يجري الرد بمعاملة جديدة يرسلها مستلم الدفعة الأصلية. ولا يختفي التحويل الأول من السجل. ليس لدى Bitcoin دعم مركزي يضغط زرًا لإلغاء دفعة مؤكدة بناءً على الطلب. إعادة التنظيم تغيّر السجل النشط للشبكة؛ وليست خدمة عملاء لتصحيح الأخطاء. لهذا يجب التحقق من المستلم والمبلغ قبل الإرسال. انتظار تأكيدات إضافية لا يصلح دفعة أُدخلت بياناتها خطأ. [5]

لا ينتهي عمل مشغّل تطبيق الدفع عند قبول الدفعة. ينبغي تسجيل المعاملة وكتلتها ومصدر التحقق، ورصد ما إذا كانت العقدة متأخرة عن الشبكة. قيمة confirmations تصف الحالة وقت الاستعلام، وليست شهادة دائمة. إذا انخفض العدد أو ظهر تعارض، يحتاج التطبيق إلى قواعد تعامل محددة مسبقًا وفحص جديد للفرع النشط. لقطة الشاشة القديمة ليست دليلًا جديدًا. والنتيجة العملية لبول هي اتخاذ القرار بحسب حالة دفعته الآن، لا فقط بحسب ما عرضته المحفظة في وقت سابق. [2] [3]