يتجمع أربعة أطراف حول عملة BTC واحدة ويعملون عليها، لكن لا يملك أي فريق منهم صلاحية كاملة لنقلها بعيدًا. بعد إعادة رسم مخطط شخصية @BabylonLabs_io ، اكتشفت أن عبارة «لا ثقة» ليست لأن النظام بلا أحد، بل لأن كل شخص يحصل على جزء من الصلاحيات فقط.
يرى فريق VP كمشرف مشروع. يتم اختياره عند إنشاء المستخدم للمكتبة (لا يمكن استبداله لاحقًا)؛ فهو ينظم خرائط المعاملات الموقعة مسبقًا، ويرفع توقيعات PegIn، ويولّد إثباتات الاسترداد، ويدفع عملية Claim. لكنه لا يستطيع في الوقت نفسه إضافة مسار جديد مؤقت لنقل BTC؛ وإذا انقطع عن الشبكة، ما يزال بإمكان المستخدم إجراء Claim ذاتيًا بالاعتماد على WOTS وملفات artifacts الخاصة بـ claimer.
AVK هو مقعد التصفية داخل التطبيق. يشارك في توقيعات التقاطع عند إنشاء المكتبة. وفي تصفية Aave، لا يمكنه شراء Vault المُدار واسترداد BTC إلا إذا كان AVK قد تم إدخاله مسبقًا ضمن خريطة المعاملة. يمكنه سلوك مسار التصفية المحدد، لكنه لا يستطيع تغيير عنوان السحب العادي.
Universal Challenger مسؤول عن المراقبة اليقظة: يراقب عمليات Claim عبر التطبيقات، وإذا اكتشف أن الإثبات لا يتطابق مع حالة Ethereum، يقوم بالتحدي. هذه المجموعة مغلقة حاليًا ومُرقّمة بالإصدارات، وليست متاحة للجميع للانضمام؛ لكن المستخدم يحتفظ أيضًا بمسار التحدي، بحيث لا تكون السلامة رهينة بوجود أي مراقب بعينه متصلًا.
أما Security Council فهو الفرامل الحمراء. في شبكة الاختبار الحالية، يلزم توقيع 3/5؛ ويمكنه منع Payout عند فشل نظام الإثباتات بشكل كارثي، لكنه لا يستطيع تحديد عنوان استلام جديد: يمكنه جعل المال يتوقف مؤقتًا عن الحركة، لكنه لا يستطيع نقل المال بعيدًا.
أعتقد أن ذكاءه الحقيقي هو تفكيك «سوء الاستخدام» إلى سلسلة من الأجزاء التي لا يستطيع أي طرف تنفيذها منفردًا. ومع ذلك فهو ليس بلا صلاحيات تمامًا: لدى AVK والتحدّيين واللجنة آليات دخول. بعد إطلاق الشبكة الرئيسية، الأهم من عدد الأشخاص هو أن تكون الأدوار قادمة من منظمات مختلفة، وأن تكون مسارات الاستبدال عند الأعطال قادرة فعلًا على العمل.
هل تقلق أكثر من أن يقوم أحد الأدوار بسوء الاستخدام، أم أنك تخشى أن تفشل جميع الأدوار معًا في لحظة حرجة؟
#baby $BABY
يرى فريق VP كمشرف مشروع. يتم اختياره عند إنشاء المستخدم للمكتبة (لا يمكن استبداله لاحقًا)؛ فهو ينظم خرائط المعاملات الموقعة مسبقًا، ويرفع توقيعات PegIn، ويولّد إثباتات الاسترداد، ويدفع عملية Claim. لكنه لا يستطيع في الوقت نفسه إضافة مسار جديد مؤقت لنقل BTC؛ وإذا انقطع عن الشبكة، ما يزال بإمكان المستخدم إجراء Claim ذاتيًا بالاعتماد على WOTS وملفات artifacts الخاصة بـ claimer.
AVK هو مقعد التصفية داخل التطبيق. يشارك في توقيعات التقاطع عند إنشاء المكتبة. وفي تصفية Aave، لا يمكنه شراء Vault المُدار واسترداد BTC إلا إذا كان AVK قد تم إدخاله مسبقًا ضمن خريطة المعاملة. يمكنه سلوك مسار التصفية المحدد، لكنه لا يستطيع تغيير عنوان السحب العادي.
Universal Challenger مسؤول عن المراقبة اليقظة: يراقب عمليات Claim عبر التطبيقات، وإذا اكتشف أن الإثبات لا يتطابق مع حالة Ethereum، يقوم بالتحدي. هذه المجموعة مغلقة حاليًا ومُرقّمة بالإصدارات، وليست متاحة للجميع للانضمام؛ لكن المستخدم يحتفظ أيضًا بمسار التحدي، بحيث لا تكون السلامة رهينة بوجود أي مراقب بعينه متصلًا.
أما Security Council فهو الفرامل الحمراء. في شبكة الاختبار الحالية، يلزم توقيع 3/5؛ ويمكنه منع Payout عند فشل نظام الإثباتات بشكل كارثي، لكنه لا يستطيع تحديد عنوان استلام جديد: يمكنه جعل المال يتوقف مؤقتًا عن الحركة، لكنه لا يستطيع نقل المال بعيدًا.
أعتقد أن ذكاءه الحقيقي هو تفكيك «سوء الاستخدام» إلى سلسلة من الأجزاء التي لا يستطيع أي طرف تنفيذها منفردًا. ومع ذلك فهو ليس بلا صلاحيات تمامًا: لدى AVK والتحدّيين واللجنة آليات دخول. بعد إطلاق الشبكة الرئيسية، الأهم من عدد الأشخاص هو أن تكون الأدوار قادمة من منظمات مختلفة، وأن تكون مسارات الاستبدال عند الأعطال قادرة فعلًا على العمل.
هل تقلق أكثر من أن يقوم أحد الأدوار بسوء الاستخدام، أم أنك تخشى أن تفشل جميع الأدوار معًا في لحظة حرجة؟
#baby $BABY
