Block Template

تُبنى كل كتلة جديدة على سابقتها المحددة. يعرّفها القالب عبر ⁦previousblockhash⁩، بصمتها الفريدة، بينما يحدد ⁦height⁩ موقع الكتلة المقترحة في السلسلة. وتشمل الحقول الأخرى ⁦version⁩، إصدار الترويسة، و⁦bits⁩، الترميز المختصر للهدف الذي يجب أن تحققه نتيجة التعدين، وبيانات الوقت. هذه معطيات لبناء كتلة بعينها، وليست قائمة مدفوعات مستقلة. وضع المعاملات نفسها بعد كتلة سابقة مختلفة يصنع تكليفًا مختلفًا بالفعل. [1]

تتلقى آنا بيتكوين ثم تدفع به. إذا أُريد إدراج التحويلين في الكتلة نفسها، فلا بد من وضع المعاملة التي أعطتها الأموال أولًا، ثم المعاملة التي تنفقها. تعرّف ⁦BIP 22⁩، وهي وثيقة تقنية تصف تنسيق القالب، هذه الروابط بحقل ⁦depends⁩، الذي يشير إلى عناصر سابقة في قائمة ⁦transactions⁩ بترقيم يبدأ من الواحد. لا تضم القائمة ⁦coinbase⁩، المعاملة الأولى الخاصة التي تخصص مكافأة المعدّن. غياب ⁦depends⁩ يعني أن التبعيات غير معروفة، لا التأكد من عدم وجودها. لذلك لا يجوز للبرنامج اعتبار المعلومة المفقودة قائمة فارغة. [1]

تشمل المكافأة البيتكوين المُصدر حديثًا وفق قواعد ذلك الارتفاع ورسوم المعاملات المدرجة فعلًا. ويحسبها ⁦Bitcoin Core v29.0⁩ المشار إليه بالطريقة نفسها. يتحقق هذا البرنامج من الكتل والمعاملات، ويمكنه أيضًا إعداد قوالب للتعدين. في مثالنا، توفر المعاملات ⁦10000 sats⁩؛ وبعد حذف معاملة مستقلة برسوم ⁦3000 sats⁩ تبقى ⁦7000 sats⁩ من الرسوم. و⁦sats⁩ وحدات صغيرة من البيتكوين. يبين حقل ⁦coinbasevalue⁩ أقصى مكافأة يجوز للمعدّن تخصيصها لنفسه مع مجموعة المعاملات الأصلية. وإذا تغيّرت المجموعة، وجب إعادة حساب المبلغ. يجب أن يعتمد الحساب على الرسوم الفعلية، لا المجموع المحسوب للمحتوى القديم. [4] [1]

تضم الكتلة أيضًا بصمات تشفيرية تتيح التحقق من بياناتها. تصف ⁦BIP 141⁩ مفهوم ⁦witness commitment⁩، وهو ارتباط تشفيري ببيانات ⁦witness⁩ التي تشمل مثلًا توقيعات تثبت حق إنفاق الأموال. يُشتق من معرّفات ⁦wtxid⁩ التي تشمل هذه البيانات. يوفر ⁦Bitcoin Core 29⁩ حقل ⁦default_witness_commitment⁩ للقالب غير المعدّل. بعد تغيير المعاملات المعنية أو ترتيبها، يلزم فحص هذا الارتباط أو إعادة حسابه. ويجب أيضًا حساب ⁦Merkle root⁩، بصمة المعاملات المجمعة في الترويسة، من معرّفات ⁦TXID⁩ النهائية، ومنها معرّف ⁦coinbase⁩ المعدّلة. الختم القديم لا يناسب محتوى تغير. [5] [3]

مساحة الكتلة محدودة، والمعدّن يختار محتواها. يقيّم ⁦Bitcoin Core v29.0⁩ حزم المعاملات المرتبطة ووزنها، وهو مقياس لحِمل البيانات، و⁦sigops⁩، أي عمليات فحص التوقيعات المحتسبة ضمن حد الكتلة. تؤثر إعدادات ⁦blockmaxweight⁩ و⁦blockmintxfee⁩ في حجم الكتلة المُنشأة ومعدل الرسوم المطلوب. هذه سياسة اختيار. فالدفعة المستبعدة لهذا السبب ليست بالضرورة مخالفة لقواعد الشبكة. كما أن إعدادات المعدّن لا ترفع حدود الشبكة التي تتحقق منها العقد الأخرى. [4] [3]

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

قد يمدّ معدّن آخر السلسلة بينما تستمر الحسابات. للبناء على أحدث كتلة مقبولة، لا يكفي استبدال بصمة الكتلة السابقة في القالب القديم. ربما تأكدت بعض المعاملات، ويتغير الارتفاع وشروط أخرى. تصف ⁦BIP 23⁩ الحقل ⁦expires⁩ بوصفه حدًا زمنيًا للعمل، و⁦prevblock⁩ بوصفه إذنًا لاستخدامه مع كتلة سابقة مختلفة. حتى هذا الإذن لا يحل محل التحقق: يجب إعادة تقييم المعاملات والمكافأة والسياق الجديد كله. [2]

من الأفضل اكتشاف خطأ المسودة قبل بحث طويل. يتيح نمط ⁦proposal⁩ وفق ⁦BIP 23⁩ عرض المقترح للفحص دون اشتراط ⁦Proof of Work⁩ صالح، أي دون نتيجة مكتشفة مسبقًا تثبت العمل الحسابي اللازم. التقييم الإيجابي لا يعني العثور على كتلة أو بثها، ولا يضمن مكانًا دائمًا لها في السلسلة. يعني فقط أن المسودة اجتازت الفحص المسبق المعني. أما الكتلة المكتملة فيجب أن تمر عند تقديمها بالتحقق المناسب، بما فيه إثبات العمل. [2]