37 / 691CONF

تأكيد

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

عدد الالتزام هو حالة مشتقة، وليس حقلاً مخزنًا في المعاملة. إذا كانت المعاملة تكمن في كتلة ارتفاعها h وكان طرف السلسلة النشطة هو H، فإن عمقها هو H − h + 1. المعاملة في مجمع الذاكرة ليس لها أي التزام؛ يمكن أن تعرض Bitcoin Core قيمة سلبية لمعاملة المحفظة المتضاربة، مما يشير إلى عمق التضارب.

الإرسال ليس تأكيدًا. تطبق كل عقدة بشكل مستقل سياسة القبول في مجمع الذاكرة الخاص بها، وقد ترى العقد المختلفة مجموعة مختلفة بسبب الوقت أو الرسوم أو التعارضات أو حدود الحزمة أو الإعدادات. يمكن لـ RBF أن يحل محل معاملة غير مؤكدة ويمكن أن تختفي الدفعة التي شاهدها التاجر دون الدخول في الكتلة. لذا فإن تقنية Zero-conf تتاجر بالسرعة مقابل خطر الإنفاق المزدوج وعرض الشبكة غير المكتمل؛ لا تعتبر صفحة txid ولا صفحة المستكشف مستوطنات. [دليل مطور البيتكوين - المعاملات] [Bitcoin Core - تناسق JSON-RPC] [BIP 125 - الاشتراك في الاستبدال الكامل برسوم]

يمكن للقائم بالتعدين تحديد معاملة في كتلة مرشحة، ولكن التأكيد الأول يحدث فقط عندما تقبل عقدة التحقق الكتلة وتقع الكتلة في سلسلتها النشطة مع أكبر سلسلة عمل. تتحقق العقدة الكاملة من إثبات العمل والبرامج النصية ووجود المدخلات وعدم إنفاقها والمبالغ وقواعد الإجماع الأخرى؛ لا يمكن للقائم بالتعدين استرداد إنفاق غير صالح بمجرد الإدراج. يُلزم جذر Merkle المعاملة بالكتلة والإشارة إلى الكتلة السابقة تضعها في إثبات سجل العمل. [بيتكوين الأساسية - التحقق من الصحة] [بيتكوين الأساسية - التحقق من صحة.cpp]

إذا كانت كتلة المعاملة على ارتفاع h والطرف الحالي للعقدة هو H، يكون العد H − h + 1: يتم حساب الكتلة نفسها أولاً. يتم إنشاء القيمة مقابل أفضل كتلة تم التحقق منها لتلك العقدة، لذلك قد يختلف الطرف قليلاً بين العقد. لا يتم كتابته في معاملة، ولا ينمو بمرور الوقت، ولا يمكن تحديده بشكل موثوق من خلال الطابع الزمني. تقوم Bitcoin Core بإرجاع البلوك هاش وارتفاع البلوك والتأكيدات كحالة المحفظة أو عرض UTXO. [دليل مطوري البيتكوين - سلسلة الكتل] [Bitcoin Core RPC - gettransaction] [Bitcoin Core RPC - getbestblockhash]

إذا حصل فرع صالح منافس على المزيد من السلسلة، فستقوم العقدة بفصل كتل الطرف القديم وإرفاق الفرع الفائز. قد تعود المعاملة من كتلة منفصلة إلى مجمع الذاكرة إذا ظلت صالحة، أو يتم الالتزام بها على ارتفاع مختلف، أو تصبح متعارضة لأن فرعًا جديدًا قد أنفق نفس المدخلات. التأكيدات السلبية في Bitcoin Core هي عبارة عن اتفاقية محفظة لعمق الصراع، وليست كتلًا سلبية متفق عليها. [Bitcoin Core RPC - gettransaction] [Bitcoin Core - validation.cpp]

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

الحساب مطلوب من قبل المستلم أو البورصة أو بروتوكول المصب، وليس المعاملة نفسها. القهوة، والإصدار غير القابل للإرجاع من السلع باهظة الثمن، وودائع البورصة وفتح القنوات لها نسب خسارة وانتظار مختلفة. يجب أن تأخذ السياسة في الاعتبار القيمة وقابلية عكس الأداء والتحفيز ومعدل التجزئة للمهاجم والصراعات أو RBF والحضانة والواجهة الخلفية ومخاطر الكسوف والحالة غير العادية للسلسلة. التأكيد يخفف من خطر الكتابة فوق السلسلة؛ لن يتم إصلاح المفتاح المسروق أو العنوان الخاطئ أو الاحتيال من الطرف المقابل. [BIP 125 - الاشتراك في الاستبدال الكامل بالرسوم] [روزنفيلد - تحليل الإنفاق المزدوج القائم على التجزئة]

تهدف Bitcoin إلى متوسط ​​حوالي عشر دقائق بين الكتل، ولكن وصول إثبات العمل يكون عشوائيًا: يمكن أن تصل الكتلة التالية في ثوانٍ أو ساعات. يمكن أن تؤدي الرسوم الأعلى إلى تحسين ترتيب اختيار المعدنين واقتصاد الحزمة RBF أو CPFP، ولكن لا توجد رسوم تشتري وقتًا محددًا ولا تسرع من إنشاء الكتل. قد تنتظر المعاملة الرخيصة العديد من الكتل أو تتم إزالتها من مجمع الذاكرة؛ التقدير هو احتمال، وليس موعدا نهائيا. [دليل مطور البيتكوين – سلسلة الكتل] [دليل مطور البيتكوين – المعاملات]

تتحقق العقدة الكاملة من صحة السلسلة وتستجيب وفقًا للطرف النشط الخاص بها. يتحقق عميل SPV من إثبات العمل في الرؤوس وإدراج إثبات Merkle، لكنه لا يقوم بتشغيل جميع قواعد الإجماع بنفسه؛ تضيف خدمة الحفظ أيضًا سياسة الائتمان والمخاطر الخاصة بها. حتى نتيجة RPC للعقدة الكاملة هي لقطة يمكن تغييرها عن طريق إعادة التنظيم. لذا فإن السؤال ليس فقط "كم عدد التأكيدات"، ولكن أيضًا لمن يثق المستخدم في طريقة العرض التسلسلية والتحقق من صحتها وحمايتها. [مستند عمل البيتكوين - إثبات العمل والحسابات] [البيتكوين الأساسي - التحقق من الصحة] [البيتكوين الأساسي - اتساق JSON-RPC]

تبدأ الفصول الأخرى أيضًا بالتأكيد. يخضع ناتج Coinbase لـ COINBASE_MATURITY = 100 ولا يمكن إنفاقه إلا بعد 100 كتلة جديدة؛ هذه قاعدة مختلفة عن سياسة الدفع العادية. تقيس الأقفال الزمنية النسبية BIP68، التي يتم فرضها بواسطة البرنامج النصي BIP112 CHECKSEQUENCEVERIFY (CSV)، العمر من كتلة التزام الإخراج. الوالد غير المؤكد يبقي أحفاده معتمدين؛ لكي يتم تأكيد الطفل، يجب أن يكون أسلافه في نفس المجموعة أو أكبر. [بيتكوين كور — توافق الآراء.h] [BIP 112 — التحقق من التسلسل]

يسمح BOLT 2 لمستقبل قناة Lightning باختيار الحد الأدنى من معاملات التمويل قبل أن تكون القناة جاهزة؛ الرقم يمثل تمويل مخاطر الإنفاق المزدوج. تقوم قناة صفرية بضبط الحد الأدنى للعمق على الصفر وتعتمد بوعي على ثقة الصندوق وقيود البروتوكول بدلاً من النهاية المباشرة. تمويل Coinbase في انتظار التسجيل. يجب على المشغل مراقبة نقطة التمويل الخارجية وعمق السلسلة النشطة وعمليات إعادة التنظيم، وعدم اعتبار txid المرسل كقناة مفتوحة. [BOLT 2 - بروتوكول النظير] [Bitcoin Optech - قنوات صفرية]

للحصول على صورة أوضح، اقرأ هذا المدخل مع الكتلة, المعاملة, Reorg, الإنفاق المزدوج, Proof of Work, Bitcoin. تشير إلى هذا المدخل أيضًا الإنفاق المزدوج, معاملة كوينبيس, Reorg, Stale Block.

DOC · 001Bitcoin whitepaper — Proof-of-Work and Calculationsتوثيق ↗DOC · 002Bitcoin Core — Validationتوثيق ↗DOC · 003Bitcoin Developer Guide — Block Chainتوثيق ↗DOC · 004Bitcoin Developer Guide — Transactionsتوثيق ↗DOC · 005Bitcoin Core RPC — gettransactionتوثيق ↗DOC · 006Bitcoin Core RPC — getbestblockhashتوثيق ↗DOC · 007Bitcoin Core — validation.cppتوثيق ↗DOC · 008Bitcoin Core — JSON-RPC consistencyتوثيق ↗DOC · 009Bitcoin Core — consensus.hتوثيق ↗DOC · 010BIP 112 — CHECKSEQUENCEVERIFYمواصفة ↗DOC · 011BIP 125 — Opt-in Full Replace-by-Feeمواصفة ↗DOC · 012BOLT 2 — Peer Protocolمواصفة ↗DOC · 013Rosenfeld — Analysis of Hashrate-Based Double Spendingتوثيق ↗DOC · 014Bitcoin Optech — Zero-conf channelsتوثيق ↗
تمت المراجعة في 1 أغسطس 2026المصادر أولًا · ليست نصيحة استثمارية