Pay Per Last N Shares

يوصل يان جهازه إلى Mining Pool، وهي خدمة تنسّق عمل المعدّنين. في PPLNS لا يعد المجمّع بسعر ثابت لكل نتيجة مقبولة. بل يستخدم عند العثور على كتلة سجلّ العمل الحديث لتقسيم المكافأة. يمكن تصور السجل قائمة متحركة: تدخل نتائج جديدة وتخرج الأقدم تدريجياً. العثور على كتلة لا يمسح القائمة. لذلك قد يحصل العمل نفسه على جزء من عدة مكافآت، أو يغادر القائمة قبل ظهور أي كتلة تستحق مكافأة. [1]

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

لنتصور نافذة ممتلئة تضم 1000 من shares المتساوية الوزن، منها 100 تخص يان. وجد المجمّع للتو كتلة ولديه 3 BTC للتوزيع بعد اقتطاع حصته. تكون حصة يان في هذا المثال 100 / 1000 × 3 = 0.3 BTC. قدّم يان عُشر العمل المحتسب، ولذلك يحصل على عُشر المكافأة الموزّعة. هذه أرقام توضيحية فقط: لا يعني 3 BTC هنا مقدار إعانة الكتلة، أي البيتكوين الجديد الذي يُنشأ مقابل الكتلة، ولا يعني 0.3 BTC دخلاً يومياً موعوداً. وعند العثور على الكتلة التالية، قد تضم النافذة نتائج مختلفة وقد يتغير المبلغ المتاح أيضاً. [1]

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

يوزّع PPLNS نتائج العثور الفعلي على الكتل، لذا يختلف يوم ناجح للمجمّع عن يوم بلا اكتشاف. ويهم أيضاً كيف يحتسب رسوم المعاملات التي يدفعها مستخدمو Bitcoin. يصف F2Pool هذه التقلبات صراحة. في المقابل، يقيّم Full Pay Per Share (FPPS) العمل المقبول بتقدير يشمل إعانة الكتلة ورسوم المعاملات؛ وقد يستخدم Pay Per Share Plus (PPS+) طريقة PPLNS لجزء الرسوم فقط. لذلك لا تخبر نسبة رسم الخدمة وحدها يان أي النتيجتين أفضل. يحتاج أيضاً إلى معرفة المبلغ الذي تُطبّق عليه النسبة. [2] [3]

الحصة المحسوبة ورصيد الحساب والدفعة المستلمة في محفظتك الخاصة خطوات مختلفة. يتحقق يان من قبول الكتلة، وطريقة حساب حصته، وموعد إمكان سحب الرصيد وفق الحد الأدنى والجدول. كذلك قد لا يصبح تغيير طريقة المكافآت نافذاً فوراً. ينشر F2Pool مثلاً توقيته الخاص لبدء تطبيق التغيير. وللمقارنة المنصفة يجب احتساب العمل السابق للتغيير وأي مكافآت لاحقة من نافذته التي لم تنتهِ بعد. لا يزيل PPLNS خطر امتناع المجمّع عن الدفع، ولا فاتورة الكهرباء وتكلفة الأجهزة. [3] [4]

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

من أهداف PPLNS الحد من pool-hopping: الانتقال بين المجمّعات لمجرد استغلال مرحلة أنسب في توزيع المكافآت. فالنافذة الممتدة عبر اكتشافات الكتل تزيل الميزة البسيطة للدخول في بداية جولة جديدة. لكن العدالة الحسابية تعتمد على النسخة المستخدمة. يميّز Meni Rosenfeld بين N الثابت البسيط وunit-PPLNS الأكثر تفصيلاً؛ فقد تُستغل القواعد الساذجة عند تغيّر صعوبة الشبكة أو قيمة الكتلة. يسجّل Unit-PPLNS لكل share بيانات تستند إلى صعوبة الشبكة ومكافأة الكتلة وقت تقديمها. وبذلك يمكن أن تراعي الدفعات اللاحقة الظروف التي أُنجز فيها العمل. وعند تعديل المعلمات، ينبغي للمشغّل الحفاظ على القيمة المتوقعة للعمل المقبول سابقاً. اسم الخدمة وحده لا يثبت أن حسابها يفعل ذلك فعلاً. [1]