getblocktemplate

في الوضع المعتاد ⁦mode=template⁩، يتلقى برنامج بيتر مثلًا الكتلة السابقة والمعاملات والمكافأة المسموح بها. هذه خطة للعمل، وليست كتلة عُثر عليها بالفعل. على البرنامج إنشاء coinbase، المعاملة الأولى الخاصة التي تخصص المكافأة، وإكمال تجميع الكتلة. ترويسة الكتلة ملخص موجز لبياناتها. بعد ذلك يبحث البرنامج عن hash، بصمة تشفيرية عددية لهذه الترويسة، تحقق هدف التعدين وتكون Proof of Work، أي دليلًا على العمل الحسابي. لا يستقبل getblocktemplate نفسه عنوانًا للدفع ولا يبدأ حسابات جهاز التعدين. لذلك لا يعني الرد الناجح أن بيتر بدأ التعدين بالفعل. [1]

لنتخيل أن العقدة ترسل بيانات بصيغة لا يفهمها برنامج بيتر. لذلك يذكر الطلب القواعد المدعومة في الحقل rules. يتطلب ⁦Bitcoin Core v29.0⁩، الإصدار الذي تحققنا منه هنا، segwit، ويطلب signet أيضًا لشبكة الاختبار Signet. يغير SegWit، من بين أمور أخرى، طريقة التعامل مع بيانات التحقق من المعاملات. لا تكفي إضافة الكلمة الصحيحة؛ يجب أن يستطيع البرنامج معالجة هذه البيانات فعلًا. يعلن capabilities قدرات أخرى للواجهة ولا يحل محل rules. وتعتمد المتطلبات الدقيقة على التنفيذ والإصدار المستخدمين. [2]

يحتوي حقل data على المعاملة كاملة مرتبة للنقل بين البرامج. يسمى هذا الترتيب تسلسل البيانات. وتُمثّل البايتات، وهي الوحدات الأساسية لهذه البيانات، بالنظام الست عشري باستخدام الأرقام ⁦0–9⁩ والحروف ⁦a–f⁩. ويتضمن الرد أيضًا معرفات قصيرة للمعاملات. وفق الوثيقة التقنية ⁦BIP 145⁩، يُحسب txid دون بيانات witness، بينما يشملها hash. تتضمن witness مثلًا تواقيع تثبت صلاحية إنفاق الأموال. ويستخدم Merkle root الرئيسي، البصمة الجامعة للمعاملات في ترويسة الكتلة، txid وليس witness hash. الخلط بين الحقول ليس مجرد خطأ في الاسم؛ فقد ينتج بصمة جامعة خاطئة ويجعل الكتلة المجمعة غير صالحة. [3]

لا يحتاج بيتر إلى إغراق العقدة بأسئلة عما إذا كان شيء قد تغير. يبقي Long polling الطلب مفتوحًا إلى أن يريد الخادم استبدال البيانات السابقة. يأخذ البرنامج longpollid ويعيد إرساله دون تغيير. وتُبيّن هذه القيمة للخادم التغيير الذي ينتظره البرنامج. ويجب ألا يحاول البرنامج استنتاج معنى معين من حروف هذه القيمة وأرقامها. ينص ⁦BIP 22⁩ على مهلة انتظار طويلة. وإذا تكررت الردود الناقصة أو غير الصالحة، يجب ترك فاصل بين المحاولات بدل تكرارها فورًا في حلقة. لذا فإن الانتظار الصامت ليس في حد ذاته عطلًا. [4]

حتى تكرار الطلب العادي لا يضمن اختيار محتوى جديد. يحتفظ ⁦Bitcoin Core v29.0⁩ بقالب جاهز في الذاكرة المؤقتة. يعيد بناءه إذا تغيرت الكتلة السابقة، أو إذا تغير mempool، مجموعة المعاملات المحلية غير المؤكدة، ومضى أكثر من خمس ثوانٍ منذ الإعداد. ويمكنه تحديث وقت الترويسة بصورة مستقلة. لذلك قد يتلقى بيتر المجموعة نفسها من المعاملات مرة أخرى؛ وهذا لا يعني توقف العقدة. كما أن سلوك هذا الإصدار المحدد لا يَعِد بمهمة تعدين فريدة مع كل استدعاء. [2]

غيّر بيتر طريقة تجميع الكتلة ويريد اكتشاف الأخطاء قبل بدء بحث يستهلك موارد كثيرة. في وضع proposal، يقدم الكتلة كاملة مكتوبة بالنظام الست عشري في data. يفحص ⁦Bitcoin Core v29.0⁩ أيضًا Merkle root، لكنه لا يشترط العثور مسبقًا على Proof of Work صالح، أي إثبات للعمل الحسابي. إذا لم يَبْنِ الاقتراح على آخر كتلة في السلسلة التي تتبعها العقدة حاليًا، يعيد ⁦inconclusive-not-best-prevblk⁩. هذا يعني أن شرطًا مسبقًا لهذا الفحص غير متحقق، وليس تقييمًا كاملًا لصلاحية الاقتراح. ولا ينشر الفحص الأولي الكتلة على الشبكة أيضًا. [2]

بعد العثور على إثبات العمل المطلوب، يستطيع البرنامج تقديم الكتلة كاملة عبر submitblock. يحمل hexdata الكتلة المتسلسلة كاملة بالنظام الست عشري، لا ترويستها أو بصمتها فقط. تحدد وثائق ⁦Bitcoin Core 29⁩ النتيجة null عند القبول، ونتيجة نصية وفق المواصفة في الحالات الأخرى. يُتجاهل المعامل الثاني الاختياري dummy؛ فهو لا يحدد المكافأة. قبول العقدة لا يضمن تأكيدًا دائمًا، إذ قد يغير تطور السلسلة لاحقًا الفرع الذي يبقى رئيسيًا. [5]

قد لا تكون العقدة التي بدأت العمل للتو قد نزّلت السجل اللازم وتحققت منه بعد. على الشبكة الرئيسية mainnet، يرفض ⁦Bitcoin Core v29.0⁩ إصدار قالب إذا لم توجد عقد نظيرة متصلة أو أثناء المزامنة الأولية IBD ⁦(initial block download)⁩. المسألة هنا جاهزية العقدة للعمل مع الشبكة الحالية، لا رفض كتلة معينة. عند تشخيص المشكلة نميز إذن بين long poll ينتظر، وعقدة غير جاهزة، ونتيجة فحص اقتراح. قد تبدو كلها كأنها «لا يوجد عمل جديد»، لكن لكل منها معالجة مختلفة. [2]