Full Pay Per Share

يرسل الجهاز إلى المجمّع shares، أي نتائج حسابية جزئية تثبت العمل. غالبًا لا تحقق الشرط الأصعب لكتلة كاملة، لكن المجمّع يستطيع التحقق منها. تعتمد Luxor في FPPS على النتائج الصحيحة المقبولة دون انتظار اكتشاف كتلتها الخاصة. وتشرح Braiins وزنها أيضًا: نتيجة بصعوبة d تُحسب بوصفها d وحدات عمل أساسية. لذلك لا يكفي عدّ الرسائل المرسلة، فقد تختلف أوزان النتائج، ولا يجوز إضافة العمل المرفوض تلقائيًا إلى العمل المقبول. [2] [3]

قد تجلب الكتلة الجديدة بيتكوين صادرًا حديثًا، يسمى إعانة الكتلة، ورسوم معاملاتها. يُقيّم FPPS حصة عمل إيفا المتوقعة من كليهما. والصيغة التقنية لحساب Braiins في فترة ثابتة المعاملات هي ⁦R=(S/D)×(C+AF)⁩. يرمز S إلى العمل المقبول الموزون بالصعوبة، وD إلى صعوبة الشبكة، وC إلى الإعانة، وAF إلى متوسط الرسوم وفق المنهجية. أما R فهو المكافأة قبل رسوم المجمّع. لا يمكن أن يكون S مجرد عدد رسائل متفاوتة الصعوبة، وإلا ساوى الحساب بين كميات عمل مختلفة. تعبّر ⁦S/D⁩ عن عدد الكتل الذي يُتوقع إيجاده في المتوسط بهذا المقدار من العمل عند الصعوبة المعنية. وهي ليست عدد الكتل المكتشفة فعلًا ولا وعدًا باكتشاف كتلة. [1] [3]

ترى إيفا كشفًا يوميًا، لكنه ليس مجرد تقسيم للكتل التي اكتشفها مجمّعها في ذلك اليوم. تُنهي Braiins الحساب وفق يوم UTC، المرجع الزمني العالمي المشترك، وتضبط نتائج الشبكة على أساس ⁦144⁩ كتلة متوقعة. هذا معيار للحساب، لا نتيجة يومية مفروضة على الشبكة أو المجمّع. وقد يكون انخفاض الكتل في يوم ما مجرد عشوائية عادية. لذلك لا يساوي اليوم التقويمي تلقائيًا آخر ⁦144⁩ كتلة؛ فقد تبدأ تلك النافذة وتنتهي في أوقات أخرى. [1]

تصف Luxor طريقة أخرى: عند الارتفاع الحالي h، أي موضع الكتلة في السلسلة، تراجع آخر ⁦144⁩ كتلة. تستبعد قيم الرسوم عند طرفي التوزيع، المحددة بـ⁦≤p5⁩ و⁦≥p95⁩، ثم تحسب متوسط الباقي لتقليل أثر القيم المتطرفة. وتستخدم أيضًا الإعانة والصعوبة عند ذلك الارتفاع. تمثّل ⁦p5⁩ و⁦p95⁩ حدّين في القيم المرتبة من الأصغر إلى الأكبر: تقع نحو ⁦5%⁩ دون الحد الأول و⁦95%⁩ دون الثاني. وهكذا يحتفظ الحساب بالجزء الأوسط من القيم بدل طرفيها المتطرفين. هذا الفرز ليس قاعدة في Bitcoin ولا شرطًا لكل مجمّع FPPS. ويمكن أن تغيّر Luxor منهجيتها؛ لذا على إيفا مقارنة القواعد الفعلية، لا الاكتفاء باختصارات متطابقة في قوائم الأسعار. [2]

لنفترض أن إيفا تعدّن قبل تغير صعوبة الشبكة وبعده. أصبحت للعمل نفسه قيمة متوقعة مختلفة، ولذلك تحسب Braiins الأجزاء المعنية من اليوم منفصلة. وتتعامل بصورة مشابهة مع Halving، الخفض الدوري إلى النصف لمكافأة الكتلة الصادرة حديثًا. يغير Halving الإعانة، لا طريقة حساب متوسط الرسوم تلقائيًا. إذن يقلل FPPS الاعتماد على حظ المجمّع، لكنه لا يثبت كمية بيتكوين (BTC) اليومية. وتغيّر سعر بيتكوين أو تكلفة الكهرباء يغيّر النتيجة الاقتصادية لإيفا أيضًا. [1] [2]

تصف الاختصارات أساس الدفع. PPS تعني ⁦Pay Per Share⁩، أي الدفع مقابل shares المقبولة. أما PPLNS فتعني ⁦Pay Per Last N Shares⁩: عند اكتشاف كتلة تُوزّع المكافأة بحسب العمل ضمن آخر نطاق محسوب من shares، ويحدد المجمّع حجم ذلك النطاق. قد يعرض كلّ من FPPS و⁦PPS+⁩ حصة من رسوم المعاملات دون حسابها بالطريقة نفسها. تميّز F2Pool بين FPPS ذي الرسوم المقدّرة بنموذج و⁦PPS+⁩. في ⁦PPS+⁩ تُدفع الإعانة بطريقة PPS، أي مقابل العمل المقبول، بينما توزّع رسوم المجمّع الفعلية بطريقة PPLNS وفق العمل في النافذة الأخيرة ذات الصلة. لذلك يبقى عنصر الرسوم معتمدًا على الكتل التي يجدها المجمّع. عبارة «نضمّن الرسوم» لا تكفي وحدها لتعرف إيفا أي جزء من مكافأتها ينتظر كتلًا حقيقية. [4]

إذا ظل المجمّع بلا كتلة مدة طويلة مع استمرار إضافة المكافآت، فهو يحتاج إلى أموال للوفاء بالتزاماته. يناقش Meni Rosenfeld هذا في PPS: يتحمل المشغّل تقلب الاكتشافات ويحتاج إلى احتياطيات. ويساعد المنطق نفسه في فهم خطر FPPS. نموذجه التاريخي ليس تدقيقًا لمجمّع حالي، ولا يبين مقدار المال لدى شركة بعينها. تحصل إيفا على حق لدى الخدمة، وليس على ضمان من البروتوكول بأن المال سيصل إذا عجز المشغّل. [5]

تفصل Braiins وLuxor بين إضافة المكافأة وإرسالها. ويتوقف الدفع أيضًا على الموعد المحدد والحد الأدنى المطلوب للرصيد ورسوم التحويل المحتملة. رقم FPPS في لوحة الحساب لا يثبت وصول المال إلى محفظة إيفا. لذلك تقارن الخدمات على أساس العمل المقبول والفترة نفسيهما، وقاعدة الحساب المستخدمة، وصافي المبلغ الذي تسلمته فعلًا. بعد ذلك فقط يمكنها معرفة ما بقي بعد تكاليف تشغيل الجهاز. [1] [2]