تعد عقود الوكيل أداة مهمة لمطوري العقود الأذكياء. اليوم ، هناك العديد من أوضاع الوكيل وقواعد الاستخدام المقابلة في نظام العقد. لقد أوضحنا سابقًا أفضل ممارسات أمان عقد الوكيل القابل للترقية.
في هذه المقالة ، سوف نقدم نموذج وكيل آخر شائع في مجتمع المطورين ، نموذج الوكيل الماسي.
عقود الوكيل الماسية ، والمعروفة أيضًا باسم "الماس" ، هي نمط تصميم لعقود Ethereum الذكية التي قدمها Ethereum Improvement Proposal (EIP) 2535.
يسمح الوضع الماسي للعقد بأن يكون له وظائف غير محدودة عن طريق تقسيم وظائفه إلى عقود أصغر (تسمى أيضًا "الجوانب"). يعمل Diamond كوكيل ، حيث يقوم بتوجيه استدعاءات الوظيفة إلى الجانب المناسب.
يمكن أن يحل تصميم النموذج الماسي مشكلة الحد الأقصى لحجم العقد لشبكة Ethereum. من خلال تقسيم عقد كبير إلى جوانب أصغر ، يسمح نمط الماس للمطورين ببناء عقود ذكية أكثر تعقيدًا وغنية بالميزات دون التأثر بقيود الحجم.
تقدم شركة Diamond Brokerage مرونة هائلة مقارنة بالعقود التقليدية القابلة للترقية. إنها تسمح بترقية أجزاء العقد أو إضافتها أو استبدالها أو إزالتها دون لمس الأجزاء الأخرى.
تقدم هذه المقالة نظرة عامة على EIP-2535 ، بما في ذلك مقارنة مع وضع الوكيل الشفاف المستخدم على نطاق واسع ووضع وكيل UUPS ، واعتبارات الأمان الخاصة به لمجتمع المطورين.
في سياق EIP-2535 ، "الماس" هو عقد توكيل يتم توفير تنفيذه الوظيفي من خلال عقود منطقية مختلفة ، تسمى "الجوانب".
تخيل أن الماس الحقيقي له جوانب مختلفة ، تسمى أوجه ، وأن عقود الألماس الخاصة بإيثريوم لها أيضًا جوانب مختلفة. كل عقد لوظيفة استعارة الماس هو جانب أو وجه مختلف.
يستخدم المعيار الماسي تشبيهًا لتوسيع إمكانيات "القطع الماسي" لإضافة أو استبدال أو حذف الأوجه والميزات.
بالإضافة إلى ذلك ، توفر Diamond Standard ميزة تسمى "العدسة الماسية" التي تعرض معلومات حول أوجه ووجود الماس.
بالمقارنة مع نموذج الوكيل التقليدي ، فإن "الماس" يعادل عقد التوكيل ، وتتوافق "الجوانب" المختلفة مع تحقيق العقد. يمكن للجوانب المختلفة لعامل الماس مشاركة الوظائف الداخلية والمكتبات ومتغيرات الحالة. المكونات الرئيسية للماس هي كما يلي:
عقد مركزي يعمل كوكيل ، يستدعي وظيفة التوجيه إلى الجانب المناسب. يحتوي على تعيين محددات الوظائف لعناوين "الجانب".
عقد منفرد ينفذ وظيفة محددة. يحتوي كل وجه على مجموعة من الوظائف التي يمكن أن يستدعيها الماس.
عبارة عن مجموعة من الوظائف القياسية المحددة في EIP-2535 التي توفر معلومات حول محددات الوجه والوظائف المستخدمة في الماس. يسمح Diamond Loupe للمطورين والمستخدمين بفحص وفهم بنية الماس.
وظائف لإضافة أو استبدال أو إزالة الأوجه في الماس ومحددات الميزات المقابلة لها. يمكن فقط للعناوين المصرح بها (على سبيل المثال ، مالك الماس أو عقد متعدد التوقيعات) القيام بقطع الماس.
على غرار الوكلاء التقليديين ، عند إجراء استدعاء دالة على عامل الماس ، يتم تشغيل وظيفة الرجوع للوكيل (وظيفة الرجوع). يتمثل الاختلاف الرئيسي عن وكيل الماس في أنه في الوظيفة الاحتياطية ، يوجد تعيين selectorToFacet ، والذي يخزن ويحدد عنوان العقد المنطقي الذي يقوم بتنفيذ الوظيفة المطلوبة. ثم يستخدم استدعاء مفوض لتنفيذ الوظيفة ، تمامًا مثل الوكيل التقليدي.
تستخدم جميع الخوادم الوكيلة الوظيفة الاحتياطية () لتفويض استدعاءات الوظائف إلى العناوين الخارجية. يوجد أدناه تنفيذ الوكيل الماسي وتنفيذ التوكيل التقليدي.
من الجدير بالذكر أن كتل كود التجميع الخاصة بهم متشابهة جدًا ، لذا فإن الاختلاف الوحيد هو عنوان الجانب في مكالمة مندوب الوكيل الماسي والعنوان الضمني في مكالمة مندوب الوكيل التقليدية.
يتمثل الاختلاف الرئيسي في أنه في الوكيل الماسي ، يتم تحديد عنوان الجانب من خلال علامة التجزئة من msg.sig الخاص بالمتصل (محدد الوظيفة) إلى عنوان الجانب ، بينما في الوكيل التقليدي ، لا يعتمد عنوان الضم على دخول المتصل.
وظيفة وكيل الماس الاحتياطية
الوظيفة التقليدية للوكيل الاحتياطي
يحدد مخطط SelectorToFacet العقد الذي يحتوي على تنفيذ كل محدد وظيفة. غالبًا ما يحتاج عمال المشروع إلى إضافة أو استبدال أو إزالة تعيين عقد الوظيفة المحدد إلى التنفيذ. تنص EIP-2535 على ما يلي: لتحقيق هذا الغرض ، يجب أن تكون هناك دالة diamondCut (). يوجد أدناه مثال للواجهة.
تحتوي كل بنية FacetCut على عنوان واجهة وصفيف محدد للميزات مكون من أربعة بايت ليتم تحديثه في عقد الوكيل الماسي. يسمح FaceCutAction لأحد بإضافة محددات الميزات واستبدالها وإزالتها. يجب أن يتضمن تنفيذ وظيفة diamondCut () تحكمًا كافيًا في الوصول ، ومنع تصادم الفتحات ، والتعافي عند الفشل ، وما إلى ذلك.
من أجل الاستعلام عن الوظائف والأوجه التي يمتلكها عامل الماس ، نستخدم "العدسة المكبرة الماسية". "العدسة الماسية" هي سمة خاصة تنفذ الواجهة التالية المحددة في EIP-2535:
يجب أن تُرجع الدالة facets () عناوين جميع الأوجه ومحددات وظائفها المكونة من أربعة بايت. يجب أن تُرجع الدالة facetFunctionSelectors () جميع محددات الوظائف التي يدعمها جانب معين. يجب أن تُرجع الدالة facetAddresses () كافة عناوين الواجهات المستخدمة بواسطة الماس.
يجب أن تُرجع الدالة facetAddress () جانبًا يدعم المحدد المحدد أو العنوان (0) إذا لم يتم العثور عليه. لاحظ أنه يجب ألا يكون هناك أكثر من عنوان واحد بجانب محدد الميزة نفسه.
نظرًا لأن وكلاء الماس يفوضون استدعاءات وظيفية مختلفة لعقود تنفيذ مختلفة ، فمن الأهمية بمكان إدارة فتحات التخزين بشكل صحيح لمنع التعارضات. يذكر EIP-2535 عدة طرق لإدارة فتحات التخزين.
يمكن لهذا الجانب أن يعلن عن متغيرات الحالة في الهيكل. يمكن لهذا الجانب استخدام أي عدد من الهياكل ، ولكل منها موقع تخزين مختلف. كل هيكل له مكان محدد في تخزين العقد. يمكن للجوانب أن تعلن عن متغيرات الحالة الخاصة بها ، لكنها لا يمكن أن تتعارض مع مواقع تخزين متغيرات الحالة المعلنة بواسطة جوانب أخرى. يتم توفير عينة مكتبة وعقد تخزين الماس في EIP-2535 ، كما هو موضح في الشكل التالي:
تخزين التطبيقات هو إصدار أكثر تخصصًا من التخزين الماسي. يستخدم هذا النمط لمشاركة متغيرات الحالة للجوانب بشكل أكثر ملاءمة وسهولة. يتم تعريف بنية متجر التطبيقات لاحتواء أي عدد ونوع من متغيرات الحالة التي يتطلبها التطبيق. يعلن جانب دائمًا عن بنية AppStorage كمتغير الحالة الأول والوحيد ، في الموضع 0 من فتحة التخزين. ثم يمكن للجوانب المختلفة الوصول إلى المتغيرات من هذا الهيكل.
هناك أيضًا استراتيجيات أخرى لإدارة فتحات التخزين ، بما في ذلك مزيج من Diamond Storage و AppStorage. على سبيل المثال ، يتم مشاركة بعض الهياكل بين جوانب مختلفة ، وبعضها خاص بجانب معين. في جميع الحالات ، من المهم جدًا منع الاصطدامات العرضية للفتحات.
** مقارنة مع وكيل شفاف وبروكسي UUPS **
إن وضعي الوكيل الرئيسيين اللذين يستخدمهما مجتمع مطوري Web3 حاليًا هما وضع الوكيل الشفاف ووضع وكيل UUPS. في هذا القسم ، نقارن بإيجاز وضع الوكيل الماسي مع أوضاع الوكيل الشفاف ووكيل UUPS.
** 1.EPI-2535: **
** 2. ** EPI-1967: ****
** 3-تنفيذ مرجع الوكيل الماسي: **
** 4.تنفيذ OpenZeppelin: **
تعد الحلول الوكيلة والقابلة للتطوير أنظمة أكثر تعقيدًا ، ويوفر OpenZeppelin قواعد تعليمات برمجية ووثائق شاملة لوكلاء UUPS وشفافة ومنارة قابلة للتطوير. ومع ذلك ، بالنسبة لوضع الوكيل الماسي ، على الرغم من أن OpenZeppelin أكد فوائده ، إلا أنهم قرروا عدم تضمين تطبيق الماس EIP-2535 في مكتبتهم.
لذلك ، يجب على المطورين الذين يستخدمون مكتبات جهات خارجية موجودة أو ينفذون هذا الحل بأنفسهم تنفيذه بحذر شديد. هنا قمنا بتجميع قائمة تحقق بأفضل ممارسات الأمان لمجتمع المطورين للنظر فيها.
من خلال تقسيم منطق العقد إلى وحدات أصغر وأكثر قابلية للإدارة ، يمكن للمطورين اختبار ومراجعة التعليمات البرمجية الخاصة بهم بسهولة أكبر.
بالإضافة إلى ذلك ، يسمح هذا النهج للمطورين بالتركيز على جوانب محددة لبناء العقود والحفاظ عليها ، بدلاً من إدارة قاعدة رموز معقدة ومتجانسة. والنتيجة النهائية هي قاعدة رمز معيارية أكثر مرونة يمكن تحديثها وتعديلها بسهولة دون التأثير على أجزاء أخرى من العقد.
المصدر: Aavegotchi Github
عند نشر عقد الوكيل الماسي ، يجب إضافة عنوان عقد DiamondCutFacet إلى عقد الوكيل الماسي وتنفيذ وظيفة diamondCut (). تُستخدم الدالة DiamondCut () لإضافة أو حذف أو استبدال الأوجه والوظائف ، بدون DiamondCutFacet و DiamondCut () ، لا يمكن لعامل الماس أن يعمل بشكل صحيح.
المصدر: Mugen's Diamond-3-Hardhat
عند إضافة متغير حالة جديد إلى بنية تخزين في عقد ذكي ، يجب إضافته في نهاية الهيكل. ستؤدي إضافة متغير حالة جديد في بداية البنية أو في منتصفها إلى قيام متغير الحالة الجديد بالكتابة فوق بيانات متغير الحالة الحالية ، وقد يشير أي متغير حالة بعد متغير الحالة الجديد إلى موقع ذاكرة خاطئ.
يتطلب نمط AppStorage أن يتم التصريح عن بنية واحدة فقط للوكيل الماسي ، وأن يتم مشاركة هذه البنية من قبل جميع الجوانب. إذا كانت الهياكل المتعددة مطلوبة ، فيجب استخدام نمط DiamondStorage.
لا تضع بنية مباشرة داخل بنية أخرى إلا إذا كنت متأكدًا من أنك لا تنوي إضافة المزيد من متغيرات الحالة إلى البنية الداخلية. لا يمكن إضافة متغيرات حالة جديدة إلى الهياكل الداخلية في الترقية دون استبدال فتحات التخزين المتغيرة المعلنة بعد البنية.
يتمثل الحل البديل في إضافة متغيرات حالة جديدة إلى البنية المعينة للذاكرة بدلاً من وضع "الهيكل" مباشرةً في "البنية". يتم حساب فتحات التخزين المتغيرة في الخريطة بشكل مختلف وليست متجاورة في التخزين.
سيتأثر حجم المصفوفة بحجم الهيكل. عند إضافة متغير حالة جديد إلى بنية ، فإنه يغير حجم وتخطيط ذلك الهيكل.
يمكن أن يسبب هذا مشاكل إذا تم استخدام البنية كعنصر في مصفوفة. إذا تغير حجم الهيكل وتخطيطه ، فإن حجم وتخطيط المصفوفة سيتغيران أيضًا ، مما قد يتسبب في مشاكل في الفهرسة أو العمليات الأخرى التي تعتمد على حجم وتخطيط متسقين للهيكل.
على غرار أنماط الوكيل الأخرى ، يجب أن يكون لكل متغير فتحة تخزين فريدة. خلاف ذلك ، فإن هيكلين مختلفين في نفس الموقع سيحلان محل بعضهما البعض.
تُستخدم وظيفة التهيئة () عادةً لتعيين المتغيرات المهمة ، مثل عناوين الأدوار ذات الامتيازات. إذا لم تتم تهيئته عند نشر العقد ، فيمكن للممثل الضار الاتصال بالعقد والتحكم فيه.
يوصى بإضافة التحكم المناسب في الوصول إلى وظيفة التهيئة / الإعداد ، أو التأكد من استدعاء الوظيفة عند نشر العقد ولا يمكن استدعاؤها مرة أخرى.
إذا كان أي جانب من جوانب العقد قادرًا على استدعاء وظيفة التدمير الذاتي () ، فمن المحتمل أن يؤدي إلى تدمير العقد بالكامل ، مما يؤدي إلى فقدان الأموال أو البيانات. هذا أمر خطير للغاية في وضع الوكيل الماسي ، حيث يمكن للجوانب المتعددة الوصول إلى التخزين وبيانات عقد الوكيل.
حاليًا ، نرى المزيد والمزيد من المشاريع التي تتبنى نموذج وكيل الماس في عقودها الذكية. يوفر المرونة والمزايا الأخرى على البروكسيات التقليدية.
ومع ذلك ، يمكن أن تعني المرونة الإضافية أيضًا مساحة هجوم أوسع للمهاجمين. نأمل أن تساعد هذه المقالة مجتمع المطورين على فهم آليات نموذج الوكيل الماسي واعتبارات الأمان الخاصة به.
وفي الوقت نفسه ، ينبغي لفريق المشروع إجراء اختبارات صارمة وعمليات تدقيق من طرف ثالث للحد من مخاطر التعرض لمواطن الضعف المتعلقة بتنفيذ عقود وكالات الماس.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
أفضل الممارسات الأمنية لعقود وكالة الماس
تعد عقود الوكيل أداة مهمة لمطوري العقود الأذكياء. اليوم ، هناك العديد من أوضاع الوكيل وقواعد الاستخدام المقابلة في نظام العقد. لقد أوضحنا سابقًا أفضل ممارسات أمان عقد الوكيل القابل للترقية.
في هذه المقالة ، سوف نقدم نموذج وكيل آخر شائع في مجتمع المطورين ، نموذج الوكيل الماسي.
عقود الوكيل الماسية ، والمعروفة أيضًا باسم "الماس" ، هي نمط تصميم لعقود Ethereum الذكية التي قدمها Ethereum Improvement Proposal (EIP) 2535.
يسمح الوضع الماسي للعقد بأن يكون له وظائف غير محدودة عن طريق تقسيم وظائفه إلى عقود أصغر (تسمى أيضًا "الجوانب"). يعمل Diamond كوكيل ، حيث يقوم بتوجيه استدعاءات الوظيفة إلى الجانب المناسب.
يمكن أن يحل تصميم النموذج الماسي مشكلة الحد الأقصى لحجم العقد لشبكة Ethereum. من خلال تقسيم عقد كبير إلى جوانب أصغر ، يسمح نمط الماس للمطورين ببناء عقود ذكية أكثر تعقيدًا وغنية بالميزات دون التأثر بقيود الحجم.
تقدم شركة Diamond Brokerage مرونة هائلة مقارنة بالعقود التقليدية القابلة للترقية. إنها تسمح بترقية أجزاء العقد أو إضافتها أو استبدالها أو إزالتها دون لمس الأجزاء الأخرى.
تقدم هذه المقالة نظرة عامة على EIP-2535 ، بما في ذلك مقارنة مع وضع الوكيل الشفاف المستخدم على نطاق واسع ووضع وكيل UUPS ، واعتبارات الأمان الخاصة به لمجتمع المطورين.
في سياق EIP-2535 ، "الماس" هو عقد توكيل يتم توفير تنفيذه الوظيفي من خلال عقود منطقية مختلفة ، تسمى "الجوانب".
تخيل أن الماس الحقيقي له جوانب مختلفة ، تسمى أوجه ، وأن عقود الألماس الخاصة بإيثريوم لها أيضًا جوانب مختلفة. كل عقد لوظيفة استعارة الماس هو جانب أو وجه مختلف.
يستخدم المعيار الماسي تشبيهًا لتوسيع إمكانيات "القطع الماسي" لإضافة أو استبدال أو حذف الأوجه والميزات.
بالإضافة إلى ذلك ، توفر Diamond Standard ميزة تسمى "العدسة الماسية" التي تعرض معلومات حول أوجه ووجود الماس.
بالمقارنة مع نموذج الوكيل التقليدي ، فإن "الماس" يعادل عقد التوكيل ، وتتوافق "الجوانب" المختلفة مع تحقيق العقد. يمكن للجوانب المختلفة لعامل الماس مشاركة الوظائف الداخلية والمكتبات ومتغيرات الحالة. المكونات الرئيسية للماس هي كما يلي:
عقد مركزي يعمل كوكيل ، يستدعي وظيفة التوجيه إلى الجانب المناسب. يحتوي على تعيين محددات الوظائف لعناوين "الجانب".
عقد منفرد ينفذ وظيفة محددة. يحتوي كل وجه على مجموعة من الوظائف التي يمكن أن يستدعيها الماس.
عبارة عن مجموعة من الوظائف القياسية المحددة في EIP-2535 التي توفر معلومات حول محددات الوجه والوظائف المستخدمة في الماس. يسمح Diamond Loupe للمطورين والمستخدمين بفحص وفهم بنية الماس.
وظائف لإضافة أو استبدال أو إزالة الأوجه في الماس ومحددات الميزات المقابلة لها. يمكن فقط للعناوين المصرح بها (على سبيل المثال ، مالك الماس أو عقد متعدد التوقيعات) القيام بقطع الماس.
على غرار الوكلاء التقليديين ، عند إجراء استدعاء دالة على عامل الماس ، يتم تشغيل وظيفة الرجوع للوكيل (وظيفة الرجوع). يتمثل الاختلاف الرئيسي عن وكيل الماس في أنه في الوظيفة الاحتياطية ، يوجد تعيين selectorToFacet ، والذي يخزن ويحدد عنوان العقد المنطقي الذي يقوم بتنفيذ الوظيفة المطلوبة. ثم يستخدم استدعاء مفوض لتنفيذ الوظيفة ، تمامًا مثل الوكيل التقليدي.
تستخدم جميع الخوادم الوكيلة الوظيفة الاحتياطية () لتفويض استدعاءات الوظائف إلى العناوين الخارجية. يوجد أدناه تنفيذ الوكيل الماسي وتنفيذ التوكيل التقليدي.
من الجدير بالذكر أن كتل كود التجميع الخاصة بهم متشابهة جدًا ، لذا فإن الاختلاف الوحيد هو عنوان الجانب في مكالمة مندوب الوكيل الماسي والعنوان الضمني في مكالمة مندوب الوكيل التقليدية.
يتمثل الاختلاف الرئيسي في أنه في الوكيل الماسي ، يتم تحديد عنوان الجانب من خلال علامة التجزئة من msg.sig الخاص بالمتصل (محدد الوظيفة) إلى عنوان الجانب ، بينما في الوكيل التقليدي ، لا يعتمد عنوان الضم على دخول المتصل.
وظيفة وكيل الماس الاحتياطية
الوظيفة التقليدية للوكيل الاحتياطي
يحدد مخطط SelectorToFacet العقد الذي يحتوي على تنفيذ كل محدد وظيفة. غالبًا ما يحتاج عمال المشروع إلى إضافة أو استبدال أو إزالة تعيين عقد الوظيفة المحدد إلى التنفيذ. تنص EIP-2535 على ما يلي: لتحقيق هذا الغرض ، يجب أن تكون هناك دالة diamondCut (). يوجد أدناه مثال للواجهة.
تحتوي كل بنية FacetCut على عنوان واجهة وصفيف محدد للميزات مكون من أربعة بايت ليتم تحديثه في عقد الوكيل الماسي. يسمح FaceCutAction لأحد بإضافة محددات الميزات واستبدالها وإزالتها. يجب أن يتضمن تنفيذ وظيفة diamondCut () تحكمًا كافيًا في الوصول ، ومنع تصادم الفتحات ، والتعافي عند الفشل ، وما إلى ذلك.
من أجل الاستعلام عن الوظائف والأوجه التي يمتلكها عامل الماس ، نستخدم "العدسة المكبرة الماسية". "العدسة الماسية" هي سمة خاصة تنفذ الواجهة التالية المحددة في EIP-2535:
يجب أن تُرجع الدالة facets () عناوين جميع الأوجه ومحددات وظائفها المكونة من أربعة بايت. يجب أن تُرجع الدالة facetFunctionSelectors () جميع محددات الوظائف التي يدعمها جانب معين. يجب أن تُرجع الدالة facetAddresses () كافة عناوين الواجهات المستخدمة بواسطة الماس.
يجب أن تُرجع الدالة facetAddress () جانبًا يدعم المحدد المحدد أو العنوان (0) إذا لم يتم العثور عليه. لاحظ أنه يجب ألا يكون هناك أكثر من عنوان واحد بجانب محدد الميزة نفسه.
نظرًا لأن وكلاء الماس يفوضون استدعاءات وظيفية مختلفة لعقود تنفيذ مختلفة ، فمن الأهمية بمكان إدارة فتحات التخزين بشكل صحيح لمنع التعارضات. يذكر EIP-2535 عدة طرق لإدارة فتحات التخزين.
يمكن لهذا الجانب أن يعلن عن متغيرات الحالة في الهيكل. يمكن لهذا الجانب استخدام أي عدد من الهياكل ، ولكل منها موقع تخزين مختلف. كل هيكل له مكان محدد في تخزين العقد. يمكن للجوانب أن تعلن عن متغيرات الحالة الخاصة بها ، لكنها لا يمكن أن تتعارض مع مواقع تخزين متغيرات الحالة المعلنة بواسطة جوانب أخرى. يتم توفير عينة مكتبة وعقد تخزين الماس في EIP-2535 ، كما هو موضح في الشكل التالي:
تخزين التطبيقات هو إصدار أكثر تخصصًا من التخزين الماسي. يستخدم هذا النمط لمشاركة متغيرات الحالة للجوانب بشكل أكثر ملاءمة وسهولة. يتم تعريف بنية متجر التطبيقات لاحتواء أي عدد ونوع من متغيرات الحالة التي يتطلبها التطبيق. يعلن جانب دائمًا عن بنية AppStorage كمتغير الحالة الأول والوحيد ، في الموضع 0 من فتحة التخزين. ثم يمكن للجوانب المختلفة الوصول إلى المتغيرات من هذا الهيكل.
هناك أيضًا استراتيجيات أخرى لإدارة فتحات التخزين ، بما في ذلك مزيج من Diamond Storage و AppStorage. على سبيل المثال ، يتم مشاركة بعض الهياكل بين جوانب مختلفة ، وبعضها خاص بجانب معين. في جميع الحالات ، من المهم جدًا منع الاصطدامات العرضية للفتحات.
** مقارنة مع وكيل شفاف وبروكسي UUPS **
إن وضعي الوكيل الرئيسيين اللذين يستخدمهما مجتمع مطوري Web3 حاليًا هما وضع الوكيل الشفاف ووضع وكيل UUPS. في هذا القسم ، نقارن بإيجاز وضع الوكيل الماسي مع أوضاع الوكيل الشفاف ووكيل UUPS.
** 1.EPI-2535: **
** 2. ** EPI-1967: ****
** 3-تنفيذ مرجع الوكيل الماسي: **
** 4.تنفيذ OpenZeppelin: **
تعد الحلول الوكيلة والقابلة للتطوير أنظمة أكثر تعقيدًا ، ويوفر OpenZeppelin قواعد تعليمات برمجية ووثائق شاملة لوكلاء UUPS وشفافة ومنارة قابلة للتطوير. ومع ذلك ، بالنسبة لوضع الوكيل الماسي ، على الرغم من أن OpenZeppelin أكد فوائده ، إلا أنهم قرروا عدم تضمين تطبيق الماس EIP-2535 في مكتبتهم.
لذلك ، يجب على المطورين الذين يستخدمون مكتبات جهات خارجية موجودة أو ينفذون هذا الحل بأنفسهم تنفيذه بحذر شديد. هنا قمنا بتجميع قائمة تحقق بأفضل ممارسات الأمان لمجتمع المطورين للنظر فيها.
من خلال تقسيم منطق العقد إلى وحدات أصغر وأكثر قابلية للإدارة ، يمكن للمطورين اختبار ومراجعة التعليمات البرمجية الخاصة بهم بسهولة أكبر.
بالإضافة إلى ذلك ، يسمح هذا النهج للمطورين بالتركيز على جوانب محددة لبناء العقود والحفاظ عليها ، بدلاً من إدارة قاعدة رموز معقدة ومتجانسة. والنتيجة النهائية هي قاعدة رمز معيارية أكثر مرونة يمكن تحديثها وتعديلها بسهولة دون التأثير على أجزاء أخرى من العقد.
المصدر: Aavegotchi Github
عند نشر عقد الوكيل الماسي ، يجب إضافة عنوان عقد DiamondCutFacet إلى عقد الوكيل الماسي وتنفيذ وظيفة diamondCut (). تُستخدم الدالة DiamondCut () لإضافة أو حذف أو استبدال الأوجه والوظائف ، بدون DiamondCutFacet و DiamondCut () ، لا يمكن لعامل الماس أن يعمل بشكل صحيح.
المصدر: Mugen's Diamond-3-Hardhat
عند إضافة متغير حالة جديد إلى بنية تخزين في عقد ذكي ، يجب إضافته في نهاية الهيكل. ستؤدي إضافة متغير حالة جديد في بداية البنية أو في منتصفها إلى قيام متغير الحالة الجديد بالكتابة فوق بيانات متغير الحالة الحالية ، وقد يشير أي متغير حالة بعد متغير الحالة الجديد إلى موقع ذاكرة خاطئ.
يتطلب نمط AppStorage أن يتم التصريح عن بنية واحدة فقط للوكيل الماسي ، وأن يتم مشاركة هذه البنية من قبل جميع الجوانب. إذا كانت الهياكل المتعددة مطلوبة ، فيجب استخدام نمط DiamondStorage.
لا تضع بنية مباشرة داخل بنية أخرى إلا إذا كنت متأكدًا من أنك لا تنوي إضافة المزيد من متغيرات الحالة إلى البنية الداخلية. لا يمكن إضافة متغيرات حالة جديدة إلى الهياكل الداخلية في الترقية دون استبدال فتحات التخزين المتغيرة المعلنة بعد البنية.
يتمثل الحل البديل في إضافة متغيرات حالة جديدة إلى البنية المعينة للذاكرة بدلاً من وضع "الهيكل" مباشرةً في "البنية". يتم حساب فتحات التخزين المتغيرة في الخريطة بشكل مختلف وليست متجاورة في التخزين.
سيتأثر حجم المصفوفة بحجم الهيكل. عند إضافة متغير حالة جديد إلى بنية ، فإنه يغير حجم وتخطيط ذلك الهيكل.
يمكن أن يسبب هذا مشاكل إذا تم استخدام البنية كعنصر في مصفوفة. إذا تغير حجم الهيكل وتخطيطه ، فإن حجم وتخطيط المصفوفة سيتغيران أيضًا ، مما قد يتسبب في مشاكل في الفهرسة أو العمليات الأخرى التي تعتمد على حجم وتخطيط متسقين للهيكل.
على غرار أنماط الوكيل الأخرى ، يجب أن يكون لكل متغير فتحة تخزين فريدة. خلاف ذلك ، فإن هيكلين مختلفين في نفس الموقع سيحلان محل بعضهما البعض.
تُستخدم وظيفة التهيئة () عادةً لتعيين المتغيرات المهمة ، مثل عناوين الأدوار ذات الامتيازات. إذا لم تتم تهيئته عند نشر العقد ، فيمكن للممثل الضار الاتصال بالعقد والتحكم فيه.
يوصى بإضافة التحكم المناسب في الوصول إلى وظيفة التهيئة / الإعداد ، أو التأكد من استدعاء الوظيفة عند نشر العقد ولا يمكن استدعاؤها مرة أخرى.
إذا كان أي جانب من جوانب العقد قادرًا على استدعاء وظيفة التدمير الذاتي () ، فمن المحتمل أن يؤدي إلى تدمير العقد بالكامل ، مما يؤدي إلى فقدان الأموال أو البيانات. هذا أمر خطير للغاية في وضع الوكيل الماسي ، حيث يمكن للجوانب المتعددة الوصول إلى التخزين وبيانات عقد الوكيل.
حاليًا ، نرى المزيد والمزيد من المشاريع التي تتبنى نموذج وكيل الماس في عقودها الذكية. يوفر المرونة والمزايا الأخرى على البروكسيات التقليدية.
ومع ذلك ، يمكن أن تعني المرونة الإضافية أيضًا مساحة هجوم أوسع للمهاجمين. نأمل أن تساعد هذه المقالة مجتمع المطورين على فهم آليات نموذج الوكيل الماسي واعتبارات الأمان الخاصة به.
وفي الوقت نفسه ، ينبغي لفريق المشروع إجراء اختبارات صارمة وعمليات تدقيق من طرف ثالث للحد من مخاطر التعرض لمواطن الضعف المتعلقة بتنفيذ عقود وكالات الماس.