Stale Rate

المجمّع خدمة توزّع العمل بين المعدّنين. عندما تجد الشبكة كتلة جديدة، يحتاجون عادةً إلى البدء بالبناء عليها. ولا تعود نتيجة محسوبة وفق المهمة السابقة مناسبةً للعمل الجديد. يعالج بروتوكول اتصال أجهزة التعدين ⁦Stratum V2⁩ ذلك برسالة ⁦SetNewPrevHash⁩: يبدأ الجهاز البحث عن كتلة تلي الكتلة المحددة حديثًا. ومن المهام المعدّة سابقًا لا تبقى صالحة إلا المهمة التي يحددها معرّف المهمة ⁦job_id⁩. لذلك تبحث بترا في صلاحية المهمة، لا في وقت إرسال النتيجة وحده. [1]

في مثال بسيط، ترسل بترا ⁦100⁩ نتيجة متساوية الصعوبة. يقبل المجمّع ⁦98⁩، ويرفض ⁦1⁩ باعتبارها ⁦stale⁩ و⁦1⁩ لسبب آخر. تمثل نتائج ⁦stale⁩ المرفوضة ⁦1%⁩، بينما تمثل جميع الرفضات معًا ⁦2%⁩. ويسمّي ⁦F2Pool⁩ نسبة جميع الإرسالات المرفوضة إلى مجموع الإرسالات ⁦rejection rate.⁩ في مثالنا، ⁦stale⁩ جزء فقط من هذا المجموع. الأرقام تشرح الحساب، ولا تحدد حدًا تشغيليًا مقبولًا؛ فقد يعني المؤشر شيئًا آخر إذا اختلف التصنيف. [2]

تحدد صعوبة ⁦share⁩ مدى صرامة الشروط التي يجب أن تحققها النتيجة. يحتسب ⁦Braiins⁩ النتيجة ذات الصعوبة ⁦d⁩ بمقدار ⁦d⁩ من وحدات العمل الأساسية. لنتخيل ⁦stale share⁩ بصعوبة ⁦1⁩ و⁦share⁩ مقبولة بصعوبة ⁦9⁩. نحصل على ⁦50%⁩ عند عدّ الإرسالات، وعلى ⁦10%⁩ عند وزن العمل. لا يكون أي من الحسابين خاطئًا بذاته، لكنهما يجيبان عن سؤالين مختلفين. لذلك تستخدم بترا الوحدة نفسها في البسط والمقام، وتتحقق من اعتماد المعيار نفسه للصعوبة. [3]

تميّز وثائق ⁦F2Pool⁩ بين فئة ⁦Staled⁩ التي تنتج مكافأة، و⁦stale shares⁩ المرفوضة التي لا تنتجها. لذلك لا يكفي الاسم لمعرفة ما إذا كانت بترا قد خسرت مالًا. ولا يمكن تعميم هذه السياسة على كل مجمّع؛ فالمهم قواعد الخدمة المعنية والتسوية الفعلية. عند مقارنة المزوّدين، تتحقق بترا أولًا من فئة النتائج، ثم تستطيع تقدير أثرها في الدخل. [2]

عند قراءة سجل التشغيل، يسهل إغفال أن ⁦Stratum V2⁩ يستطيع تأكيد عدة إرسالات برسالة ⁦SubmitShares.Success⁩ واحدة. يشير الحقل ⁦new_submits_accepted_count⁩ إلى عدد الإرسالات التي تأكدت حديثًا، بينما يجمع ⁦new_shares_sum⁩ درجات صعوبتها. لذلك لا يساوي عدد ردود الخادم عدد ⁦shares⁩ المقبولة. وعند الرفض، تتضمن ⁦SubmitShares.Error⁩ الحقل ⁦sequence_number⁩ لتحديد الإرسال، و⁦error_code⁩ لبيان سبب الخطأ. من دون هذا التمييز قد تظن بترا أن كل خطأ يعني عملًا متأخرًا. [1]

يجب أن ينتقل خبر الكتلة الجديدة أولًا بين الحواسيب التي تتحقق من ⁦Bitcoin.⁩ يشرح ⁦BIP152⁩ آلية ⁦Compact Block Relay⁩ لنقل الكتل ببيانات أقل بين عقد شبكة ⁦P2P⁩، أي المشاركين المتصلين مباشرةً. وقد يقلل حجم البيانات الأصغر من تأخر النقل. لكن الأمر يتعلق بنشر الكتل، لا بمحاسبة ⁦shares⁩ داخل المجمّع. لذلك لا تقيس نسبة الكتل التي بقيت خارج السلسلة الرئيسية النتائج المتأخرة لجهاز بترا. [4]

يوفر ⁦Braiins⁩ إحصاءات العمل لفترات مختلفة: ⁦shares_5m⁩ (آخر ⁦5⁩ دقائق) و⁦shares_60m⁩ (آخر ⁦60⁩ دقيقة) و⁦shares_24h⁩ (آخر ⁦24⁩ ساعة). لا تستطيع بترا قسمة النتائج المتأخرة لفترة قصيرة على عمل يوم كامل، ثم مقارنة ذلك بإحصاءات ساعة لجهاز آخر. يجب أن يغطي طرفا الحساب الفترة والأجهزة نفسها. وإذا لم تُرصد أي إرسالات، تكون النسبة غير معرّفة؛ وليست خسارة مقاسة مقدارها ⁦0%⁩. كذلك لا تثبت فجوة المراقبة أو غياب الرد، بمفردهما، أن النتيجة كانت ⁦stale.⁩ [5]

تبدأ بترا بتغييرات المهام وأسباب الرفض وحالة الاتصال خلال الفترة نفسها. يربط ⁦F2Pool⁩ نتائج ⁦stale⁩ بظروف الشبكة. وقد تنشأ حالات رفض أخرى من أخطاء ⁦firmware⁩، أي البرنامج الذي يتحكم بالجهاز، أو من الإفراط في رفع تردد تشغيل الشرائح لمحاولة إجراء مزيد من الحسابات. يوصي ⁦Braiins⁩ باستخدام ⁦ping⁩، وهو اختبار بسيط لمعرفة ما إذا كان الخادم يستجيب لطلبات الشبكة. لكن وصول الرد لا يؤكد صحة التعدين أو قيد المكافأة. انخفاض النسبة الإجمالية وحده لا يثبت زوال السبب. المطلوب فهم ما تغيّر، وتتبع نوع الخطأ المحدد في ظروف قابلة للمقارنة. [2] [6]