@BabylonLabs_io $BABY #baby
$VIC في الأعلى.. الآن، لكن دعونا نتحدث عن @BabylonLabs_io أولًا.
دخلتُ في وثائق Babylon معتقدًا أن المفاتيح المختلفة هي في الأساس نسخ احتياطية لنفس الهوية.
كلما قرأت أكثر، قلّ منطقية تلك الفكرة.
مزود نهائية (Finality Provider) يحمل في الواقع مسؤوليات منفصلة عبر مفاتيح مختلفة. يُستخدم مفتاح EOTS لتوليد العشوائية وتوقيع تصويتات النهائية. وفي المقابل، يثبّت مفتاح Genesis هوية المزود، ووجهة المكافآت، ووظائف إدارية أخرى.
ما لفت انتباهي هو أن هذه الهويات ترتبط بشكل دائم عندما يسجّل المزود. فهي ليست مصممة لكي يتم تبديلها لاحقًا ضمن العمليات العادية.
وهذا يخلق نوعين مختلفين تمامًا من حالات الفشل.
إذا فُقد مفتاح EOTS، فلن يستطيع المزود المشاركة بعد الآن في التصويت على النهائية. لكن إذا فُقد مفتاح Genesis، فقد يحدث شيء أكثر دقة. قد يستمر المزود في توقيع الكتل بشكل طبيعي بينما يفقد التحكم العملي في إدارة المكافآت. يعالج تصميم Babylon ذلك عبر التوصية بمفتاح تشغيل منفصل وقابل للتدوير لإدارة الروتين، مما يسمح ببقاء مفتاح Genesis غير متصل بالإنترنت ومحميًا.
هذه هي تفاصيل أظن أنها قد تختفي خلف لوحة تحكم تبدو سليمة
قد يظل مزود النهائية يبدو نشطًا لأن التوقيعات ما زالت تصل في الوقت المحدد. من الخارج، يمكن أن تبدو كل الأمور طبيعية. ومع ذلك، قد يكون الجانب الاقتصادي للعملية بالفعل مقفلًا خلف بيانات اعتماد لم يعد بالإمكان الوصول إليها.
كلما جلستُ مع هذا التصميم، شعرت أكثر أنه في Babylon يفصلون بشكل متعمد بين الاستمرارية التشغيلية والتحكم الإداري. في البداية بدا الأمر غير مريح. الآن أعتقد أنه تذكير بأن الأمان لا يقتصر فقط على منع الهجمات. أحيانًا يكون الأمر أيضًا التأكد من أن خطأ واحدًا لا يؤدي فورًا إلى المساس بكل المسؤوليات في الوقت نفسه.
ما أستمر في التساؤل عنه هو: هل سيلاحظ المشغلون، أثناء حادثة حقيقية لفقدان مفتاح، فقدان التحكم الإداري قبل أن يلاحظ المفوضون (delegators) أي شيء غير معتاد على الإطلاق.
$VIC في الأعلى.. الآن، لكن دعونا نتحدث عن @BabylonLabs_io أولًا.
دخلتُ في وثائق Babylon معتقدًا أن المفاتيح المختلفة هي في الأساس نسخ احتياطية لنفس الهوية.
كلما قرأت أكثر، قلّ منطقية تلك الفكرة.
مزود نهائية (Finality Provider) يحمل في الواقع مسؤوليات منفصلة عبر مفاتيح مختلفة. يُستخدم مفتاح EOTS لتوليد العشوائية وتوقيع تصويتات النهائية. وفي المقابل، يثبّت مفتاح Genesis هوية المزود، ووجهة المكافآت، ووظائف إدارية أخرى.
ما لفت انتباهي هو أن هذه الهويات ترتبط بشكل دائم عندما يسجّل المزود. فهي ليست مصممة لكي يتم تبديلها لاحقًا ضمن العمليات العادية.
وهذا يخلق نوعين مختلفين تمامًا من حالات الفشل.
إذا فُقد مفتاح EOTS، فلن يستطيع المزود المشاركة بعد الآن في التصويت على النهائية. لكن إذا فُقد مفتاح Genesis، فقد يحدث شيء أكثر دقة. قد يستمر المزود في توقيع الكتل بشكل طبيعي بينما يفقد التحكم العملي في إدارة المكافآت. يعالج تصميم Babylon ذلك عبر التوصية بمفتاح تشغيل منفصل وقابل للتدوير لإدارة الروتين، مما يسمح ببقاء مفتاح Genesis غير متصل بالإنترنت ومحميًا.
هذه هي تفاصيل أظن أنها قد تختفي خلف لوحة تحكم تبدو سليمة
قد يظل مزود النهائية يبدو نشطًا لأن التوقيعات ما زالت تصل في الوقت المحدد. من الخارج، يمكن أن تبدو كل الأمور طبيعية. ومع ذلك، قد يكون الجانب الاقتصادي للعملية بالفعل مقفلًا خلف بيانات اعتماد لم يعد بالإمكان الوصول إليها.
كلما جلستُ مع هذا التصميم، شعرت أكثر أنه في Babylon يفصلون بشكل متعمد بين الاستمرارية التشغيلية والتحكم الإداري. في البداية بدا الأمر غير مريح. الآن أعتقد أنه تذكير بأن الأمان لا يقتصر فقط على منع الهجمات. أحيانًا يكون الأمر أيضًا التأكد من أن خطأ واحدًا لا يؤدي فورًا إلى المساس بكل المسؤوليات في الوقت نفسه.
ما أستمر في التساؤل عنه هو: هل سيلاحظ المشغلون، أثناء حادثة حقيقية لفقدان مفتاح، فقدان التحكم الإداري قبل أن يلاحظ المفوضون (delegators) أي شيء غير معتاد على الإطلاق.
