@BabylonLabs_io
كنت أقرأ قسم ورقة عمل بايندون/Babylon الخاص بخصائص الأقبية (vault)، ووقفت عند عبارة صغيرة واحدة أوقفتني: «المُطالب المُحدد مسبقًا» (pre-set claimer). في البداية بدا الأمر كمتطلب تقني فحسب: مجموعة الأطراف المسموح لها بالمطالبة واسترداد/سحب البيتكوين يجب أن تُعرَّف لحظة إنشاء القبو. لكن كلما جلست معها أكثر، شعرت أنها ليست مجرد شرط، بل قرار تصميم هادئ يغيّر كل شيء فيما يتعلق بمن يمكنه حتى محاولة لمس الأموال.
والذي يبدو مثيرًا للاهتمام هو ما الذي يستبعده هذا فعليًا. لا أحد خارج تلك المجموعة المحددة مسبقًا يمكنه تقديم مطالبة على الإطلاق، حتى لو حاول ببرهان ذكي أو باستغلال تقني، لأن القبو ببساطة لن يتعرف عليهم كأطراف مؤهلة. يجعلني ذلك أفكر في أنها تُقلّص سطح الهجوم قبل أن يدخل أي تشفير في الصورة، تقريبًا مثل إزالة أبواب إضافية من مبنى بدلًا من مجرد إضافة أقفال أفضل للأبواب الموجودة.
ومع ذلك، لست متأكدًا تمامًا أنها خالية من المقايضات. تثبيت مجموعة المُطالب (claimer) عند الإنشاء يعني أن هناك مساحة صغيرة جدًا للمرونة لاحقًا؛ فماذا يحدث إذا تغيّرت الظروف، أو تطورت علاقة الإقراض، أو تم اختراق مفتاح المُطالب في مرحلة لاحقة؟ هل هذه الصلابة التي تجعلها أكثر أمانًا تجعلها أيضًا غير مرنة إلى حد ما مقارنة بالأنظمة التي تسمح بإدارة صلاحيات ديناميكية؟
ومن زاوية من الخارج، يبدو الأمر كما لو أن Babylon اختارت قابلية التوقع على حساب التكيّف؛ راهنت أن سطح هجوم أصغر وثابت يستحق أكثر من المرونة التي قد لا يحتاجها معظم المستخدمين على أي حال. وهل يَصمد هذا الافتراض مع بناء منتجات DeFi أكثر تعقيدًا فوق TBV، شيء لا أستطيع الحكم عليه بالكامل بعد. ربما يكون هذا هو الاختبار الحقيقي في الطريق... في النهاية، الوقت سيخبر👍
$BROCCOLIF3B
$ON
$BABY
#baby
كنت أقرأ قسم ورقة عمل بايندون/Babylon الخاص بخصائص الأقبية (vault)، ووقفت عند عبارة صغيرة واحدة أوقفتني: «المُطالب المُحدد مسبقًا» (pre-set claimer). في البداية بدا الأمر كمتطلب تقني فحسب: مجموعة الأطراف المسموح لها بالمطالبة واسترداد/سحب البيتكوين يجب أن تُعرَّف لحظة إنشاء القبو. لكن كلما جلست معها أكثر، شعرت أنها ليست مجرد شرط، بل قرار تصميم هادئ يغيّر كل شيء فيما يتعلق بمن يمكنه حتى محاولة لمس الأموال.
والذي يبدو مثيرًا للاهتمام هو ما الذي يستبعده هذا فعليًا. لا أحد خارج تلك المجموعة المحددة مسبقًا يمكنه تقديم مطالبة على الإطلاق، حتى لو حاول ببرهان ذكي أو باستغلال تقني، لأن القبو ببساطة لن يتعرف عليهم كأطراف مؤهلة. يجعلني ذلك أفكر في أنها تُقلّص سطح الهجوم قبل أن يدخل أي تشفير في الصورة، تقريبًا مثل إزالة أبواب إضافية من مبنى بدلًا من مجرد إضافة أقفال أفضل للأبواب الموجودة.
ومع ذلك، لست متأكدًا تمامًا أنها خالية من المقايضات. تثبيت مجموعة المُطالب (claimer) عند الإنشاء يعني أن هناك مساحة صغيرة جدًا للمرونة لاحقًا؛ فماذا يحدث إذا تغيّرت الظروف، أو تطورت علاقة الإقراض، أو تم اختراق مفتاح المُطالب في مرحلة لاحقة؟ هل هذه الصلابة التي تجعلها أكثر أمانًا تجعلها أيضًا غير مرنة إلى حد ما مقارنة بالأنظمة التي تسمح بإدارة صلاحيات ديناميكية؟
ومن زاوية من الخارج، يبدو الأمر كما لو أن Babylon اختارت قابلية التوقع على حساب التكيّف؛ راهنت أن سطح هجوم أصغر وثابت يستحق أكثر من المرونة التي قد لا يحتاجها معظم المستخدمين على أي حال. وهل يَصمد هذا الافتراض مع بناء منتجات DeFi أكثر تعقيدًا فوق TBV، شيء لا أستطيع الحكم عليه بالكامل بعد. ربما يكون هذا هو الاختبار الحقيقي في الطريق... في النهاية، الوقت سيخبر👍
$BROCCOLIF3B
$ON
$BABY
#baby