لقد أخذت إطار مخاطر SCRIPT الذي نشرته بنفسي @BabylonLabs_io وقارنته عبر TBV Testnet من طرف إلى آخر. والأكثر إثارة للاهتمام هو أنه من جهة مكتوب: “يجب ألا يكون لِحياة الضمانات أي تفويض/ترخيص”، ومن الجهة الأخرى يتم تحديد عتبة طوارئ لمجلس الأمن بمقدار 3/5 بوضوح.
هذا ليس بالضرورة تناقضًا، لكنه بالتحديد هو الفجوة التي تختبر مدى قيمة “trustless”.
تتطلب SCRIPT ستة أمور: يحتفظ المستخدم بالسيادة، تكون قواعد التصرف واضحة، لا يجوز إعادة/إعادة الرهن دون موافقة، كل موضع/حيازة يكون معزولًا، لا يستطيع طرف ثالث التدقيق، وحالة الضمانات يجب أن تكون شفافة. كأنك تضع ستة شروط قبول لخزنة: لمن المفتاح؟ ما شروط فتح الخزنة؟ هل يمكن أخذها كرهان ثانٍ؟ هل تُخلَط الخزائن؟ من الذي يستطيع أن يمنعك؟ وهل يمكن للخارج أن يتحقق/يعثر عليها؟
تتضح أفكار TBV بخصوص العزل والشفافية: يبقى BTC لكل مستخدم داخل “Bitcoin Vault” مستقل، وتقوم التطبيقات الخارجية بالتحقق من الحالة، دون خلط كل العملات في مجمع إيداع واحد. ومع ذلك، تكتب أيضًا في معلمات الـTestnet العامة الحالية أن Security Council يتكون من خمسة مقاعد، ويمكن لثلاثة توقيعات تنفيذ تدخل طارئ مماثل لـ CouncilNoPayout.
هنا يجب رسم الحدود بوضوح: إن 3/5 هي معطيات في الـTestnet العامة، ولا يمكن الاستنتاج مباشرة أن الشبكة الرئيسية في المستقبل ستطبق الشيء نفسه. وبسبب أن إجابة الشبكة الرئيسية ما تزال غير مؤكدة من هذه الصفحة، ينبغي اعتبار بقاء/تغيّر اللجنة وصلاحياتها بندًا للمراقبة على المدى الطويل، لا أن يكون ذلك نتيجة تُستكمل لصالح المشروع.
أنا أقر بأن “فرامل الطوارئ” لها قيمة واقعية خلال مرحلة الاختبار. فالنظام الجديد يتضمن سكربتات Bitcoin وتنسيقًا خارج السلسلة وعقود Ethereum؛ وعند اكتشاف أعطال خطيرة، قد لا يكون هناك زر لإيقاف النزيف (stop-loss) على الإطلاق، وقد لا يكون ذلك أقل أمانًا من وجود زر.
المشكلة أنه بعد وجود الأزرار، يجب الاستمرار في طرح الأسئلة: من الأعضاء؟ ما الشروط التي تتيح الضغط؟ هل يتم نشر الفعل كحدث مع تأخير أم بشكل فوري؟ وهل لدى المستخدم مسار خروج لا يعتمد على اللجنة؟
وهذا أيضًا هو المكان الذي ينبغي أن تراقبه الحوكمة الحقيقية لـ $BABY . ليس مجرد رؤية عبارة “حوكمة المجتمع” ثم افتراض تشتت الصلاحيات، بل مراقبة: في الشبكة الرئيسية المستقبلية، أي صلاحيات الطوارئ ستبقى؟ ومن يستطيع تعديل العتبة؟ وهل يمكن تتبّع كل إجراء على السلسلة؟ #baby لا يصوّت على “رؤية” مجردة، بل على حدود صلاحيات ملموسة.
موقفي: يمكن أن تكون لجنة الطوارئ درابزينًا خلال مرحلة البناء، لكن لا يمكن أن تكون دائمًا معفاة من الفحص بمجرد جملة “من أجل الأمان”. تحقق بنفسك أولًا. هل أنت مستعد لتبادل فرامل 3/5 مقابل الاستجابة للأعطال، أم أنك تعتقد أن النظام غير المصرّح لا ينبغي أن يحتفظ بهذا القاطع الرئيسي؟ اذكر رأيك في قسم التعليقات وافصلها نقطة بنقطة.
هذا ليس بالضرورة تناقضًا، لكنه بالتحديد هو الفجوة التي تختبر مدى قيمة “trustless”.
تتطلب SCRIPT ستة أمور: يحتفظ المستخدم بالسيادة، تكون قواعد التصرف واضحة، لا يجوز إعادة/إعادة الرهن دون موافقة، كل موضع/حيازة يكون معزولًا، لا يستطيع طرف ثالث التدقيق، وحالة الضمانات يجب أن تكون شفافة. كأنك تضع ستة شروط قبول لخزنة: لمن المفتاح؟ ما شروط فتح الخزنة؟ هل يمكن أخذها كرهان ثانٍ؟ هل تُخلَط الخزائن؟ من الذي يستطيع أن يمنعك؟ وهل يمكن للخارج أن يتحقق/يعثر عليها؟
تتضح أفكار TBV بخصوص العزل والشفافية: يبقى BTC لكل مستخدم داخل “Bitcoin Vault” مستقل، وتقوم التطبيقات الخارجية بالتحقق من الحالة، دون خلط كل العملات في مجمع إيداع واحد. ومع ذلك، تكتب أيضًا في معلمات الـTestnet العامة الحالية أن Security Council يتكون من خمسة مقاعد، ويمكن لثلاثة توقيعات تنفيذ تدخل طارئ مماثل لـ CouncilNoPayout.
هنا يجب رسم الحدود بوضوح: إن 3/5 هي معطيات في الـTestnet العامة، ولا يمكن الاستنتاج مباشرة أن الشبكة الرئيسية في المستقبل ستطبق الشيء نفسه. وبسبب أن إجابة الشبكة الرئيسية ما تزال غير مؤكدة من هذه الصفحة، ينبغي اعتبار بقاء/تغيّر اللجنة وصلاحياتها بندًا للمراقبة على المدى الطويل، لا أن يكون ذلك نتيجة تُستكمل لصالح المشروع.
أنا أقر بأن “فرامل الطوارئ” لها قيمة واقعية خلال مرحلة الاختبار. فالنظام الجديد يتضمن سكربتات Bitcoin وتنسيقًا خارج السلسلة وعقود Ethereum؛ وعند اكتشاف أعطال خطيرة، قد لا يكون هناك زر لإيقاف النزيف (stop-loss) على الإطلاق، وقد لا يكون ذلك أقل أمانًا من وجود زر.
المشكلة أنه بعد وجود الأزرار، يجب الاستمرار في طرح الأسئلة: من الأعضاء؟ ما الشروط التي تتيح الضغط؟ هل يتم نشر الفعل كحدث مع تأخير أم بشكل فوري؟ وهل لدى المستخدم مسار خروج لا يعتمد على اللجنة؟
وهذا أيضًا هو المكان الذي ينبغي أن تراقبه الحوكمة الحقيقية لـ $BABY . ليس مجرد رؤية عبارة “حوكمة المجتمع” ثم افتراض تشتت الصلاحيات، بل مراقبة: في الشبكة الرئيسية المستقبلية، أي صلاحيات الطوارئ ستبقى؟ ومن يستطيع تعديل العتبة؟ وهل يمكن تتبّع كل إجراء على السلسلة؟ #baby لا يصوّت على “رؤية” مجردة، بل على حدود صلاحيات ملموسة.
موقفي: يمكن أن تكون لجنة الطوارئ درابزينًا خلال مرحلة البناء، لكن لا يمكن أن تكون دائمًا معفاة من الفحص بمجرد جملة “من أجل الأمان”. تحقق بنفسك أولًا. هل أنت مستعد لتبادل فرامل 3/5 مقابل الاستجابة للأعطال، أم أنك تعتقد أن النظام غير المصرّح لا ينبغي أن يحتفظ بهذا القاطع الرئيسي؟ اذكر رأيك في قسم التعليقات وافصلها نقطة بنقطة.
