#baby $BABY أمس فككتُ مستندات EOTS الخاصة بـ @BabylonLabs_io سطرًا سطرًا، فوجدتُ تفصيلًا خطيرًا تحجبُه هالة "إيداع BTC الأصلي": العقوبة ليست تصاعدية، بل تفجيرية.
في PoS التقليدي، إذا أخطأ المُتحقّقُ في توقيع كتلة، تكون العقوبة على شكل درجات—يُخصَم مبلغ بسيط أولًا مع فرصة للتصحيح. لكن ضمن آلية EOTS في BABY، فيمكن لارتفاع كتلة واحد فقط أن يحتوي على توقيع صالح واحد. إذا حدث توقيع مزدوج بسبب انحراف ساعة الخادم، أو تبديل النسخ الاحتياطي السريع، أو خطأ في الكود، فإن المفتاح الخاص سيُعاد حسابه رياضيًا ويُكشف فورًا. الـ 1 BTC الذي قمتَ بتأمينه سيتم خصمه بالكامل على الشبكة الرئيسية، دون تحذير، ودون فرصة ثانية.
لقد استنتجتُ هذا السيناريو: قام FP بنشر عقدة أساسية وعقدة احتياطية؛ حيث تتسبب اهتزازات الشبكة في العقدة الأساسية في خطأ حكمٍ بميلي ثانية في العقدة الاحتياطية، فتكون كلتاهما قد وقّعتا كتلتين عند نفس الارتفاع. في PoS على إيثيريوم، قد تؤدي هذه الزلة إلى غرامة بضعة آلاف من الدولارات فقط؛ أما في Babylon، فهذه تعني الصفر المباشر لـ 1 BTC.
والأكثر إزعاجًا هو أن الأفراد (المنفردون) يشاركون بنقرة واحدة عبر بروتوكول LST، ولا يرون إدارة المفاتيح والاستراتيجية الاحتياطية خلف FP. أنت لا تتحمل فقط مخاطر Slash الخاصة بالبروتوكول، بل تتحمل كذلك بشكل إضافي مخاطر مراجعة الكود لفريق التشغيل وجودة مصدر العشوائية (الانتروبيا).
عائدٌ مرتفع يعني عدم وجود هامش خطأ. ما لم توجد في المستقبل وثيقة تأمين احتجازٍ ناضجة أو تكرار متعدد التواقيع مُلزم، فعندما يرى الأفراد رواية الأمان الخاصة بـ "إيداع BTC الأصلي"، دعهم أولًا يحسبوا ما إذا كان لدى FP نسخ احتياطية تعمل في وضع الحار (hot backup). هذه الجملة أقولها لنفسي، وربما لأنني قمتُ بأكثر من اللازم عندما أعددتُ النسخ الاحتياطية.#baby BABY@BabylonLabs_io
في PoS التقليدي، إذا أخطأ المُتحقّقُ في توقيع كتلة، تكون العقوبة على شكل درجات—يُخصَم مبلغ بسيط أولًا مع فرصة للتصحيح. لكن ضمن آلية EOTS في BABY، فيمكن لارتفاع كتلة واحد فقط أن يحتوي على توقيع صالح واحد. إذا حدث توقيع مزدوج بسبب انحراف ساعة الخادم، أو تبديل النسخ الاحتياطي السريع، أو خطأ في الكود، فإن المفتاح الخاص سيُعاد حسابه رياضيًا ويُكشف فورًا. الـ 1 BTC الذي قمتَ بتأمينه سيتم خصمه بالكامل على الشبكة الرئيسية، دون تحذير، ودون فرصة ثانية.
لقد استنتجتُ هذا السيناريو: قام FP بنشر عقدة أساسية وعقدة احتياطية؛ حيث تتسبب اهتزازات الشبكة في العقدة الأساسية في خطأ حكمٍ بميلي ثانية في العقدة الاحتياطية، فتكون كلتاهما قد وقّعتا كتلتين عند نفس الارتفاع. في PoS على إيثيريوم، قد تؤدي هذه الزلة إلى غرامة بضعة آلاف من الدولارات فقط؛ أما في Babylon، فهذه تعني الصفر المباشر لـ 1 BTC.
والأكثر إزعاجًا هو أن الأفراد (المنفردون) يشاركون بنقرة واحدة عبر بروتوكول LST، ولا يرون إدارة المفاتيح والاستراتيجية الاحتياطية خلف FP. أنت لا تتحمل فقط مخاطر Slash الخاصة بالبروتوكول، بل تتحمل كذلك بشكل إضافي مخاطر مراجعة الكود لفريق التشغيل وجودة مصدر العشوائية (الانتروبيا).
عائدٌ مرتفع يعني عدم وجود هامش خطأ. ما لم توجد في المستقبل وثيقة تأمين احتجازٍ ناضجة أو تكرار متعدد التواقيع مُلزم، فعندما يرى الأفراد رواية الأمان الخاصة بـ "إيداع BTC الأصلي"، دعهم أولًا يحسبوا ما إذا كان لدى FP نسخ احتياطية تعمل في وضع الحار (hot backup). هذه الجملة أقولها لنفسي، وربما لأنني قمتُ بأكثر من اللازم عندما أعددتُ النسخ الاحتياطية.#baby BABY@BabylonLabs_io