يجعل Proof of Work إنشاء كتل Bitcoin مكلفًا والتحقق منها سهلًا. يتنافس المُعدّنون بإجراء حسابات لا يستطيعون توقع نتائجها. يبحثون عن قيمة تجزئة، أي بصمة رقمية لترويسة الكتلة، لا تتجاوز عدديًا حدًا يسمى target. يستطيع الآخرون فحص النتيجة الناجحة بسرعة. لكن Full Node، وهو حاسوب يتحقق بنفسه من قواعد Bitcoin، يفحص المعاملات أيضًا بصورة مستقلة؛ فإثبات العمل وحده لا يجعل الكتلة صحيحة.
تخيل سحبًا لا يمكن حساب البطاقة الفائزة فيه مسبقًا بحيلة ذكية. يغير المُعدّنون بيانات كتلة مرشحة مرارًا ويحسبون hash في كل مرة. تفشل معظم النتائج. ولا يصلح كـ Proof of Work إلا hash قيمته العددية أقل من target الحالي أو مساوية له. يصعب العثور عليه، لكن أي شخص يستطيع فحصه بسرعة. لا يثبت Bitcoin حسابًا مفيدًا بالمعنى المعتاد، بل يقدم دليلًا عامًا على إجراء بحث مكلف من أجل Block Header محدد. [1] [2]
يحمل Block Header البيانات الأساسية للكتلة، بينما يمثل Merkle Root بصمة مجمّعة لمعاملاتها. وNonce عدد يستطيع المُعدّن تغييره أثناء البحث. أما ASIC فهو شريحة مصممة لمهمة حسابية محددة؛ وهنا تستخدم دالة التجزئة SHA-256 مرارًا. يبني المُعدّن أولًا كتلة مرشحة: يختار المعاملات، وينشئ Coinbase Transaction التي تحمل المكافأة، ويحسب Merkle Root. تشكل هذه القيم مع مرجع الكتلة السابقة والوقت وtarget وnonce عناصر Block Header. ثم يحسب ASIC متخصص SHA-256 مزدوجًا لنسخ كثيرة. ليست مسألة يقترب فيها الحل خطوة بعد خطوة. فكل محاولة تعطي نتيجة جديدة تبدو عشوائية، ولا يكشف الفشل السابق إن كانت المحاولة التالية ستنجح. [3] [1]
يمكن قراءة hash كعدد ضخم. Target الشبكة هو أعلى قيمة تسمح بها القواعد. كلما انخفض، قلت نسبة hashes المقبولة وزاد عدد المحاولات المتوقع. يخزن nBits قيمة target بصورة مضغوطة في header. أما difficulty فهي تعبير نسبي عن صعوبة الهدف، وليست عدد الأصفار أو مقدار الجول أو حصة مُعدّن من القدرة. قد تظهر كتلة فورًا أو بعد انتظار طويل؛ تحدد القواعد النتيجة المطلوبة، لا عدد المحاولات التي أدت إليها فعلًا. [2] [1]
لا يتجاوز nonce في Block Header أربعة بايتات، لذلك قد يجتاز ASIC سريع مجاله كله بلا نتيجة. Mining ليس زيادة رقم واحد إلى ما لا نهاية. يستطيع البرنامج تغيير extra nonce داخل Coinbase Transaction أو اختيار المعاملات وترتيبها وبيانات أخرى مسموحة. يؤدي ذلك إلى تغيير Coinbase Transaction ثم Merkle Root وheader كله، فتظهر مجموعة مرشحين جديدة. ويوزع pool أعمالًا مختلفة على أجهزة كثيرة حتى لا تختبر النسخ نفسها. [3]
تحقق قيمة التجزئة التي لا تتجاوز target شرطًا أساسيًا واحدًا، لا كل قواعد Bitcoin. يفحص Full Node أيضًا الحجم والبنية والأسلاف وCoinbase Transaction والمكافأة المسموحة والتوقيعات والبرامج النصية وما إذا كانت المدخلات تشير إلى أموال موجودة لم تُنفق بعد. لذلك لا يستطيع الحساب المكلف إجبار الآخرين على قبول bitcoin زائد أو إنفاق مزدوج. تبقى الكتلة غير الصحيحة مرفوضة مهما كانت الطاقة. وبالعكس، لا تستطيع كتلة معاملاتها صحيحة لكن Proof of Work فيها غير كافٍ توسيع السلسلة النشطة. [4] [1]
قد ينشر مُعدّنان كتلتين صحيحتين مختلفتين في الوقت نفسه تقريبًا وعلى الارتفاع نفسه، فتظهر لفترة قصيرة شعبتان. بين المرشحين الصحيحين تتبع العقد الفرع ذا أكبر عمل متراكم، الذي يمثله Bitcoin Core بقيمة chainwork. ولا يساوي ذلك دائمًا مجرد عدد الكتل، إذ قد تكون قد أُنتجت عند قيم target مختلفة. تتطلب إعادة كتابة دفعة مؤكدة بناء تاريخ بديل صحيح واللحاق بعمل الفرع العادي المتزايد ثم تجاوزه. لذلك تزيد التأكيدات تكلفة الهجوم عادة، لكنها لا تنشئ عدم قابلية رياضية فورية للتراجع. [5] [1]
يقيس Hashrate عدد محاولات التجزئة في الثانية. لو ظل target ثابتًا، لأدى ارتفاع Hashrate إلى تسريع الكتل وأدى انخفاض القدرة إلى إبطائها. لذلك يعيد Bitcoin mainnet حساب target بعد فترات من 2,016 كتلة لإرجاع المتوسط الطويل إلى نحو عشر دقائق لكل كتلة. يقارن الحساب المدة المرصودة بالأسبوعين المستهدفين ويقيد التعديل بحدود البروتوكول. لا يستجيب retarget مباشرة لسعر BTC أو عدد المستخدمين أو تصويت المُعدّنين على القواعد. عشر دقائق متوسط مستهدف، لا موعد الكتلة التالية. [2]
قد ينتظر المُعدّن المنفرد طويلًا كتلة صحيحة، لذلك تعمل أجهزة كثيرة عبر mining pool. يحدد pool قيمة share target داخلية أسهل ويستخدم shares المقدمة لتقدير مساهمة كل مشارك. لا تبلغ معظمها target الشبكة الأشد ولا تدخل Blockchain أبدًا. عندما تبلغ نتيجة ما target الشبكة أيضًا، يبث pool الكتلة المرشحة كاملة. ولا يقرر قبولها pool أو حجم Hashrate، بل التحقق المستقل في كل عقدة. [3]
تستهلك الأجهزة الفعلية الكهرباء وتطلق الحرارة أثناء البحث، لكن Bitcoin لا يخزن فاتورة طاقة داخل الكتلة. لا يكشف hash الفائز العدد الدقيق للمحاولات أو الكيلوواط-ساعة أو مصدر الكهرباء أو موقع المُعدّن. يمنح Proof of Work التاريخ دفاعًا اقتصاديًا لأن المحاولات الجديدة لها تكلفة واقعية، لكن زيادة الاستهلاك وحدها لا تعني أمنًا كاملًا أو تشغيلًا أنظف. يجب أن يشمل تقييم الأمن التحقق وتوزيع Hashrate والتهديد المحدد، وأن يشمل تقييم الطاقة مصدرها وتوقيتها وكفاءتها واستخدامها البديل. [1] [2]
يفحص Full Node مستقلًا hash السابق وnBits وtarget المشتق وhash الخاص بـ header لكل كتلة. تتيح بيانات الكتل مقارنة height وdifficulty وchainwork، لكن hash الفائز لا يكشف هوية المُعدّن أو طاقته الدقيقة. تحتاج عبارة مثل «آمن بعد ستة تأكيدات» إلى سياق: قيمة الدفعة وقدرة الخصم وتوزيع العمل وإمكان الانتظار. Proof of Work ليس ملصقًا تسويقيًا ولا تصويت المُعدّنين على القواعد، بل مدخل محدد يسهل فحصه في آلية الاختيار بين التواريخ الصحيحة. [2] [3] [5]
للحصول على صورة أوضح، اقرأ هذا المدخل مع التعدين, Difficulty Adjustment, Timechain / Blockchain, Full Node, Block Subsidy. تشير إلى هذا المدخل أيضًا Bitcoin, Satoshi Nakamoto, Bitcoin Whitepaper, Timechain / Blockchain.