Mining Share

ينفّذ جهاز بيتر عددًا هائلًا من المحاولات. لا يحتاج المجمّع رسالة عن كل محاولة؛ بل يتلقى نتائج مختارة حققت شرطًا محددًا مسبقًا. يتحقق منها ويقدّر العمل إحصائيًا من تواترها وصعوبتها. لذلك ليست Mining Share جزءًا من كتلة غير مكتملة ولا حصة بيتكوين قابلة للنقل. وليست أيضًا معاملة تُسجّل في سلسلة الكتل، وهي السجل العام لمعاملات Bitcoin المرتبة في كتل مترابطة. وتتيح Mining Share إثبات مساهمة المعدّن في الحسابات أمام المجمّع. [1]

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

لا يجمع بيتر هذه الرسائل يدويًا؛ يتولى البرنامج ذلك. ⁦Stratum V2⁩ بروتوكول، أي قواعد تواصل بين الأجهزة والمجمّع. تتضمن رسالته ⁦SubmitSharesStandard⁩ حقل ⁦job_id⁩ لتعريف المهمة، و⁦nonce⁩ للقيمة المتغيرة أثناء البحث، و⁦ntime⁩ للطابع الزمني في ترويسة الكتلة، و⁦version⁩ لنسخة ترويسة الكتلة، وهي الجزء المختصر من بياناتها. وتتضمن تعريف قناة التواصل أيضًا. يحتاج المجمّع هذا السياق للتحقق من الحساب؛ فقيمة ⁦nonce⁩ بلا المهمة الصحيحة ليست دليل عمل مستقلًا. [2]

تخيّل أن بيتر يقارن أجهزة تعمل على مهام مختلفة الصعوبة. تعمل الصعوبة هنا كوزن: تُحتسب النتيجة التي تحقق شرطًا أشد على أنها مقدار أكبر من العمل. عند استخدام طريقة التحويل نفسها، يكون لإرسالين مقبولين بصعوبة 1024 الوزن الإجمالي نفسه لإرسال واحد بصعوبة 2048. يختلف عدد الرسائل، لكن وزن العمل المحتسب متساوٍ. وحتى هذا المجموع ليس سجلًا دقيقًا لكل الحسابات التي أُجريت بالفعل، لأن النجاحات الفردية عشوائية. لذلك تحقّق هل يعرض عدّاد shares النتائج المقبولة أم وزنها بعد التحويل. [3]

يؤكد المجمّع أحيانًا عدة إرسالات دفعة واحدة. يستخدم ⁦Stratum V2⁩ الاستجابة ⁦SubmitShares.Success⁩ لذلك. يعدّ الحقل ⁦new_submits_accepted_count⁩ الإرسالات المؤكدة حديثًا، بينما يجمع ⁦new_shares_sum⁩ صعوبات مهامها. الأول يعدّ النتائج، والثاني وزنها. كلاهما يخص الدفعة الجاري تأكيدها، وليس تلقائيًا مجموع تاريخ المعدّن كله. لذا لا يلزم توقع تأكيد مستقل لكل نتيجة مرسلة عند قراءة البروتوكول. [2]

قد يعلن جهاز بيتر إرسال نتيجة بينما لا يزال المجمّع يتحقق منها. يستخدم ⁦Stratum V2⁩ رسالة ⁦SubmitShares.Error⁩ للإرسال الخاطئ، ويحدد ⁦sequence_number⁩ الإرسال المعني بالخطأ. إذا تعذر التحقق فورًا، فقد تصل استجابة الخطأ لاحقًا. لذلك افصل النتائج المرسلة عن المؤكد قبولها، وراقب الرفض أيضًا. لا يثبت ارتفاع عدّاد الإرسال المحلي وحده أن المجمّع احتسب كل شيء. [2]

يدخل العمل المؤكد في قواعد مكافآت المجمّع المحدد. مثلًا، يحسب نموذج ⁦FPPS⁩، أي ⁦Full Pay Per Share⁩، لدى Braiins المكافأة من العمل المقدّم وبيانات الشبكة، بما فيها الصعوبة ومكافآت الكتل؛ ويتضمن جزءًا من رسوم المعاملات أيضًا. يقتطع المجمّع رسمه، وتتبع التحويلات إعدادات الدفع. تأكيد share لا يرسل BTC (بيتكوين) إلى المحفظة بنفسه. لذلك يتابع بيتر العمل المقبول والمكافأة المحسوبة والدفع الفعلي كلًا على حدة. [4]

قد يشبه عدّاد shares تقدم التنزيل، لكن التعدين لا يعمل هكذا. تظهر shares والكتل من البحث عن hashes منخفضة بما يكفي، بنتائج عشوائية. يمنح العمل المثبت الأكثر أساسًا إحصائيًا أفضل لتقدير القدرة، لا يقينًا بنجاح تالٍ. ولا تضمن سلسلة طويلة من shares المقبولة كتلة في المحاولة المقبلة. يخبر العدّاد بيتر عن العمل المستمر وقبوله، لا بأن آخر قطعة فقط من الكتلة تنتظر الإكمال. [3]