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