في البداية افترضت أن الشيء الوحيد الذي قد يُعرِّض مزوّد الحسم <Finality Provider> لمكانته للخطر هو السلوك الخبيث الصريح: توقيع كتلتين متعارضتين، والوقوع في الفضيحة، ثم التعرض للخصم (slashing)، وهي الثنائية المعتادة بين الصادق وغير الصادق. عند قراءة وثائق وحدة الحسم <Finality module> الخاصة ببابل <Babylon>، وجدت مسار فشل ثانٍ أكثر هدوءًا لا علاقة له بالأمانة على الإطلاق. قبل أن يتمكن مزوّد الحسم حتى من التصويت على كتلة، يتعين عليه بشكل استباقي الالتزام بعشوائية EOTS العامة لذلك الارتفاع <height> المستقبلي تحديدًا، مسبقًا، قبل اقتراح الكتلة حتى. ينظّم نظام بابل بشكل منفصل فئتين من مقدّمي الخدمة المثيرين للمشكلات: المراوغون الذين يتم ضبطهم وهم يوقّعون رسائل متعارضة، والذين يتسمون بالبطء (sluggish) والذين ببساطة يفشلون في الحضور في الوقت المحدد. إن البطء ليس انتهاكًا مماثلًا لعدم الأمانة، لكنه مع ذلك يُسجَّل ويُعاقَب كفئة مستقلة. ما يعنيه ذلك عمليًا هو أن مزوّد الخدمة يمكن أن يكون صادقًا بالكامل: لا يوقّع أبدًا أي شيء متعارض، ولا يحاول أي سلوك عدائي، ومع ذلك يفقد القدرة على التصويت لارتفاع معيّن فقط لأن التزامه بالعشوائية لم يواكب الطرح حتى لحظة حد السلسلة <chain's tip>. إن الالتزام بالعشوائية ليس خطوة إعداد لمرة واحدة؛ بل هو عمل تنبؤ مستمر، يتمثل في البقاء متقدمًا على سلسلة تواصل التحرك سواء كنت جاهزًا أم لا. لذا فإن نموذج الأمان الفعلي الموصوف ليس مجرد مقارنة بين الصادق والخبيث. بل هو مقارنة بين الصادق والمتقيد بالمواعيد مقابل الجميع الآخرين، بما في ذلك مزوّدي الحسم الأوفياء الذين ببساطة تأخروا عن شرط جدولة ربما لا يفكر معظم من يقومون بالرهان عليهم أصلًا في التحقق منه.
@BabylonLabs_io #baby $BABY