الحاجة إلى السرعة!
الغرض من تطوير البرنامج هو جعلها تعمل على النحو المطلوب.
حيث انة يجب تكرار اختبارات متعددة لتحقيق ذلك، والوقت بين هذه الإختبارات له أهمية بالغة عند محاولة إكمال المهمة المطروحة في أسرع وقت ممكن.
في Origin، نستخدم اختبارات Unit وFork من أجل التطوير. يمكن أن يكون إجراء اختبارات Fork بطيئ للغاية، لكننا تمكنا من تقليل وقت تنفيذ اختبارات Frok (في بعض الحالات). من خلال هذه المقالة سأشرح كيف يمكنك تحسين سرعة اختبارات Fork، حتى تتمكن من إجراء التعليمات البرمجية الخاصة بك على النحو المطلوب في أي وقت من الأوقات.
اختبار Unit أو اختبار Fork؟
في العادة يعتمد ما إذا كنت تستخدم اختبار Fork أو اختبار Unit على بنية البروتوكول الذي يتم تطويره. تستخدم بعض الفرق اختبارات Unit فقط وبعض اختبارات Unit وFork. في Origin، تتفاعل عقودنا مع العديد من بروتوكولات الطرف الثالث (Curve، وUniswap، وBalancer، وConvex...) ويمكن أن تؤدي الأخطاء في التكامل إلى خسارة فادحة للأموال.
باستخدام اختبارات Unit، نسخر واجهة برمجة التطبيقات (API) لبروتوكول الطرف الثالث ونختبر مدى تكامل عقودنا برمجياً بشكل صحيح. ولكن إختبارات Fork مهمة لاختبار سلوك بروتوكول الطرف الثالث مع كل التعقيدات والحالات المختلفة (المشروعة أو المتلاعب بها) التي يمكن أن يكون البروتوكول فيها. وبالنسبة لبعض المهندسين في فريقنا، يعد التطوير القائم على الاختبار باستخدام اختبارات Fork هو وضع التطوير الأساسي. يعد تقليل وقت "تعديل الكود" إلى "تنفيذ الاختبار" أمراً ضرورياً.
دورة تطوير اختبار Fork
في Origin، نستخدم إجراءات حازمة لـSolidity development stack الخاص بنا. من المهم أن نفهم الخطوات المختلفة التي يتكون منها إجراء اختبار Fork من أجل تقليل وقت دورة التطوير. من أجل التبسيط، سنقوم بإجراء اختبار Fork واحد فقط في كل مرة - وهو عادة ما يكون النهج عند العمل على عقد ذكي.
- تجميع - هذه خطوة ضرورية عند إجراء تغييرات على التعليمات البرمجية لعقود Solidity. يحدث ذلك مع اختبارات Fork وUnit على حد سواء، ويعتمد الوقت المستغرق على عدد العقود التي تم تغييرها منذ آخر عملية تجميع.
- عمليات النشر - نستخدم البرنامج الإضافي hardhat-deploy. تستخدم ملفات النشر لنشر تغييرات protocol repository على الشبكة الرئيسية. لأننا نريد أن تحاكي بيئة Fork الشبكة الرئيسية قدر الإمكان، يتم تشغيل هذه الملفات تقريباً دون تغيير في بيئة Fork. هناك أيضاً بعض الأشياء التي يجب مراعاتها:
- اعتمادًا على ارتفاع كتلة Fork، يتم تشغيل عمليات النشر التي لم تنعكس بعد في عقدة Fork.
- نظرًا لأن OUSD وOETH يخضعان لـ DAO، فإن كل عملية نشر تحتاج للخضوع لإجراءات الإدارة. يتم نشر المقترح أولاً، ثم تكون هناك فترة تصويت، وبعد ذلك يتم إدراج المقترح في قائمة الانتظار وتنفيذه. تستغرق محاكاة كل تلك الخطوات على العقدة وقتاً ثميناً.
- ما بعد النشر - خطوة عامة لجميع الاختبارات حيث يتم تمويل حسابات الاختبار وإعادة تعيين مخصصاتها
- أداة الاختبار - تتطلب بعض الاختبارات وضع البروتوكول في حالة معينة حتى يكون الاختبار قابلاً للتطبيق (على سبيل المثال، تمكين وتمويل استراتيجية معطلة حاليًا على الشبكة الرئيسية).
- الاختبار - اختبار Fork نفسه
النهج الأبطأ
الطريقة الأبطأ هي إجراء اختبارات Fork باستخدام Node Fork من أحدث كتلة. بهذه الطريقة، في كل مرة يتم إجراء الاختبارات، يتم اختيار رقم كتلة مختلف، ولا تتمكن Hardhat من القيام بأي تخزين مؤقت من خلال قراءة storage slots من مزود الشبكة الرئيسية. وينعكس هذا في سرعة التنفيذ البطيئة البالغة 101 ثانية.
يرسل اختبار Fork هذه الأموال إلى إحدى إستراتيجيات تعدين السيولة لدينا والتي توظف الأصول في مجمع Balancer. يؤدي ذلك إلى قدر كبير من قراءات storage slots وهو السبب الرئيسي لجزء الاختبار البطيء من التنفيذ (الجزء البرتقالي من الشريط أعلاه).
بديل أسرع
تتمثل الفكرة البسيطة في تثبيت ارتفاع الكتلة هي تمكن Hardhat من توفير قدر كبير من الوقت من خلال استخدام ذاكرة تخزين مؤقت محلية لقراءات storage slots. لا يتأثر وقت التجميع بهذا التحسين، ولكن جميع الخطوات الأخرى تتأثر بذلك. تقليل وقت الدورة بشكل كبير إلى 27 ثانية (ينطبق هذا على جميع عمليات التشغيل غير الأولى للاختبار، حيث تكون ذاكرة التخزين المؤقت للـHardhat جاهزة بالفعل).
هل يمكن أن يكون أسرع؟
يعمل النهج المذكور أعلاه على تحسين الوضع بشكل كبير، لكنه لا يزال بعيداً عن سرعة اختبارات Unit ويمكن أن يبدو بطيئاً بشكل محبط في بعض الأحيان. لقد قمنا بتغيير عقد واحد فقط. لماذا نحتاج إلى إعادة تشغيل نفس عمليات النشر وما بعد النشر عندما يكون رمز البايت لعقد Solidity واحد (أو أكثر) بحاجة إلى التغيير؟ نظراً لذلك، فإننا بالطبع لا نغير تخطيط storage slots أو الحالة بين المجموعات.
عمليات النشر السريع: شيطان السرعة
ينشر Hot-deploy العقد الذي يتم تعديله ويجلب رمز البايت الخاص به. وباستخدام لقطات مجموعة اختبار Hardhat، فإنه يعثر على الإصدار السابق من هذا العقد في حالة قبل إجراء الاختبارات ويستبدل رمز البايت الخاص به بالرمز المجمع حديثًا. علاوة على ذلك، فإنه يقوم بتشغيل تركيبات الاختبار والاختبار نفسه، متخطيًا جميع خطوات النشر (ما بعد).
تم الآن تقليل وقت الدورة إلى 7 ثوانٍ فقط. لقد ساعد هذا التغيير في دورة تطوير Origin Protocol على تحسين الإنتاجية والسرعة التي يمكننا من خلالها تطوير الميزات بشكل كبير.
حل تقني
لسوء الحظ، لا يمكن تشغيل النشر السريع بسهولة (على الأقل حتى الآن) ويتطلب ذلك بعض التكوين. الطريقة التي طبقنا بها الحل في Origin هي كما يلي:
- لدينا وظيفة يمكنها إنشاء أي عقود قابلة للنشر السريع باستخدام parameters المنشئ الدقيقة الموجودة على الشبكة الرئيسية. لا يمكن تجنب ذلك حيث يمكن للمنشئ تحديد متغيرات ثابتة أو غير قابلة للتغيير يتم تخزينها في كود بايت العقد بدلاً من storage slots.
- باستخدام مطور العلامات البيئية، يمكن تحديد مجموعات العقود (إن وجدت) التي سيتم نشرها بسرعة في كل تشغيل اختباري. هذا خاص جدًا ببروتوكولنا ومن المحتمل أن يختلف عن التطبيقات الأخرى.
- تم العثور على الإصدار السابق من العقد على عقدة Fork وتم استبدال رمز بايت التنفيذ الخاص به بالرمز المجمع حديثًا.
أحد المتطلبات المهمة هو أن تعمل عقدة Hardhat المستقلة بشكل منفصل عن بيئة اختبار Fork. قد لا يكون الأمر واضحًا على الفور، ولكن تشغيل اختبار Fork سيؤدي إلى إنشاء وقت تشغيل آخر للعقدة واستخدام العقدة الأخرى قيد التشغيل. ستقوم العقدة المستقلة بتشغيل جميع عمليات النشر (اللاحقة)، وستقوم عقدة اختبار Fork بتجميع التغييرات، وتشغيل تركيبات الاختبار لاستبدال أي كود بايت للعقد مطلوب، وأخيراً تشغيل الاختبار.
من الجيد أن تضع في اعتبارك التغييرات التي تم إجراؤها على ملفات النشر و node storage slots وإعداد حالتها. يجب أن تفكر في أن تركيبات الاختبار قيد التشغيل تتطلب إعادة تشغيل العقدة المستقلة.
خاتمة
في بعض الأحيان قد نميل إلى استخدام اختبارات Fork لأجزاء من النظام الأساسي التي تتكامل مع بروتوكولات الطرف الثالث فقط حتى نتمكن من التطوير بشكل أسرع... على حساب الأمان الإضافي الذي يمكن أن يوفره اختبار Fork. بالنسبة للمطورين في Origin، تعد عمليات hot deploy خطوة مهمة لسد الفجوة الزمنية للدورة. أتمنى أن يحاول الآخرون ذلك، وأتمنى أن تستفيد من هذا النهج لتقليل أوقات دورة التطوير الخاصة بك.
