تعبّر Share Difficulty عن مدى صرامة الشرط الذي يجب أن تستوفيه نتيجة التعدين ليقبلها المجمّع بوصفها share، أي دليلًا مستمرًا على العمل. ارتفاع الصعوبة يعني في المتوسط نتائج مستوفية للشروط أقل من العدد نفسه من المحاولات. وهذا إعداد مختلف عن صعوبة العثور على كتلة في شبكة Bitcoin.
ينتج التعدين قيم هاش، وهي نتائج حسابية يمكن قراءتها كأعداد. لكي يتمكن المجمّع من قبول النتيجة، يجب ألا تتجاوز الهدف المحدد. والهدف الأدنى أشد صرامة لأن نتائج أقل تقع تحته. لذلك ترتفع Share Difficulty عندما ينخفض الهدف العددي. ولمن يهتم بالبروتوكول: تنقل قواعد الاتصال بالمجمّع، Stratum V2، هذا الحد في الحقل target من رسالة SetTarget. ولا يلزم معرفة صيغة الرسالة لفهم الفكرة: السقف العددي الأدنى يجعل شرط المعدّن أصعب. [1]
لنفترض أن المجمّع رفع صعوبة بيترا من 1024 إلى 2048. عند ثبات القدرة الحسابية وطريقة تحويل وحدات العمل، نتوقع نحو نصف النتائج المستوفية للشروط خلال الفترة الزمنية نفسها. يستمر الجهاز في المحاولة بالسرعة ذاتها، لكن نتائج أقل تجتاز الشرط الأشد. وتظل الفواصل بين النتائج عشوائية. لذلك لا ينبغي لبيترا أن تتوقع وصول كل share لاحق بعد ضعف المدة بالضبط. [2]
لو اكتفى المجمّع بعدّ الرسائل لقارن بين أشياء غير متكافئة. لذلك تشرح Braiins المحاسبة بوحدات عمل محوّلة وفق الصعوبة. نتيجتان مقبولتان عند صعوبة 1024 تحملان معًا وزن نتيجة واحدة عند صعوبة 2048. إذن قلة الرسائل لا تثبت مساهمة أقل. كذلك لا ينبغي لبيترا أن تخلط هذا الوزن المحاسبي بالعدد الدقيق للحسابات المنفذة فعلًا؛ فهو دليل إحصائي على العمل. وتعتمد المكافأة المالية أيضًا على قواعد المجمّع. [3]
تغيير Share Difficulty وحده لا يسرّع ASIC، أي الشريحة المتخصصة في جهاز التعدين. كما لا يغير هدف الشبكة المطلوب لكتلة Bitcoin. مع العدد نفسه من المحاولات المستقلة وصعوبة الشبكة نفسها، يبقى احتمال العثور على كتلة كما هو. يغير المجمّع فقط النتائج المرحلية التي يريد تلقيها. لذا فإن خفض صعوبة shares لا يجعل إنتاج كتل Bitcoin أسهل. [3]
لو استخدمت الأجهزة الأضعف والأقوى الإعداد نفسه لأرسلت أعدادًا مختلفة جدًا من النتائج. يوازن VarDiff، أي التعديل التلقائي للصعوبة، هذا الفرق ويحد من حركة البيانات غير الضرورية. وتسمح Braiins أيضًا بتحديد حد أدنى. لكنه حد لا تنخفض الصعوبة عنه، وليس قيمة ثابتة مخصّصة؛ فقد يختار المجمّع صعوبة أعلى بحسب القدرة الحسابية. حين تقارن بيترا إعدادها بالرقم المعروض، عليها أولًا أن تعرف إن كانت تقرأ الحد الأدنى أم الصعوبة المخصّصة فعلًا. [2]
يحتاج البرنامج إلى معرفة العمل الذي يشمله التغيير. وفق مواصفة Stratum V2 الحالية، تشمل رسالة SetTarget المهام التي تُستقبل بعدها والمهام المستقبلية المستلمة سابقًا التي يكون حقل ntime_start فيها فارغًا، أي إن الطابع الزمني الابتدائي الذي سيوضع في ترويسة الكتلة لم يُحدد بعد. والترويسة هي الجزء الموجز من بيانات الكتلة. يشير الحقل الفارغ إلى مهمة لا تزال تنتظر التفعيل. أما المهمة المستلمة سابقًا ذات ntime_start المحدد فتحافظ على هدفها. لذلك لا تكفي مقارنة نتيجة مرفوضة بأحدث حد؛ بل يجب ربطها بالمهمة الصحيحة. يتولى برنامج التعدين هذا عادةً. [1]
قد ترى بيترا أيضًا مؤشر best share. تستخدمه Braiins Solo مثلًا لوصف أعلى صعوبة لنتيجة share عُثر عليها خلال جلسة التعدين. الصعوبة المخصّصة تصف الشرط الكافي للإرسال، بينما يصف best share مدى ندرة النتيجة التي عُثر عليها فعلًا. هذا السجل ليس تقدمًا مدّخرًا نحو كتلة. وحتى النتيجة الاستثنائية لا تزيد احتمال نجاح المحاولة المستقلة التالية. [4]
قد يجعل الحد الأدنى اليدوي المرتفع جدًا الإرسالات نادرة إلى درجة يتذبذب معها تقدير القدرة الحسابية بشدة. وقد تطلق المراقبة إنذارًا مع أن ASIC لا يزال يعمل. غياب share فترة قصيرة لا يثبت عطلًا بمفرده. تقارن بيترا الصعوبة المخصّصة ومدة المراقبة والعمل المقبول وحالة الاتصال. وتساعدها هذه المعلومات مجتمعة على التمييز بين العشوائية المعتادة والمشكلة الحقيقية. [2]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Mining Share, Mining Target, Hashrate, Mining Pool, Bitcoin. تشير إلى هذا المدخل أيضًا Mining Pool, Stratum V1, Stratum V2, Mining Share.