Job Negotiation

تنتقل آنا إلى ⁦Stratum V2⁩، لكنها تظل تتلقى قائمة المعاملات من المجمّع. لا تناقض هنا. يمكن لـ Mining Protocol، الجزء الذي ينقل العمل والنتائج، أن يعمل دون Job Declaration أو Template Distribution. يقدم الأخير قوالب الكتل، بينما يعالج Job Declaration المقترحات الخاصة. لكي تختار آنا، يجب أن تتوافر هذه الأدوار أيضًا وأن يدعمها المجمّع. لذلك لا يوضح أسلوب نقل أحدث وحده من يحدد محتوى كتلة على شبكة Bitcoin. [1] [4]

لا يجوز أن تملأ الدفعات المختارة الكتلة حتى لا تتسع لمعاملة المكافأة coinbase. لذلك يحتاج مزود القالب، Template Provider، إلى معرفة الحيز المطلوب حجزه. يعمل لدى آنا برنامج JDC، اختصار Job Declarator Client. يجمع متطلبات المجمّعات المستخدمة ويرسلها إلى مزود القالب في رسالة بيانات تسمى ⁦CoinbaseOutputConstraints⁩. يشمل الحجز مساحة البيانات وsigops، أي عمليات التحقق من التواقيع التي تُحتسب ضمن حد الكتلة. وإلا فقد تتجاوز مخرجات coinbase الإضافية، البنود التي تخصص الأموال، حدود الكتلة. الاختيار الخاص للمعاملات يجب أن يراعي صلاحية النتيجة كاملة منذ البداية. [3]

في وضع Full-Template، يرسل JDC رسالة ⁦DeclareMiningJob⁩ إلى JDS، أي Job Declarator Server لدى المجمّع أو خدمة يثق بها. تتضمن الرسالة معرفات المعاملات المختارة. وإذا افتقد الخادم إحداها، يمكنه طلب بياناتها عبر ⁦ProvideMissingTransactions⁩. بذلك تشارك آنا معلومات تتيح فحص اختيارها. تأكيد التصريح ثم قبول المجمّع للمهمة الخاصة خطوتان منفصلتان. أول رسالة نجاح لا تعني اكتمال الاتفاق كله. [2]

في وضع Coinbase-only، لا يكشف JDC مجموعة المعاملات ولا تُستخدم ⁦DeclareMiningJob⁩. يقدّر المجمّع الإيراد من coinbase المقدمة. يحجب ذلك اختيار آنا عن المجمّع، لكنه لا يثبت بمفرده صلاحية المعاملات المخفية أو رسومها الفعلية. وتذكر المواصفة هذا الخطر صراحة. مشاركة معلومات أقل تغير أيضًا ما يمكن التحقق منه؛ اسم الوضع وحده ليس ضمانًا لإثبات جميع شروط المكافأة على نحو كافٍ. تخص هذه الخصوصية المقترح أثناء التعدين. فإذا عثرت آنا على كتلة صالحة ونشرتها على الشبكة، أصبحت معاملاتها مرئية. [2]

تظهر في التواصل التقني علامات عدة تبدو متشابهة. يمنح JDS الرمز ⁦mining_job_token⁩، ويشير إليه العميل في ⁦SetCustomMiningJob⁩. عندما يقبل المجمّع المهمة، يعيد ⁦SetCustomMiningJob.Success⁩ مع ⁦job_id⁩ الخاص به. للرمز و⁦job_id⁩ وظيفتان مختلفتان: الأول يربط إجراءات المقترح، والثاني يحدد العمل عند تقديم نتائجه. يشبه الأمر رقم طلب ورقم أمر عمل معتمد. الخلط بينهما يمنع المجمّع من إسناد النتيجة إلى المهمة المقبولة الصحيحة. [1]

انتظار كل خطوة شبكية يؤخر الأجهزة بلا داعٍ. متى امتلك العميل الرمز والقالب اللازمين، يمكنه بدء التعدين التفاؤلي قبل ⁦SetCustomMiningJob.Success⁩. تُحفظ shares، النتائج الجزئية التي تثبت العمل وفق هدف المجمّع، حتى يصل التأكيد. وبعد قبول المهمة يمكن إرسالها بالمعرّف المخصص. لذا فإن عمل الآلة لا يثبت أن المجمّع قبل هذه المهمة أو احتسب نتائجها. بدء الحساب والموافقة على مكافأة المهمة لحظتان مختلفتان. [1] [2]

إذا تلقت آنا ⁦SetCustomMiningJob.Error⁩ أو لم تحصل على رد خلال وقت معقول، توصي المواصفة بمجمّع آخر أو بالتعدين الفردي. تعتمد القدرة على الصمود إذن على fallback يعمل، أي مسار بديل مُعد مسبقًا. لو انتقل البرنامج بصمت إلى القالب الأصلي للمجمّع الذي رفض مقترحها، فقد يحافظ على التشغيل لكنه يفقد اختيار آنا. لذلك يهم معرفة ما يفعله النظام فعلًا عند الرفض. وصف قدرة في بروتوكول لا يثبت أن كل خدمة تدعمها. [1] [4]

تريد آنا اختيار المعاملات مع الاحتفاظ بالمكافآت المشتركة. لذا يجب أن يخصص JDC قيمة للمخرج الذي يحدده المجمّع في coinbase لاستيفاء شروط المكافآت. إذا وجهت جزءًا من الإيراد إلى مكان آخر، يستطيع المجمّع خفض مكافأة هذه المهمة بنسبة متناسبة. لا ينشئ Job Declaration دفعًا مباشرًا تلقائيًا للمعدّن ولا يلغي شروط المحاسبة لدى الخدمة. ما يتغير أساسًا هو الطرف الذي يستطيع اقتراح محتوى الكتلة؛ أما قواعد صلاحيتها وكيفية تقسيم الإيراد فيجب النظر إليهما كلٌّ على حدة. [2]