إثبات المخاطر: نظرة داخلية

هناك الكثير من المقالات والنقاشات الفلسفية على الإنترنت ، ولكن لا توجد معلومات كافية عن الأسس الموضوعية. في مرحلة ما ، أدرك المؤلف أن الميكانيكا والعديد من الفروق الدقيقة المتعلقة بالأمن ليست مفهومة تمامًا حتى من قبل العديد من مطوري العملات المشفرة. تم الكشف عن ذلك في حالة حقيقية من نقل تطبيق PoS لأحد العملات المشفرة وفي نشر مزيد من المعلومات حول نقاط الضعف التي وجدها خبراء الطرف الثالث.

ستكون هذه المقالة مفيدة لجميع المطورين الذين واجهوا بالفعل نقاط ضعف PoS أو الذين ما زالوا قادمين.

بالرعب تحت خفض.

حبة التاريخ

على الإنترنت ، يتم تتبع ظهور Proof-of-Stake (PoS) في Peercoin بعد مناقشة حول أحد المنتديات في عام 2011 ، واستخدامه لاحقًا في Novaoin وتوزيعه الإضافي في PIVX وشوك Bitcoin الأخرى. تم نقل منطق kernel.h البدائي إلى حد ما إلى kernel.cpp / kernel.cpp ، والتي تتجول عبر مسافات الشوك في شكل وحدات فرانكشتاين المختلفة.

مرت خوارزمية PoS بعدة مراحل من التطوير ، حيث يقوم شخص ما بإعطائها نسخًا. الآن خيارات PoS مقسمة لأسباب طبيعية ، وقد ظهرت DPoS. أحد الحلول الأكثر تقدمًا هو بروتوكول Casper في Ethereum.

يتطلب أي blockchain توليد كتل ويجب أن يكون شخص ما لديه الحق في بناء كتلة جديدة. إذا كان المؤلف يفعل ذلك دون منافسة كبيرة في مثل هذه البلوك مثل نظام التحكم في إصدار Git ، فهناك في العملات المشفرة صراع حاد لمكافأة الكتلة في إطار Proof-of-Work (PoW) - إيجاد مثل هذا الجمع بين معلمات الإدخال المتغيرة عن طريق التحديد الذي يعطي نتيجة متوافقة مع يحددها هدف معين (التعدين ، التعدين).

يحل PoS محل إثبات العمل (PoW) لتجنب هدر الموارد على التعدين. بدلاً من ذلك ، يتم تعريف جميع معلمات الإدخال بدقة مع خاصية ثابتة تستند إلى المدخرات الحالية لحاملي العملات. لذلك ، PoW مطلوب كنقطة انطلاق لـ PoS ، إذا لم تلجأ إلى خيارات متعددة للإثراء المبدئي للرهن لمبدعي العملة.

لماذا؟

يعد توفير الطاقة أمرًا مهمًا للمطورين وحاملي العملات المعدنية مثل الحد من انبعاثات غازات الدفيئة للمنتجين والمستهلكين. الحقيقة القاسية مختلفة:

1. تخضع المشروعات القائمة على برنامج PoW لما يسمى "51 بالمائة من الهجمات": يمكن للمهاجمين الاستفادة من القوى الكبيرة وإنشاء سلسلة موازية ثم نشرها فجأة بحركة مختلفة من العملات المعدنية (مثل الهدر المزدوج) ،
2. يحتاج عمال المناجم الذين يعملون في مجال الطاقة إلى تغطية تكاليفهم والاستثمار في بناء القدرات - هذا هو التدفق المباشر لرأس المال من المشروعات ،
3. يريد أصحاب المدخرات الحفاظ على قوتها الشرائية من خلال رأس المال الذاتي ، بدلاً من النظر إلى التضخم الطبيعي.

على مثال حي: في نوفمبر إلى ديسمبر 2018 كانت هناك محاولات للهجمات ؛ ثم في شهري ديسمبر وفبراير ، كان هناك ضجة باعتبارها العملة الأكثر ربحية للتعدين على بطاقات الفيديو ؛ انخفض المعدل من 2+ إلى 0.5 دولار أمريكي ؛ بعد التحول إلى PoS ، ارتفع السعر إلى 1 دولار أمريكي في الأسبوع ، وزاد تدفق الاستثمارات.

النقاط الفنية

انتباه: في هذا القسم ، نتحدث عن نقاط البيع "التقليدية" في النموذج كما هي في Peercoin و PIVX وشوكهم.

تحتاج إلى فهم أنه لا يوجد مركزية ومحاسبة لـ "النقاط". في هذا الإصدار ، يعمل نفس مبدأ الحظ كما في PoW.

1. المصطلحات

المصطلحات عامة نسبيًا ، لكن في التطبيقات المختلفة ، تكون الفروق الدقيقة هي:

• هدف PoW - الهدف = الهدف الأساسي ، عادةً 2 ^ 240 (0x0000ffff ...) مقسومًا على تعقيد الكتلة (يزيد عدد الأصفار الموجودة في المقدمة).
• صعوبة البلوك - تعقيد الكتلة بالنسبة للهدف الأساسي ، يتم تحديده بشكل محدد استنادًا إلى معدل نمو السلسلة الحالي.
• UTXO - مخرجات المعاملات غير المنفقة ، زوج من تجزئة المعاملة ورقم الخروج.
• CoinBase هي معاملة خاصة مع مؤشر 0 في الكتلة التي تحتوي على المكافأة.
• Stake أو CoinStake هي معاملة خاصة مع فهرس 1 في كتلة.
• حصة المدخلات - UTXO التي تلبي متطلبات الرهان حسب الحجم والعمر.
• Stake Modifier - معلمة خاصة محددة بشكل محسوب لكل مدخلات Stake .
• Stake Hash هي نتيجة تجزئة يجب أن تكون أقل من حساب Stake Target .
• Stake Target - هو نفس هدف PoW ، ولكنه زاد نسبيًا بمقدار مقدار Stake Input بالنسبة إلى الحد الأدنى لعرض التسعير.
• توقيع كتلة - توقيع كتلة .
• شوكة - سلسلة المتفرعة.
• انقسام - تقاسم الشبكة.
• يتيم - كتل المهملة بسبب اختيار بديل آخر.

2. التشريح

عملية الجيل:

1. نجد جميع UTXO التي تلبي متطلبات Stake Input
2. العثور على حصة معدل.
3. ضرب هدف الهدف عن طريق إدخال حصة
   
   • في المليون في الواقع - هذا هو السبب في أن تجزئة 1 MH PoW تجريبية تخرج مساوية لعملة واحدة.
4. نحصل Stake Hash = H(Stake Modifier, Stake Block Time, UTXO output index, UTXO txid, Current Block Time) .
   
   • متغير المعلمة فقط كتلة الوقت الحالي
5. إذا كان Stake Hash >= Stake Target ، فحاول العثور على Current Block Time في النطاق المقبول.
   
   • تحتاج إلى النظر في إمكانية تجاوزات Stake Target عند ضربها بمقدار مقدار Stake Input وفقًا للتنفيذ.
6. نضع Coinbase في tx [0] ، و CoinStake في tx [1].
   
   • المستفيد من Coinbase هو نفس البرنامج النصي (العنوان) مثل Stake Input.
7. نحن نوقع الكتلة.

2.1. الوقت كتلة:

من السهل أن نرى أن عملية احتيال يمكن أن تعطي بعض الفائدة مع مرور الوقت. الإجماع القياسي يحد من الحدود الدنيا والعليا.

تقوم الدرجات السفلية دائمًا بتعيين متوسط ​​وقت الكتل على الكتل N الأخيرة ، عادة ما يزيد عن 11. وهذا هو التسامح لعدم دقة الوقت في إنشاء العقد.

تم تعيين الحد الأعلى التاريخي لـ PoW بإصبع إلى السماء في الساعة 2. زيادة الفواصل الزمنية يقلل من التعقيد ويجعل الفرع أقل جاذبية - وبالتالي ، فإنه لا معنى له. لكن بالنسبة إلى PoS ، فمن المنطقي.

يحدد PIVX وآخرون الوقت المستقبلي بحد أقصى 3 دقائق. يضع البعض قيودًا أشد ، لكن هذا يخلق مشاكل للمستخدمين. قررت بعض تطبيقات PoS تغيير الحد الأدنى للفواصل الزمنية للوقت الحالي من ثانية واحدة إلى 15-16 ثانية.

2.2. معدل حصة:

تم تصميم Stake Modifier كوسيلة لجعل التنبؤ صعبًا وبناء السلسلة المقبلة ، ولكن حدث خطأ ما ...

هناك العديد من الخيارات لحسابها: البتات الأخيرة من تجزئات الكتلة في نهايات الفواصل الزمنية المحددة تدريجياً ، [وليس للغاية] القيم المتنبأ بها بشكل سيء من الكتل السابقة ، إلخ. في بعض الأماكن ، يبدو الأمر وكأنه رمز غامض أكثر من كونه شيئًا عاقلًا.

الأصلي يأخذ فجوة من 64 فترات. وتنقسم هذه الفجوة تدريجيا إلى 64 أجزاء غير متكافئة. يتم تقريب الحدود إلى دقائق. عند الحدود ، يتم اختيار الكتل الموجودة ويتم أخذ بت واحد آخر منها. لذلك اتضح أن الرقم 64 بت ، شيء مشابه لـ Nonce.

الفاصل الزمني في Peercon هو 20 دقيقة ، لكن اللاعبين في PIVX قرروا أن الفترة الزمنية التي مدتها دقيقة واحدة ، تقريبًا إلى الدقيقة ، هي ما طلبه الطبيب.

بشكل عام ، في بعض التطبيقات مثل Blackcoin V2 + يتم إصلاح كل شيء ويتم حساب Stake Modifier من الرأس ، بينما في Peercoin V03 و PIVX و Blackcoin V1 وغيرها من كتلة Stake Input. هذا الأخير يدمر المعنى بالكامل تقريبًا. هناك افتراض أن الارتباك ذهب بسبب مشكلة عادية في تسمية المتغيرات ، وتحولات أكثر ولصق نسخة بدون تفكير. واكتشف المؤلف نفسه المشكلة في وقت متأخر جدًا بينما كان كل اهتمامه يركز على الحماية ضد DoS. لا ننشغل!

2.3. توقيع كتلة

نظرًا لأن التجزئة من الكتلة لم تعد بمثابة دليل على العمل ، ويمكن لأي شخص أن يأخذ معاملة CoinStake الموقعة من كتلة شخص آخر ، تحتاج إلى التحقق من أن الكتلة قد تم إنشاؤها بواسطة مالك Stake. لذلك ، يتم توقيع الرأس بنفس المفتاح الخاص كـ CoinStake.

2.4. CoinBase و CoinStake النصي الخروج

مطلوبة نفس البرامج النصية للخروج ، أو كما يدعو الناس عناوين المحفظة ، للحفاظ على الخصوصية وتجنب ربط العناوين الفردية في محفظة واحدة.

2.5 ماذا وأين؟

هناك اختلافات مختلفة حول كيفية تعاملهم مع المبالغ في CoinBase و CoinStake. المنطق والتحفيز في حالة معينة:

1. يجب الاحتفاظ بالمبالغ منفصلة لتجنب حتى أصغر خسارة ممكنة لأموال المستخدمين بسبب أخطاء المعالجة.
2. يحتفظ CoinBase بتأكيداته الـ 100 ، لكن يمكن صرف CoinStake على الفور ، مما يترك بالطبع خطر مضاعفة الإنفاق.
   
   • إن الانجراف إلى عمق الكتل يتناقض أيضًا مع مؤهلات العمر لاستخدامه كإدخال حصص.
3. يجب ألا تدخل CoinBase و CoinStake في mempool ، ويجب حذف جميع المعاملات التي تستند إليها أثناء إعادة إنشاء السلسلة.

3. كتل كاملة ضد الرؤوس

يبدأ إدخال عقدة كاملة في الشبكة مع التزامن. في Bitcoin ، تعتمد المزامنة في المقام الأول على رؤوس الكتل ، كما أنها تحتوي على معلومات كافية للتحقق الأولي من توافق الآراء. أولاً ، يتم سحب رؤوس صغيرة نسبياً وفحصها على دفعات تصل إلى 2000 قطعة من عقدة واحدة جانبية. في حالة نجاح الفحص الأولي ، يتم سحب جميع الكتل بالتوازي من جميع العقد المتصلة.

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

مع PoS ، هذا النهج لا يعمل ، لأنه للتحقق من الكتل ، تحتاج إلى معالجة الكتل السابقة الكاملة على الأقل حتى الحد الأدنى لسن الرهان. لم تبدأ عمليات التنفيذ التي عرضها المؤلف في الانحراف ، ولكنها رفضت ببساطة العمل مع الرؤوس.

لذلك ، قام المؤلف بتنفيذ تنزيل انتهازي متوازي للكتل التي تلي الرؤوس ، مما يزيد بشكل كبير من سرعة المزامنة بسبب استخدام جميع الاتصالات. تحدث التأخيرات الطفيفة فقط إذا كان أقرانهم في سلاسل مختلفة - ثم يتم قطع الاتصال بعد مهلة طفيفة كما هو الحال في المخطط القياسي. كطرح ، الميل إلى اختيار سلسلة خاطئة في وقت التزامن.

بالمناسبة ، قام عميل Bitcoin القياسي وشوكاته باختيار الحد الأدنى لعدد الاتصالات الصادرة لمدة 8 فترة كافية إذا فشل بعضها لأسباب مختلفة. تم حل هذا عن طريق الاتصالات الصادرة غير المتزامنة.

4. الشوك ، الإنشقاقات والأيتام

مع بناء كتلة المنافسة ، سلاسل بديلة من 1-2 وصلات شائعة نسبيا. تحدث الشوكات الأطول في الشبكات المتقدمة بشكل طبيعي فقط مع فشل ملحمي في الإجماع بسبب خطأ في البرمجة أو انقطاع عالمي للإنترنت.

حتى مع الفصل ، لا يوجد عادة تهديد لسلامة معالجة المعاملات ، كما عند فصل الكتل ، تعود جميع المعاملات إلى mempool ويتم تضمينها بالفعل في الكتل الأخرى. Mempool هو مستودع مؤقت للمعاملات بعد إنشائها. يتم حفظ Mempool نفسها إلى القرص في الإصدارات الأخيرة. يتم تدمير المكافأة للكتلة. هذا هو السبب في تعيين الحد الأدنى لعدد التأكيدات (العمق) للجوائز.

يحدث أن تفقد قطاعات الشبكة المحلية اتصالها بالعالم الخارجي وتواصل الاتصال بها ، على افتراض وجود اتصال بالشبكة الرئيسية. هذه الفروع عادة لا تشكل تهديداً بسبب ضعفها الطبيعي.

لقد تم بالفعل وصف الهجوم الرئيسي البالغ 51٪ لـ PoW أعلاه - فهو شديد الكثافة الاستخدام للموارد ، لكن بالنسبة إلى PoS فقد أصبح في المتناول نسبيًا. لهذا السبب ، أصبح من الممكن تقنيًا إنتاج العديد من الفروع من مختلف الروابط في السلسلة. أحد الحلول الكلاسيكية هو حظر الشوكات دون عمق معين.

المشكلة الرئيسية لمثل هذه الحماية هي عدم قدرة العقد من شرائح الناسك على العودة بشكل مستقل إلى الدائرة الرئيسية بعد إعادة التشغيل.

لذلك ، تم تطبيق نهج في حظر الشوكات الأقدم من فترة زمنية معينة فقط إذا كان الجزء العلوي من السلسلة صغيرًا جدًا.

مع فاصل زمني مستهدف من الكتل لمدة دقيقة واحدة ، تم اختيار معيار الشوكة القديمة في ساعة واحدة ، وهو ما يتوافق تقريبًا مع 60٪ من تأكيدات CoinBase ، ومعيار شباب التاج في 15 دقيقة أعلى 3 مرات من الحد الأقصى للتأخير الإحصائي للكتلة.

5. كتلة وتجزئة التجزئة

في PoW ، يغطي تجزئة الكتلة كل البيانات بالكامل. كما انها تستخدم للتحقق من الهدف. في PoS ، Stake Hash هي قيمة منفصلة لأن من الضروري استبعاد إمكانية اختياره. يفتح هذا التهديد الرئيسي - القدرة على إنتاج عدد غير محدود من الإصدارات المختلفة من الكتلة بناءً على نفس الحادثة المتزامنة ، والتي يسهل إغراقها ووضع الشبكة أو عقدها الفردية.

أساليب الدفاع الساذجة تؤدي إلى نقاط ضعف الانقسام أكثر خطورة. أحد هذه الأساليب في أشكال مختلفة هو السماح باستخدام Stake Input مرة واحدة فقط. الهجوم البسيط هو إرسال كتل مختلفة إلى عقد مختلفة ، مما يخلق على الفور انقسامًا بسيطًا.

الأمر الأكثر فتكًا هو تفاقم هذا من خلال حظر DoS ، الذي لن يقسم السلاسل فقط ، بل الشبكة نفسها إلى شرائح مختلفة.

تنشأ مشاكل أخرى - عدم القدرة على استخدام حصة من كتلة إسقاط.

لذلك ، تم اختيار طريقة الخانق باعتبارها الحل الأكثر أمانًا - لا يمكن استخدام نفس الرهان أكثر من مرة واحدة في الدقيقة. المنطق بسيط: لا يمكن أن يستمر الهجوم إلا في فاصل زمني مدته ساعة واحدة (انظر الشوكة القديمة أعلاه) ، حيث لا يمكن إغراق أكثر من 60 قطعة. في أفضل الأحوال ، على الكتلة التالية ، ستنتقل الشبكة بالفعل إلى دائرة واحدة. في أسوأ الأحوال ، مع هجوم مستمر ، سيحدث هذا في غضون ساعة. احتمال الأسوأ - العثور على عدة كتل متتالية ، يذوب بشكل كبير.

ومع ذلك ، تبقى بعض النقاط التي تكون فيها العقد عرضة للفيضان المعتدل حتى لحظة التزامن الكامل .

6. الحد الأدنى للسن

بالنسبة للبعض ، هذا القيد أمر محير ، لكنه مهم للغاية لاستقرار الشبكة ، كما هو ترتبط هذه المعلمة ارتباطًا مباشرًا بالحد الأقصى لطول الشبكة البديلة ، والتي ستتمكن العقدة المحلية من فحصها دون أي تشوهات تقنية خطيرة.

كما ذكرنا سابقًا ، يجب أن تقوم العقدة المحلية بمعالجة جميع الكتل حتى الحد الزمني للسن حتى تتمكن من التحقق من أن إدخال Stake In (أ) لديه مكان ليكون ب) هو UTXO حقًا ولم يتم إنفاقه.

تحقق هذا ممكن فقط من خلال وظيفة ما يسمى. CoinView ، وهي حالة حركة العملات المعدنية في وقت كتلة معينة - الجزء العلوي من السلسلة الرئيسية في فهم العقدة المحلية.

يبدو أن تطبيق اختبار كامل للدوائر البديلة على فترات زمنية أو حتى بطريقة خاصة يوفرها CoinView أمر غير واعد ، لأن عدد هذه السلاسل البديلة كبير بلا حدود.

شريط كبير جدًا بالنسبة لعمر UTXO يؤثر سلبًا على المستخدمين الذين يرغبون في إنفاق جزء من عملاتهم المعدنية أو الجمع بينها.

إذا حددت هذه الحدود في عمق الكتل ، فيمكن عندئذٍ وضع حالة من الجمود الافتراضي في سلسلة كاملة بسبب عدم وجود UTXO مناسب. في حالة الوحدات الزمنية ، تحدث بعض الحركة على الأقل.

لذلك ، يتم استخدام اختيار متوازن قدره ساعة واحدة في شبكات أخرى بوحدات زمنية مطلقة ، بدلاً من عمق الكتل.

7. ما هو أفضل من N UTXO لأدنى مبلغ أو UTXO واحد بإجمالي N؟

هنا يطرح التشبيه نفسه: الأفضل هو مسدس واحد بدقة 0.9 أو ثلاثة مسدسات بدقة 0.3 ، لكن مع احتمالات تصل إلى 1/2 ^ 20 ، يبدو أن نتائج مثل هذه الحسابات قد تم تسويتها. خريطة صغيرة تخلط بين استحقاق التأهيل.

الاعتقاد الحالي بأن العديد من المعاملات الصغيرة تجد المزيد من القطع ربما يعود تاريخها إلى عصر إدخال الحصص أيضًا في الاعتبار لتحديد الوزن. في ذلك الوقت ، كانت المعاملات الصغيرة القديمة ذات معنى.

في الوقت الحالي ، استنادًا إلى التجارب العملية والحسابات النظرية ، تجلب المجموعات المجمعة في UTXO الكبيرة المزيد من القطع. بالإضافة إلى ذلك ، يتطلب أقل UTXO عمل وحدة المعالجة المركزية أقل. شخص يدعي العكس.

فكر بنفسك.

8. تشغيل كتل إلى الأمام

عمال المناجم PoS يتفوق بشكل طبيعي كتلة مرات قليلا. هذا يؤثر على تعقيد الشبكة إلى الأسوأ. يحدد رمز Bitcoin القياسي أول كتلة تم استلامها ، بغض النظر عن الوقت المشار إليه فيه. معظم تطبيقات PoS تفعل الشيء نفسه.

لذلك ، تم تغيير منطق عامل المناجم PoS لبدء التحديد من متوسط ​​وقت الكتل إذا مضى وقت الكتلة الحالية إلى الأمام. في الوقت نفسه ، قبل مقارنة الترتيب ، تقارن العقد الوقت المحدد للكتل. يرسل عامل تعدين PoS الكتلة التي تم العثور عليها إلى الشبكة حتى إذا رأى أنها تنشئ شوكة.

وبهذه الطريقة ، تكون الشبكة محمية أيضًا من الكتل الافتراضية المرسلة قبل الأوان والتي لا يمكن استخدام Stake Input في غضون 60 ثانية مع نفس معدّل Stake بسبب حماية DoS. مثل العقاب المزدوج للغش مع مرور الوقت.

9. قائمة مرجعية صغيرة

1. يجب أن تكون مدخلات الحصص صالحة UTXO قبل نقطة الشوكة:
   
   • في حالة السلسلة الرئيسية ، نقطة الشوكة هي الطرف ،
   • في حالة وجود دائرة بديلة - يمكن أن تؤدي UTXO بعد نقطة الشوكة إلى مهام الخدمة الذاتية عند التبديل ،
   • لا ينبغي أن يكون UTXO في mempool بمفرده.
2. لا تقبل CoinStake في mempool عند إعادة بناء الدائرة الرئيسية:
   
   • يحدث الشيء نفسه مع CoinBase ،
   • هذا يمكن أن تدمر سلسلة المعاملات (من غير المرجح).
3. لا تقبل الشوك من الكتل القديمة إذا كان الجزء العلوي على قيد الحياة.
4. يعد الحد الأدنى للسن بالوحدات الزمنية المطلقة لإدخال الأسهم أمرًا ضروريًا لتحقيق الاستقرار والأمان.
5. يجب أن يتغير التجزئة Stake من وقت الكتلة فقط.
6. يجب ألا يكون "معدّل الأسهم" مرتبطًا بلوك "إدخال المدخلات".
7. يتطلب العمل مع رؤوس الكتل معالجة خاصة على الشبكة وأثناء إعادة الترجيع.
8. يتم تسجيل CoinStake في المحفظة المحلية وتتطلب بعض التغييرات لعرض orfans بشكل صحيح.
9. من المحتمل أن يكون لدى عمال المناجم في PoS عضادات كافية ويحتاجون إلى الانتهاء من ملف.
10. يحتاج إعادة الفهرس إلى التحسين ، لأن إنه يعمل عن طريق القياس مع الرؤوس - أولاً يتم تحميل وفحص فهرس الكتل فقط ، ثم يحاول معالجة الكتل فقط.
11. إذا كان الانتقال إلى PoS غير مشفر ، ولكن من خلال spork ، فأنت بحاجة إلى الإمساك به عند التشغيل ، لأن لا يتم حفظ الأشواك.
12. نقاط التفتيش في Dash و Bitcoin تكاد تكون خادعة وتتطلب مراجعة خطيرة للغاية.
13. إذا كان شوكة Dash يصل إلى الإصدار 0.13 ، فهناك مشاكل في معالجة بيانات masternode في وضع المستخدم البسيط.
    
    • مع إعادة التشغيل المتكرر للعميل ، يتم تشويه طريقة عرض الشبكة.
    • من الأفضل تجاهل ذاكرة التخزين المؤقت في حالة تشغيلها في الوضع الرسومي.
14. تغيير اختيار أفضل كتلة مع الأخذ في الاعتبار الوقت كتلة.
15. Bitcoin .
16. mempool CoinStake .

. mainnet PoW , , PoS, . PoS Ethereum Casper'.

GPU - — ethminer'. 150-200 GH (ethash). - PoS .

PoS PIVX 2.x " ". - PIVX , , . , PIVX 2.x . Dash 0.12 Bitcoin'.

, PoS . , , .

. . whitepaper -.

PoS PIVX Bitcoin/Dash. CoinStake . PoS .

, Stake Modifier Stake Hash , Stake Input . - , - PIVX .

— . :

1. .
2. .
3. — .. , .
4. , - , .

. spork' , .

, . spork' .

PoS

, - . spork, , .

, .. . , .

testnet, .

testnet 3 1 mainnet, .

PoW , PoS - , 1e6 PoW.

. mainnet Stake Input.

.

PoS

X spork PoS . - , .

. , . .

, , .

Stake Modifier . . PIVX - … , , Ethereum, .

الخاتمة

- , . , PoS , . .

: - .

GitHub