#baby $BABY منتصف الليل لا أستطيع النوم، فخلّوني أنا وأصحابي نفصّل الكلام عن Babylon التي صارت حديث الساعة مؤخرًا (#baby $BABY @BabylonLabs_io ). بصراحة، عندما كنت أبحث في سكربتات الرهن الخاصة بهم، طلع في دماغي سؤال كبير جدًا: بما أنّ المشروع يضع كل يوم عبارة «الاستضافة الذاتية البحتة» على لسانه، فلماذا يُدخلون «لجنة العهد» (Covenant Committee) كوسيط بينهم؟ أليس هذا زيادة غير لازمة تُضيف مخاطر ثقة إضافية بلا سبب؟ في البداية، اعتقدت فعلًا أنّ هذا حلّ وسط فرضته عليهم جهة التطوير لأنهم لا يقدرون على إنجاز الأمور تقنيًا.
لكن خلال اليومين الماضيين، وبعد أن غصّيت في الورقة البيضاء والوثائق التقنية الأساسية، اتضح أنني كنت مخطئًا. هذه المسؤولية لا ينبغي أن يحملها Babylon وحدها؛ بل يجب أن يحمله النظام نفسه.
الإخوة اللي فاهمين تقنية يعرفون أن سكربتات البيتكوين الأصلية «غبية» جدًا؛ لا يمكنها كتابة منطق معقّد للجزاءات وإلغاء القفل بشروط مباشرة. وفريق Babylon أيضًا كان مضطرًا؛ لذلك لجأوا إلى التفافٍ ذكي: إنشاء لجنة توقيع بنظام العتبة. في الحقيقة، دور هؤلاء هو أن يعملوا كـ«موقّعين مشترَكين» عندما يتم التحرير المبكر (Unbonding) أو عندما يلزم فرض الجزاءات على أحدٍ يسيء التصرف (Slashing)، لضمان أن الأموال لا تمشي إلا وفق القواعد المُحددة مسبقًا.
إذا فهمت هذا، ارتحت. ميزة Babylon الأساسية والرائعة هي «الرقص مع القيود»—أي أنهم ضمن شرط عدم المساس مطلقًا بخطّ البيتكوين الأحمر (إجماع الطبقة الأساسية)، نجحوا في شق طريق رهن يمكن التحكم فيه وقابل للمعاقبة. بالطبع توجد تكلفة: صار النظام أكثر تعقيدًا، ولا بد أن يظل المستثمرون الصغار مثلنا يراقبون كل حلقة. لكن في عالم الهندسة هذا يُسمّى توازنًا عمليًا: نحل مشكلة الانطلاق من الصفر أولًا، ثم نلاحق الكمال لاحقًا.
ومع ذلك، أحتفظ ببعض الحذر. لا يمكن أن نستثمر فقط وفق ما يحدث الآن؛ ما يهمني ليس ما إذا كانت هذه اللجنة قد تُسيء التصرف اليوم، بل ما إذا كانت سلطتها قد تتمدد خفيةً مع الترقية مستقبلًا. والأبعد من ذلك: إذا جاء يومٌ ما في المستقبل، وحدثت بالفعل ترقية كبيرة في سكربتات البيتكوين الأصلية (مثل ضجة OP_CAT العالية التي قد تمر)، فسيصبح باستطاعة النظام نفسه تنفيذ هذه الأعمال المعقّدة. عندها، هل ستقوم Babylon فورًا بإحضار هذه «اللجنة» إلى متحف التاريخ؟ وهل يمكن لهذا التصميم أن ينسحب بأمان كامل؟ هذا هو جوهر «نقطة القوة الحقيقية» للمشروع على المدى الطويل، وسنترقّب النتائج.
لكن خلال اليومين الماضيين، وبعد أن غصّيت في الورقة البيضاء والوثائق التقنية الأساسية، اتضح أنني كنت مخطئًا. هذه المسؤولية لا ينبغي أن يحملها Babylon وحدها؛ بل يجب أن يحمله النظام نفسه.
الإخوة اللي فاهمين تقنية يعرفون أن سكربتات البيتكوين الأصلية «غبية» جدًا؛ لا يمكنها كتابة منطق معقّد للجزاءات وإلغاء القفل بشروط مباشرة. وفريق Babylon أيضًا كان مضطرًا؛ لذلك لجأوا إلى التفافٍ ذكي: إنشاء لجنة توقيع بنظام العتبة. في الحقيقة، دور هؤلاء هو أن يعملوا كـ«موقّعين مشترَكين» عندما يتم التحرير المبكر (Unbonding) أو عندما يلزم فرض الجزاءات على أحدٍ يسيء التصرف (Slashing)، لضمان أن الأموال لا تمشي إلا وفق القواعد المُحددة مسبقًا.
إذا فهمت هذا، ارتحت. ميزة Babylon الأساسية والرائعة هي «الرقص مع القيود»—أي أنهم ضمن شرط عدم المساس مطلقًا بخطّ البيتكوين الأحمر (إجماع الطبقة الأساسية)، نجحوا في شق طريق رهن يمكن التحكم فيه وقابل للمعاقبة. بالطبع توجد تكلفة: صار النظام أكثر تعقيدًا، ولا بد أن يظل المستثمرون الصغار مثلنا يراقبون كل حلقة. لكن في عالم الهندسة هذا يُسمّى توازنًا عمليًا: نحل مشكلة الانطلاق من الصفر أولًا، ثم نلاحق الكمال لاحقًا.
ومع ذلك، أحتفظ ببعض الحذر. لا يمكن أن نستثمر فقط وفق ما يحدث الآن؛ ما يهمني ليس ما إذا كانت هذه اللجنة قد تُسيء التصرف اليوم، بل ما إذا كانت سلطتها قد تتمدد خفيةً مع الترقية مستقبلًا. والأبعد من ذلك: إذا جاء يومٌ ما في المستقبل، وحدثت بالفعل ترقية كبيرة في سكربتات البيتكوين الأصلية (مثل ضجة OP_CAT العالية التي قد تمر)، فسيصبح باستطاعة النظام نفسه تنفيذ هذه الأعمال المعقّدة. عندها، هل ستقوم Babylon فورًا بإحضار هذه «اللجنة» إلى متحف التاريخ؟ وهل يمكن لهذا التصميم أن ينسحب بأمان كامل؟ هذا هو جوهر «نقطة القوة الحقيقية» للمشروع على المدى الطويل، وسنترقّب النتائج.
