Mining Target

للتوضيح فقط، تخيل حدًا قدره ⁦20⁩: تقبل النتيجتان ⁦19⁩ و⁦20⁩، ولا تقبل ⁦21⁩. أعداد التعدين الفعلية أكبر بكثير، لكن العلاقة نفسها: ⁦hash ≤ target⁩. تعني العلامة «أصغر من أو يساوي»، لا أصغر حصرًا. Bitcoin Core برنامج يستخدمه المشاركون في الشبكة للتحقق من الكتل والمعاملات. وتجري النسخة v29.0 المشار إليها هنا هذه المقارنة لهاش الترويسة كاملة. أما ⁦nonce⁩، القيمة التي يغيرها المعدّن أثناء البحث، فهي أحد المدخلات. وما يُقارن بالهدف هو الهاش الناتج من الحساب. [1]

ترى يانا صورة لهاش ناجح يبدأ بصف طويل من الأصفار. هذا تشبيه بصري مفيد: عند تساوي طول التمثيل، تعني الأصفار البادئة الأكثر عددًا أصغر. لكن قيمتي هاش لهما العدد نفسه من الأصفار قد تقعان على جانبين مختلفين من الهدف. بقية الخانات مهمة أيضًا. لذلك لا تحل الأصفار محل المقارنة الكاملة ⁦hash ≤ target⁩. الشرط عددي دقيق، وليس مسابقة لإنتاج نمط جميل من الرموز. [1]

يمثل البت صفرًا أو واحدًا، وتكوّن ثمانية بتات بايتًا. لتجنب تخزين العدد الطويل كاملًا في الترويسة، يستخدم Bitcoin حقل ⁦nBits⁩ بطول ⁦32⁩ بتًا. يرمّز هدفًا ضمن فضاء أعداد ⁦256⁩ بتًا، بمعامل وأسّ يحدد الإزاحة وبت للإشارة. مثلًا يُفك ⁦0x04123456⁩ إلى ⁦0x12345600⁩؛ وتشير البادئة ⁦0x⁩ إلى التمثيل الست عشري الذي يستخدم حروفًا أيضًا. هذا مثال للترميز لا هدف الشبكة الحالي. وللفهم الأساسي يكفي التمييز بين العدد نفسه وصيغته المختصرة. [3] [5]

عند قراءة البيانات الخام قد يبدو العدد نفسه معكوسًا. في ترويسة طولها ⁦80⁩ بايتًا، يشغل ⁦nBits⁩ أربعة بايتات بترتيب ⁦little-endian⁩، أي إن البايت الأقل وزنًا عدديًا يأتي أولًا. لذلك يظهر العدد ⁦0x1d00ffff⁩ في البيانات على هيئة ⁦ff ff 00 1d⁩. ترتيب البايتات لا يغير الهدف، بل يصف التخزين. هذا تفصيل يهم التعامل مع البيانات الخام؛ أما القارئ المعتاد لمستكشف الكتل فلا يحتاج إلى عكس الأعداد المعروضة. [2]

قد تقترح يانا تخزين عدد أكبر لتسهيل البحث. لكن البرنامج لا يكتفي بالتحقق من قدرته على قراءة ⁦nBits⁩. ترفض ⁦DeriveTarget⁩ في Bitcoin Core v29.0 الهدف السالب والصفر وتجاوز النطاق العددي والقيم الأعلى من ⁦powLimit⁩، أي أعلى هدف مسموح لهذه الشبكة. فك الترميز بنجاح يحدد فقط العدد الذي يمثله الترميز؛ ولا يمنح بحد ذاته حق استخدامه. [1]

حتى الهدف الواقع ضمن النطاق المسموح قد يكون خاطئًا لكتلة بعينها. يقارن Bitcoin Core حقل ⁦nBits⁩ بنتيجة ⁦GetNextWorkRequired⁩، وهي عملية حسابية تعتمد على الكتلة السابقة وقواعد الشبكة. يؤدي عدم التطابق إلى ⁦bad-diffbits⁩. ولا يبرر هاش منخفض تحت هدف أسهل اختاره المعدّن قيمةً خاطئة في الترويسة. لا تحصل يانا على كتلة مقبولة بمجرد خفض المتطلبات؛ فالعقد الأخرى، وهي الحواسيب التي تتحقق من القواعد، ترفض المحاولة. [4]

في نموذج قيم هاش بطول ⁦256⁩ بتًا موزعة بانتظام، لكل نتيجة ممكنة الاحتمال نفسه. لهدف مسموح ⁦T⁩، تُقبل القيم من الصفر إلى ⁦T⁩ شاملًا. ومن هنا تأتي ⁦p = (T + 1) / 2^256⁩ للمحاولة الواحدة، حيث ⁦p⁩ احتمال النجاح. الواحد المضاف يحتسب الصفر أيضًا. توضح العلاقة لماذا يجعل الهدف الأدنى البحث أصعب، لكنها لا تحدد عدد محاولات الجهاز في الثانية ولا موعد ظهور الكتلة التالية بدقة. [1]

عندما تستوفي يانا الشرط تكون قد أثبتت العمل الحسابي المطلوب، لا صحة كل ما في الكتلة. يفحص Bitcoin Core أيضًا البصمة المجمعة للمعاملات، ومعاملة المكافأة الخاصة المسماة ⁦coinbase⁩، وحدود الكتلة وصحة المعاملات. وكلمة ⁦coinbase⁩ هنا اسم تقني لأول معاملة في الكتلة، لا منصة التداول. لا يصلح الهاش المنخفض محتوى غير صالح. فالهدف جزء مهم من القواعد، لا إذن بتجاوز بقيتها. [4]