AssumeUTXO

يشغّل بيتر أول Full Node له، أي برنامجًا يتحقق بنفسه من قواعد Bitcoin. تجمع الكتلة معاملات في دفعة تُضاف إلى السجل المشترك. يتطلب البدء المعتاد معالجة تاريخ طويل أولًا. يتيح AssumeUTXO الانطلاق من مجموعة UTXO مُعدّة مسبقًا: مخرجات معاملات لم تُنفَق بعد، يحدد كل منها مبلغًا وشروط إنفاقه. تمثل اللقطة الحالة بعد كتلة بعينها. ليست أرشيفًا لجميع المدفوعات ولا دليلًا على أن حاسوب بيتر قد تحقق بالفعل من الماضي كله. [1] [3]

اسم الملف لا يجعل اللقطة صحيحة. عند تحميلها بواسطة loadtxoutset، يتحقق Bitcoin Core v29.0 من التنسيق والكتلة الأساسية (الكتلة التي تمثل اللقطة حالتها) والمعلمات المدعومة. ويحسب أيضًا hash لمحتوى UTXO، أي بصمته التشفيرية، ثم يقارنه بالقيمة المتوقعة قبل التفعيل. لذلك لا يمر محتوى معدّل بالفحص لمجرد أن شخصًا أعطى الملف اسمًا يوحي بالثقة. [2] [3] [6]

بعد قبول اللقطة، تتابع العقدة من حالتها وتتحقق من الكتل اللاحقة، ويمكن أن تصل إلى النهاية الحالية للسلسلة. لا تقبلها بلا فحص: تظل شروط الإنفاق والحدود المسموحة لإنشاء بيتكوين جديد خاضعة للتحقق. الميزة أن هذا المسار نحو النشاط الحالي لا يحتاج إلى انتظار اكتمال التاريخ الأقدم. لكن ذلك لا يعني أن الماضي قد خضع بالفعل للتحقق المحلي. [1] [6]

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

تنتمي قيمة hash المتوقعة والكتلة الأساسية المدعومة إلى إصدار محدد من البرنامج. وإلى أن تحسب عقدة بيتر التاريخ بنفسها، فإنها تعتمد على صحة تلك المعلومة المدمجة. تتيح مقارنة قيم hash التحقق من تطابق المحتوى، لكنها لا تثبت وحدها أنه ناتج عن سجل صحيح. ولو كانت الحالة المتوقعة خاطئة، لاعتمد الاستخدام المبكر للعقدة على ذلك الافتراض الخاطئ. لهذا يجب التمييز بين التحقق التاريخي اللاحق وفحص الملف عند تحميله. [2] [6]

قد يأتي الملف من مشغّل آخر، لكن ذلك لا يمنحه سلطة اختيار الحالة المقبولة. المعيار هو مطابقة القيمة التي يدعمها البرنامج، لا وعد المزوّد. كذلك لا يمكن تحميل أي لقطة من أي كتلة؛ فالدعم يعتمد على الإصدار والشبكة. وفحص hash لا يضمن وصول الملف، ولا يلغي ما يستهلكه تنزيله ومعالجته من وقت واتصال ومساحة قرص. [2] [4] [7]

عندما يصل العمل في الخلفية إلى الكتلة الأساسية نفسها، تحسب العقدة hash لمجموعة UTXO التي بنتها وتقارنه بالبصمة المتوقعة للقطة. ليست مقارنة لحالة اليوم بصورة قديمة؛ فالطرفان يمثلان النقطة نفسها في التاريخ. وإذا اختلفا، يوقف التنفيذ الموصوف هنا العقدة ويتوقف عن استخدام الحالة المشتقة من اللقطة. لا يخفي الاختلاف ولا يعلنه تحققًا ناجحًا. [1] [6]

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

تحتوي مجموعة UTXO معلومات عن المخرجات غير المنفقة، لا المفاتيح الخاصة التي تجيز الإنفاق. يثبت التوقيع الرقمي الإذن بالدفع باستخدام مفتاح خاص، وهو قيمة عددية سرية، دون الكشف عن المفتاح. مجموعة UTXO ليست نسخة احتياطية للمحفظة ولا تستعيد Seed Phrase مفقودة، أي كلمات الاستعادة لمحفظة تستخدم هذه الآلية. وقد لا تظهر المدفوعات القديمة فورًا أيضًا، لأن العثور عليها قد يتطلب كتلًا أقدم من اللقطة. نسخ المفاتيح احتياطيًا والبحث في تاريخ محفظتك والتحقق من حالة الشبكة مهام مختلفة. [1] [7]

قد يسبب تشابه الاسمين التباسًا. يبدأ AssumeUTXO من حالة محمّلة ويعيد بناء التاريخ الأقدم في الخلفية. أما assumevalid فيمكنه، بشروط محددة، تجاوز جزء من الفحوص التاريخية للسكربتات، أي شروط الإنفاق بما فيها التواقيع. إنه تحسين منفصل قد يؤثر أيضًا في التحقق التاريخي؛ واكتمال AssumeUTXO وحده لا يعني أنه كان معطّلًا. عند قراءة دليل، ميّز بين نقطة بداية العقدة وما تتحقق منه فعليًا وموعد انتهاء كل فحص. [5] [6]