#bedrock $BR قبل فترة واجهتُ موقفًا مُحرجًا إلى حدّ ما. أعلن أحد بروتوكولات DeFi أنه يريد ترقية العقد، وأنه يجب على المستخدمين نقل السيولة يدويًا. اتبعتُ الإرشادات كما في الدليل، لكن حدثت مشكلة في خطوة منح الإذن؛ بعد أن أحرقتُ رسوم غاز (gas) دون قصد، فشلت عملية الترحيل. حاولتُ مرةً أخرى، لكنها فشلت أيضًا. في النهاية سألتُ في المجتمع (مجموعة/سيرفر) ووجدتُ أن الأمر ليس حالة فردية، بل مشكلة توافق مرتبطة بترقيات العقود. استغرقتُ أكثر من نصف ساعة حتى انتهيت من حلها، ومنذ ذلك الحين أصبحتُ أكثر حذرًا تجاه عبارة «ترقية البروتوكول».$ETH
ثم عندما قرأتُ وثائق @Bedrock ، بحثتُ تحديدًا في آلية ترقية العقود الخاصة بها.
ضمن بنية Bedrock 2.0، فإن منطق إصدار العقود الأساسية مثل uniBTC و brBTC ليس شيئًا يمكن تبديله بحرية. صلاحيات الترقية بيد جهة متعددة التواقيع (multisig)، وليست جهة تابعة لـ Bedrock نفسها. في كل مرة تُجرى ترقية، يجب أن يوقّع عليها عدة أطراف مستقلة معًا لتنفيذها. تَمنع هذه الآلية تمامًا مخاطر «سوء نية الفريق»؟ لا، لكن على الأقل ترفع العتبة. لا يكفي رأي شخص واحد؛ بل يجب أن يوافق عليها عدد من الأشخاص.
والأمر الذي جذب انتباهي أكثر هو أن Bedrock، عند موضوع الترقية، جعلت العديد من المعلمات قابلة للتكوين وليست قابلة للاستبدال. ماذا يعني ذلك؟ بعض البروتوكولات إذا أرادت تعديل معلمة معدل العائد (yield) فإنها تحتاج إلى استبدال العقد بالكامل، ما يرفع المخاطر ويجعل العملية أكثر تعقيدًا. في تصميمها منذ البداية، جعلت Bedrock المعلمات الشائعة مثل رسوم المعاملات وموزع الحوافز وأوزان المجمعات (pools) عناصر قابلة للتكوين، ويمكن تعديلها عبر تصويت الحوكمة دون الحاجة إلى لمس العقد الأساسي. بهذه الطريقة يتم ضمان المرونة وتقليل مساحة المخاطر الناتجة عن الترقيات.
قمتُ بتصفح تقارير التدقيق التاريخية لديها. خضعت العقود الأساسية في Bedrock لعمليات تدقيق متقاطعة من عدة شركات تدقيق، بما فيها SlowMist و CertiK. لا يمكن للتدقيق أن يضمن عدم وجود أي ثغرات بنسبة 100%، لكن تعدد جولات التدقيق على الأقل يشير إلى أن الفريق لا يستهين بالاستثمار في الأمان.$BTC
وهناك تفصيلة أخرى. آلية ترقية العقود في Bedrock تتضمن «قفلًا زمنيًا». أي ترقية ليست طارئة، عند تفعيلها، يكون هناك تأخير زمني قبل أن تصبح سارية. هذه الفترة تمنح المجتمع وقتًا للتفاعل. إذا كان هناك جدل حول مقترح ترقية ما، يمكن للمجتمع اكتشاف المشكلات خلال هذه الفترة وتقديم اعتراضات. هذا النوع من التصميم ليس نادرًا في مجال DeFi، لكن المشاريع التي تطبقه بتشدد فعليًا ليست كثيرة.
ثم عندما قرأتُ وثائق @Bedrock ، بحثتُ تحديدًا في آلية ترقية العقود الخاصة بها.
ضمن بنية Bedrock 2.0، فإن منطق إصدار العقود الأساسية مثل uniBTC و brBTC ليس شيئًا يمكن تبديله بحرية. صلاحيات الترقية بيد جهة متعددة التواقيع (multisig)، وليست جهة تابعة لـ Bedrock نفسها. في كل مرة تُجرى ترقية، يجب أن يوقّع عليها عدة أطراف مستقلة معًا لتنفيذها. تَمنع هذه الآلية تمامًا مخاطر «سوء نية الفريق»؟ لا، لكن على الأقل ترفع العتبة. لا يكفي رأي شخص واحد؛ بل يجب أن يوافق عليها عدد من الأشخاص.
والأمر الذي جذب انتباهي أكثر هو أن Bedrock، عند موضوع الترقية، جعلت العديد من المعلمات قابلة للتكوين وليست قابلة للاستبدال. ماذا يعني ذلك؟ بعض البروتوكولات إذا أرادت تعديل معلمة معدل العائد (yield) فإنها تحتاج إلى استبدال العقد بالكامل، ما يرفع المخاطر ويجعل العملية أكثر تعقيدًا. في تصميمها منذ البداية، جعلت Bedrock المعلمات الشائعة مثل رسوم المعاملات وموزع الحوافز وأوزان المجمعات (pools) عناصر قابلة للتكوين، ويمكن تعديلها عبر تصويت الحوكمة دون الحاجة إلى لمس العقد الأساسي. بهذه الطريقة يتم ضمان المرونة وتقليل مساحة المخاطر الناتجة عن الترقيات.
قمتُ بتصفح تقارير التدقيق التاريخية لديها. خضعت العقود الأساسية في Bedrock لعمليات تدقيق متقاطعة من عدة شركات تدقيق، بما فيها SlowMist و CertiK. لا يمكن للتدقيق أن يضمن عدم وجود أي ثغرات بنسبة 100%، لكن تعدد جولات التدقيق على الأقل يشير إلى أن الفريق لا يستهين بالاستثمار في الأمان.$BTC
وهناك تفصيلة أخرى. آلية ترقية العقود في Bedrock تتضمن «قفلًا زمنيًا». أي ترقية ليست طارئة، عند تفعيلها، يكون هناك تأخير زمني قبل أن تصبح سارية. هذه الفترة تمنح المجتمع وقتًا للتفاعل. إذا كان هناك جدل حول مقترح ترقية ما، يمكن للمجتمع اكتشاف المشكلات خلال هذه الفترة وتقديم اعتراضات. هذا النوع من التصميم ليس نادرًا في مجال DeFi، لكن المشاريع التي تطبقه بتشدد فعليًا ليست كثيرة.