التأكيد

ترسل أليس إلى صديقها 20 000 sat، وهي أصغر وحدات البيتكوين. تعرض محفظتها «أُرسلت»، ويرى صديقها الدفعة الواردة بالفعل، لكن بعدد تأكيدات صفر. لا تناقض هنا: انتشرت معلومات الدفعة بين العقد، أي الحواسيب التي تتحقق من البيتكوين، لكنها لم تدخل كتلة بعد. وMempool مخزن محلي للمعاملات غير المؤكدة لدى عقدة، وليس طابورًا واحدًا للشبكة كلها. عندما تدخل الدفعة كتلة مقبولة تحصل على التأكيد الأول، ثم تمنحها الكتلة التالية الثاني والتي بعدها الثالث. لا تحتاج أليس إلى الإرسال مرة أخرى. نشر المعاملة ليس تأكيدًا، ولا يضمنه معرّفها txid أيضًا. قد تُستبدل معاملة غير مؤكدة، مثلًا باستخدام Replace-by-Fee (RBF) لزيادة الرسم. يُسمّى قبول دفعة دون تأكيد zero-conf، ويعني تحمل احتمال أن يتأكد بدلًا منها إنفاق آخر للأموال نفسها. [4] [8] [11]

يختار المعدّن معاملات لكتلة جديدة ويبحث عن Proof of Work صالح، أي نتيجة الحسابات المكلفة التي تشترطها قواعد البيتكوين. ثم تتحقق العقد الكاملة الأخرى من الكتلة بنفسها: هل التوقيعات والمبالغ وشروط الإنفاق صحيحة، وهل ما زالت الأموال غير منفقة؟ ليس ذلك تصويتًا للمعدّنين ولا ختم موافقة من شركة واحدة. لا يستطيع المعدّن جعل دفعة غير صالحة صالحة بمجرد إدراجها في كتلة. تحتسب العقدة التأكيد فقط ضمن السلسلة التي تقبلها. وتختار بين الفروع الصالحة ما يملك أكبر عمل متراكم، المسمّى chainwork. تشير كل كتلة إلى سابقتها؛ لذا يتطلب تغيير السجل القديم إعادة بناء ما يليه أيضًا. [2] [7]

يستهدف البيتكوين متوسط عشر دقائق بين الكتل، لا جدول مواعيد. قد تصل كتلة جديدة خلال ثوانٍ أو بعد وقت أطول بكثير. وانتظار ساعة لا يعني بذاته الحصول على ستة تأكيدات. قد يزيد معدل الرسم الأعلى فرصة اختيار المعدّن لمعاملتك، لكنه لا يسرّع إنتاج الكتل. تتيح بعض المحافظ RBF، أي استبدال معاملة غير مؤكدة بأخرى تدفع رسمًا أعلى، أو CPFP (Child Pays for Parent): تضيف معاملة لاحقة تعتمد على السابقة رسومًا تكفي لجعل إدراجهما معًا مجديًا للمعدّن. يعتمد توفر ذلك على المحفظة والمعاملة. وقد يعني الرسم المنخفض انتظارًا طويلًا أو إزالة المعاملة من Mempool لدى عقدة. تعامل مع تقدير المحفظة بوصفه تقديرًا، لا موعدًا مضمونًا. [3] [4]

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

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

قد يحدث تفرع قصير دون هجوم إذا وجد معدّنان كتلة في وقت متقارب جدًا. ويُسمّى انتقال العقدة إلى فرع فائز آخر إعادة تنظيم. يسجل مخرج المعاملة مبلغًا وشروط إنفاقه، ويشير مدخل في معاملة لاحقة إلى ذلك المخرج وينفقه. ويُسمّى المخرج غير المنفق UTXO. إذا راكم فرع منافس صالح عملًا أكثر، أي chainwork أكبر، تفصل العقدة الكتل الواقعة في نهاية السلسلة الأصلية وتصل الفرع الفائز. قد تعود معاملة من كتلة فُصلت إلى Mempool إذا بقيت صالحة، أو قد تحصل على تأكيد عند ارتفاع مختلف. وقد تصبح أيضًا متعارضة إذا أنفق الفرع الجديد المخرج نفسه الذي يشير إليه مدخلها. القيمة السالبة للحقل confirmations في Bitcoin Core هي طريقة المحفظة للتعبير عن عمق التعارض، ولا تعني وجود عدد سالب من الكتل في قواعد الإجماع. [5] [7]

ارتفاع الكتلة هو موضعها في الترتيب، بدءًا من الكتلة الأولى ذات الرقم صفر. إذا كانت كتلة المعاملة عند الارتفاع h، وآخر كتلة في السلسلة النشطة لدى العقدة عند الارتفاع H، فإن عدد التأكيدات هو H − h + 1. وهكذا تُحسب الكتلة التي تتضمن المعاملة نفسها كتأكيد أول. تعتمد النتيجة على أفضل كتلة تحققت منها تلك العقدة، ولذلك قد تختلف الأعداد قليلًا بين العقد أثناء وصول كتل جديدة. هذا العدد ليس جزءًا من المعاملة، ولا يزيد لمجرد مرور الوقت، ولا يمكن استنتاجه بصورة موثوقة من الطابع الزمني. يعيد Bitcoin Core بيانات مثل blockhash وblockheight وconfirmations بحسب الحالة التي تعرفها المحفظة المعنية أو الصورة المتاحة لديها عن UTXO. [3] [5] [6]

SPV هو التحقق المبسط من الدفع، أما RPC فواجهة برمجية للاستعلام من العقدة. ويظل اختلاف طرق التحقق مهمًا حتى إن عرض تطبيقان العدد نفسه. تتحقق العقدة الكاملة من السلسلة وتجيب وفق النهاية الحالية للسلسلة التي تحققت منها. يفحص عميل SPV قيمة Proof of Work في رؤوس الكتل ودليل Merkle على إدراج المعاملة، لكنه لا يتحقق بنفسه من جميع قواعد الإجماع. يستخدم دليل Merkle مجموعة صغيرة من البصمات التشفيرية للبيانات لإثبات وجود المعاملة في كتلة، دون تنزيل جميع معاملات تلك الكتلة. أما الخدمة التي تحتفظ بالأموال نيابة عن المستخدم فتطبق أيضًا قواعدها الخاصة لقيد الدفعات وإدارة المخاطر. حتى نتيجة RPC من عقدة كاملة تصف حالة في لحظة معينة، وقد تغيرها إعادة التنظيم. لذلك لا يهم عدد التأكيدات وحده، بل أيضًا الجهة التي يثق المستخدم في رؤيتها للسلسلة وتحققها من صحتها وحفظها للأموال. [1] [2] [8]

Coinbase Transaction هي المعاملة الأولى الخاصة في الكتلة، وتدفع مكافأة المعدّن؛ ولا علاقة لها بمنصة Coinbase. يقيّد القفل الزمني موعد إمكان إنفاق الأموال. وBIP وثيقة اقتراح تقني أو معيار. يبدأ التأكيد أيضًا بعض فترات الانتظار التي يحددها البروتوكول. يخضع مخرج معاملة coinbase لقاعدة COINBASE_MATURITY = 100: يمكن إنفاقه، في أقرب وقت، ضمن كتلة يزيد ارتفاعها بمقدار 100 عن ارتفاع الكتلة التي تضمنت معاملة coinbase تلك. هذه فترة انتظار إلزامية قبل إنفاق مكافأة الكتلة، وليست اختيارًا لمستلم دفعة عادية. تستند الأقفال الزمنية النسبية في BIP68 إلى تأكيد المخرج المراد إنفاقه، وتقيّم المدة التي مضت عليه وفق قواعد للكتل أو للوقت. السكربت برنامج قصير يحدد شروط إنفاق المخرج. يتيح الأمر CHECKSEQUENCEVERIFY (CSV) من BIP112 فرض هذا الشرط النسبي داخل السكربت. تظل المعاملة التي تنفق مخرجًا غير مؤكد معتمدة على المعاملة التي أنشأته. ولكي تحصل المعاملة اللاحقة على تأكيد، يجب إدراج المعاملات التي تعتمد عليها في الكتلة نفسها أو في كتلة سابقة. [9] [10]

تتيح Lightning Network الدفع عبر قنوات تموّلها معاملات بيتكوين. وBOLT اسم مواصفاتها التقنية؛ الحديث هنا عن فتح قناة، لا عن انتظار كتلة لكل دفعة داخلها. يتيح BOLT 2 للطرف الذي يقبل قناة Lightning أن يحدد في الحقل minimum_depth عدد التأكيدات المطلوبة لمعاملة التمويل قبل إرسال رسالة channel_ready. يراعي هذا الشرط خطر الإنفاق المزدوج للتمويل. تضبط القناة المفتوحة دون تأكيد، أي zero-conf channel، قيمة minimum_depth على الصفر، وتعتمد عن قصد على الثقة بمقدم التمويل وعلى قيود البروتوكول. ولا تحصل بذلك على تسوية فورية لا رجعة فيها. إذا كانت معاملة التمويل نفسها معاملة coinbase، فإن BOLT 2 يُلزم الطرف الذي لا يفتح القناة بالانتظار 100 كتلة على الأقل. على المشغّل مراقبة مخرج التمويل المحدد، أي funding outpoint، وعمقه في السلسلة النشطة وإعادات التنظيم. مجرد نشر txid لا يعني أن القناة أصبحت مفتوحة. [12] [14]