#bedrock $BR في الآونة الأخيرة تناولت أنا وصديق لي يعمل في مجال تدقيق الأمان طعامًا، وتحدثنا عن آلية التوقيع متعدد التواقيع (multi-sig) في بروتوكولات DeFi. قال لي جملةً واحدة، لا زلت أتذكرها. كثير من المشاريع تستخدم التوقيع متعدد التواقيع كديكور؛ فقد تكون الأشخاص الذين يوقّعون يعرفون بعضهم بعضًا في الخفاء، ومستوى تمركز “مركز القوة” الحقيقي قد يكون أعلى من وضع عدم التوقيع أصلًا.
بعد ذلك عدت إلى قراءة مستندات @Bedrock ، وركزت تحديدًا على تصميم الحوكمة والأمان.
في Bedrock 2.0، لا يسلكون في جزء التوقيع متعدد التواقيع مسار “المعرفة/الأصدقاء يوقّعون لأنفسهم”. العمليات الجوهرية، مثل ترقية العقد (contract upgrade)، والإيقاف الطارئ، وتعديل المعلمات، تتطلب توقيعًا مشتركًا من عدة أطراف مستقلة كي يمكن تنفيذها. ليست تشكيلة جهات التوقيع شيئًا يقرره فريق Bedrock وحده، بل تشمل جهات خارجية وشركاء. ورغم أنه ليس لا مركزيًا بالكامل حتى الآن، إلا أنهم على الأقل وزّعوا السلطة بين كيانات مختلفة، لتجنب سيطرة جهة واحدة على كل شيء.
ثم ننظر إلى تصميم veBR. يقوم المستخدمون بقفل BR للحصول على حق التصويت، ما يمكنهم من تحديد أي مسابح/برك إيداع ستحصل على حوافز أكبر، وأي معلمات تحتاج إلى تعديل. هذه الآلية ما زالت في مراحلها الأولى، ومعدل المشاركة في التصويت غير مرتفع—وهو التحدي الذي تواجهه كل رموز الحوكمة تقريبًا. لكن على الأقل قام Bedrock ببناء إطار للحوكمة، ومسار انتقال السلطة واضح. أما بعض المشاريع الأخرى، فلا شيء يفضح ذلك مثل أن الأبيض (الورقة البيضاء) يكتب مقاطع طويلة عن طموحات الحوكمة، لكن عند التنفيذ تظل صفحة عنوان محفظة فريق المشروع وحدها قادرة على تقرير كل شيء. $ETH
لاحظت أيضًا تفصيلًا: في جانب “إثباتات الاحتياطي/التمويل على السلسلة” (on-chain proof of reserves)، يستخدم Bedrock PoR من Chainlink. هذا التصميم ليس فقط للتباهي، بل ليتمكن أي شخص من التحقق في أي وقت من أن الأصول الأساسية لـ uniBTC و brBTC كافية. فإذا اختفى فريق Bedrock يومًا ما، يمكن للمستخدمين ما زالوا التأكد عبر بيانات السلسلة من أن الشهادات/الاستحقاقات التي لديهم تقابل أصولًا فعلية. إن تصميم “مقاومة نقطة الفشل الواحدة” هو ما يجعل البروتوكول يتحرك فعلًا نحو نظام لا يحتاج إلى الثقة.
$BTC
من قبل تضررت في بروتوكولات أخرى؛ إذ قبل أن يهرب فريق المشروع، قاموا بتجميع صلاحيات التوقيع متعدد التواقيع بالكامل في أيديهم، ثم نقلوا أصول المستخدمين بين ليلة وضحاها. بعد ذلك، عندما أنظر إلى أي بروتوكول DeFi، ليست أول خطوة هي النظر إلى APY، بل إلى هيكل الصلاحيات: المال موجود لدى من؟ ومن يملك إمكانية تحريك تلك الأموال؟ وعند تحريكها، كم عدد الأشخاص الذين يجب أن يوافقوا.
بعد ذلك عدت إلى قراءة مستندات @Bedrock ، وركزت تحديدًا على تصميم الحوكمة والأمان.
في Bedrock 2.0، لا يسلكون في جزء التوقيع متعدد التواقيع مسار “المعرفة/الأصدقاء يوقّعون لأنفسهم”. العمليات الجوهرية، مثل ترقية العقد (contract upgrade)، والإيقاف الطارئ، وتعديل المعلمات، تتطلب توقيعًا مشتركًا من عدة أطراف مستقلة كي يمكن تنفيذها. ليست تشكيلة جهات التوقيع شيئًا يقرره فريق Bedrock وحده، بل تشمل جهات خارجية وشركاء. ورغم أنه ليس لا مركزيًا بالكامل حتى الآن، إلا أنهم على الأقل وزّعوا السلطة بين كيانات مختلفة، لتجنب سيطرة جهة واحدة على كل شيء.
ثم ننظر إلى تصميم veBR. يقوم المستخدمون بقفل BR للحصول على حق التصويت، ما يمكنهم من تحديد أي مسابح/برك إيداع ستحصل على حوافز أكبر، وأي معلمات تحتاج إلى تعديل. هذه الآلية ما زالت في مراحلها الأولى، ومعدل المشاركة في التصويت غير مرتفع—وهو التحدي الذي تواجهه كل رموز الحوكمة تقريبًا. لكن على الأقل قام Bedrock ببناء إطار للحوكمة، ومسار انتقال السلطة واضح. أما بعض المشاريع الأخرى، فلا شيء يفضح ذلك مثل أن الأبيض (الورقة البيضاء) يكتب مقاطع طويلة عن طموحات الحوكمة، لكن عند التنفيذ تظل صفحة عنوان محفظة فريق المشروع وحدها قادرة على تقرير كل شيء. $ETH
لاحظت أيضًا تفصيلًا: في جانب “إثباتات الاحتياطي/التمويل على السلسلة” (on-chain proof of reserves)، يستخدم Bedrock PoR من Chainlink. هذا التصميم ليس فقط للتباهي، بل ليتمكن أي شخص من التحقق في أي وقت من أن الأصول الأساسية لـ uniBTC و brBTC كافية. فإذا اختفى فريق Bedrock يومًا ما، يمكن للمستخدمين ما زالوا التأكد عبر بيانات السلسلة من أن الشهادات/الاستحقاقات التي لديهم تقابل أصولًا فعلية. إن تصميم “مقاومة نقطة الفشل الواحدة” هو ما يجعل البروتوكول يتحرك فعلًا نحو نظام لا يحتاج إلى الثقة.
$BTC
من قبل تضررت في بروتوكولات أخرى؛ إذ قبل أن يهرب فريق المشروع، قاموا بتجميع صلاحيات التوقيع متعدد التواقيع بالكامل في أيديهم، ثم نقلوا أصول المستخدمين بين ليلة وضحاها. بعد ذلك، عندما أنظر إلى أي بروتوكول DeFi، ليست أول خطوة هي النظر إلى APY، بل إلى هيكل الصلاحيات: المال موجود لدى من؟ ومن يملك إمكانية تحريك تلك الأموال؟ وعند تحريكها، كم عدد الأشخاص الذين يجب أن يوافقوا.