@BabylonLabs_io #baby $BABY
قبل كتابة هذه المشاركة، تحدّيت افتراضًا واحدًا كنت أملكه عن بابل.
كنت أعتقد أن الإجهاض/القطع (slashing) يدور أساسًا حول معاقبة مُقدّمي النهاية (Finality Providers) الخبيثين. بعد دراسة التنفيذ، خرجت بنتيجة مختلفة. يستثمر بابل جهدًا هندسيًا قدره تقريبًا منع المشغّلين الأمناء من إنشاء توقيعات غير آمنة أثناء الاسترداد، كما يستثمر في اكتشاف السلوك الخبيث.
هذا أحد أقوى القرارات المعمارية للبروتوكول. بدلًا من افتراض بنية تحتية مثالية، يفترض أن التعطّلات، وأخطاء البرمجيات، وتأخر استجابات RPC، والترقيات المتقطعة أمر لا مفرّ منه. الهدف ليس فقط تحديد السلوك غير الصالح بعد حدوثه، بل تقليل الظروف التي يمكن أن يحدث فيها أصلًا.
التفصيل الذي غيّر وجهة نظري هو الفصل بين مُعيّن/خدمة شيّاع النهاية (Finality Provider Daemon) ومدير EOTS. أحدهما يحدد متى ينبغي إنتاج التصويت. والآخر يحدد بشكل مستقل ما إذا كان إنتاج تلك التوقيع/الـ signature ما يزال صالحًا. لقد صمّموا عمدًا حالات تشغيل مختلفة، ليجعلوا هناك تحققين مستقلين قبل أن يمكن أن توجد توقيع جديد.
تترتب على ذلك دلالة أعمق تتجاوز علم التشفير. بابل تحمي سجل/تاريخ القرارات بجانب المفاتيح الخاصة. المفتاح يثبت من وقّع رسالة. أما حالة التوقيع التاريخية فتحدد ما إذا كان توقيع تلك الرسالة ما يزال شرعيًا. هذه ضمانات أمنية مختلفة، ومع ذلك كلاهما مطلوبان لجعل بنية تحتية مقاومة للـ slashing موثوقة.
فرق/تضحية (Trade-off) الأمر كذلك مهم. مع نمو الرهن/التعهد في بيتكوين (Bitcoin staking)، يعتمد أمن البروتوكول بشكل متزايد على صحة التشغيل. يصبح استرداد الحالة، والتواصل الموثّق، والبنية التحتية المنضبطة جزءًا من نموذج الثقة بدلًا من كونها تفاصيل تنفيذ.
إذا استمر تطوير Bitcoin staking في هذا الاتجاه، فهل ينبغي أن نقيم الأمان فقط عبر مقدار الرهان الاقتصادي، أم أيضًا عبر جودة الأنظمة التي تحافظ على صحة التشفير قبل أن يتم إنشاء توقيع أصلًا؟💭
$BTC $ETH @Binance Square Official
#Bitcoin
#BTCStaking
#BlockchainInfrastructure
قبل كتابة هذه المشاركة، تحدّيت افتراضًا واحدًا كنت أملكه عن بابل.
كنت أعتقد أن الإجهاض/القطع (slashing) يدور أساسًا حول معاقبة مُقدّمي النهاية (Finality Providers) الخبيثين. بعد دراسة التنفيذ، خرجت بنتيجة مختلفة. يستثمر بابل جهدًا هندسيًا قدره تقريبًا منع المشغّلين الأمناء من إنشاء توقيعات غير آمنة أثناء الاسترداد، كما يستثمر في اكتشاف السلوك الخبيث.
هذا أحد أقوى القرارات المعمارية للبروتوكول. بدلًا من افتراض بنية تحتية مثالية، يفترض أن التعطّلات، وأخطاء البرمجيات، وتأخر استجابات RPC، والترقيات المتقطعة أمر لا مفرّ منه. الهدف ليس فقط تحديد السلوك غير الصالح بعد حدوثه، بل تقليل الظروف التي يمكن أن يحدث فيها أصلًا.
التفصيل الذي غيّر وجهة نظري هو الفصل بين مُعيّن/خدمة شيّاع النهاية (Finality Provider Daemon) ومدير EOTS. أحدهما يحدد متى ينبغي إنتاج التصويت. والآخر يحدد بشكل مستقل ما إذا كان إنتاج تلك التوقيع/الـ signature ما يزال صالحًا. لقد صمّموا عمدًا حالات تشغيل مختلفة، ليجعلوا هناك تحققين مستقلين قبل أن يمكن أن توجد توقيع جديد.
تترتب على ذلك دلالة أعمق تتجاوز علم التشفير. بابل تحمي سجل/تاريخ القرارات بجانب المفاتيح الخاصة. المفتاح يثبت من وقّع رسالة. أما حالة التوقيع التاريخية فتحدد ما إذا كان توقيع تلك الرسالة ما يزال شرعيًا. هذه ضمانات أمنية مختلفة، ومع ذلك كلاهما مطلوبان لجعل بنية تحتية مقاومة للـ slashing موثوقة.
فرق/تضحية (Trade-off) الأمر كذلك مهم. مع نمو الرهن/التعهد في بيتكوين (Bitcoin staking)، يعتمد أمن البروتوكول بشكل متزايد على صحة التشغيل. يصبح استرداد الحالة، والتواصل الموثّق، والبنية التحتية المنضبطة جزءًا من نموذج الثقة بدلًا من كونها تفاصيل تنفيذ.
إذا استمر تطوير Bitcoin staking في هذا الاتجاه، فهل ينبغي أن نقيم الأمان فقط عبر مقدار الرهان الاقتصادي، أم أيضًا عبر جودة الأنظمة التي تحافظ على صحة التشفير قبل أن يتم إنشاء توقيع أصلًا؟💭
$BTC $ETH @Binance Square Official
#Bitcoin
#BTCStaking
#BlockchainInfrastructure
