لا تتوقف عن العمل: أفضل الممارسات للتعامل مع ترقيات عميل القسطنطينية و Ethereum

تعد تحديثات البرامج ، سواء لسد ثغرات الأمان أو إصلاح الأخطاء أو إضافة ميزات جديدة ، أمرًا جيدًا عمومًا للتطبيقات التي نستخدمها كل يوم ، ولا نفكر مرتين في تطبيقها. لكن يمكن أيضًا أن تكون تحديثات الأجزاء الأساسية للبنية الأساسية مخيفة عندما تقدم تغييرات عاجلة أو سلوكًا غير متوقع للتطبيقات التابعة ، أو في حالات أخرى عندما يؤدي الفشل في التحديث في الوقت المحدد إلى حدوث كسر. تؤثر هذه المشكلة على الكيانات الصغيرة والكبيرة ، كما أن blockchain ليست استثناء.

في Alchemy ، نوفر البنية التحتية Ethereum موثوقة وقابلة للتطوير وسريعة لعملائنا حتى لا يضطروا إلى الحفاظ على العقد ويمكنهم التركيز على بناء تطبيقاتهم. في سياق عملنا ، تعلمنا العديد من الدروس (أحيانًا الطريقة الصعبة!) حول كيفية التعامل بشكل أفضل مع شوكات الشبكة وتحديثات العميل. مع شوكة القسطنطينية القادمة ، اعتقدنا أن هذه ستكون فرصة رائعة لمشاركة بعض من أفضل ممارساتنا.

هذه هي الأولى في العديد من منشورات المدونة التي سنكتبها حول تشغيل البنية الأساسية لـ Ethereum بطريقة موثوقة وأداء وقابلة للتطوير.

القسطنطينية

القسطنطينية هي التحديث القادم على مستوى النظام في Ethereum وستقوم بتنفيذ خمس خطط تنفيذية ، والتي تعد في الواقع جزءًا من خريطة طريق أكبر نحو Ethereum 2.0. هناك الكثير من المنشورات التي تناقش التغييرات المحددة ، لكن الشيء الرئيسي الذي يجب ملاحظته هو أنه نظرًا لأن هذا شوكة صلبة غير مثيرة للجدل ، فسوف يعتمد المجتمع الشوكة الجديدة ، مما يجعل الرموز وغيرها من الحالات على عقد غير محدثة لا قيمة لها.

كيف يؤثر هذا عليك؟

بالنسبة لمطوري dapp ، فإن الوجبات الرئيسية هي أنك ستحتاج إلى تحديث العقدة الخاصة بك إلى إصدار متوافق مع القسطنطينية أو ستكون غير متوافقة مع الجزء المتبقي من كتلة الشبكة السابقة البالغة 7،080،000. من المحتمل أن يكون عملاء Ethereum محدّثين على الشوكات الصلبة في السلسلة ويصدروا نسخة ثابتة ومتوافقة من عملائهم قبل وقت طويل من تاريخ الشوكة التقديري ، على سبيل المثال غيت والمساواة. إذا كنت تدير عقدة عميل Ethereum الخاصة بك ، فستحتاج إلى تحديث عميل ethereum إلى إصدار متوافق مع الشوكة الصلبة ؛ سيكون التكافؤ 2.1.10-مستقرة أو أعلى ، و geth سيكون 1.8.20 أو أعلى.

يجب أن تكون تحديثات الشوكة الصلبة قليلة ومتباعدة ، ولكن يمكن أن تكون تحديثات عميل Ethereum أكثر شيوعًا. إذا كنت تقوم بتشغيل خدمة تعتمد على السلسلة ، فقد يكون تحديث عميلك مفيدًا لإصلاح عيوب الأمان أو الاستفادة من وظائف جديدة. ومع ذلك ، يجب أن تكون حريصًا على عدم تقديم مشكلات غير متوقعة في طلبك.

أفضل الممارسات

إذا كنت تقوم بتشغيل خدمة تتطلب تفاعلًا منتظمًا مع Ethereum blockchain ، فستوفر لك أفضل الممارسات الأساسية اثنين من الأخطاء الكارثية المحتملة عند تحديث العقد. سنتناول بعض السيناريوهات الواقعية للتحديثات بشكل سيء والتي كانت الدافع لنشر المدونة هذا.

تشغيل عقد متعددة

نوصي بشدة بتشغيل عقد متعددة كأفضل ممارسة عامة للمحافظة على البنية التحتية الداخلية في Ethereum نظرًا للعديد من الفوائد ، بما في ذلك زيادة الموثوقية وقابلية التوسع. ومع ذلك ، يمكن أن يؤدي ذلك إلى إدخال مشكلات الاتساق والضعف في نظامك ، والتي سنتناولها في منشور مدونة لاحق.

عندما يتعلق الأمر بالتحديثات ، يوفر تشغيل عقد متعددة فوائد إضافية قليلة:

  1. تعمل العقد الإضافية كنسخ احتياطية في حالة حدوث خطأ ما وتحول دون استعادة العقدة
  2. توفر عالية دون توقف أثناء تحديث العقد بطريقة متجددة
  3. للسماح لاختبار الانحدار الذي يقارن العقد المحدّثة بالعقد الأصلية لضمان السلوك المتوقع

في سيناريو عقدة غير قابلة للاسترداد ، يمكن أن تستغرق عقدة الأرشيف الكاملة الجديدة ما يصل إلى أسبوعين للمزامنة بالكامل. بدون نسخة احتياطية ، هذا هو مقدار غير مقبول من التوقف.

مثال 1: Buggy DB Migration

إحدى المشكلات التي رأيناها عند ترقية التكافؤ من 1.X.X إلى 2.X.X هي الفساد في قاعدة البيانات. تضمن التحديث ترحيل DB داخلي والذي تم بشكل غير صحيح تحويل أرقام الكتلة في مرشح bloom مما أدى إلى نتائج فارغة لطلبات getLog للكتل التاريخية. كان فقدان البيانات لا رجعة فيه ، وبالتالي لا يمكن إنقاذ العقدة. لقد كنا محظوظين بما يكفي للتعرف عليها من خلال الاختبارات الداخلية على عقدة الكناري ، والعودة إلى العقد غير المحدثة للحفاظ على أنظمتنا ، والانتظار حتى يتم حل المشكلة من قبل فريق التكافؤ في الإصدار 2.2.3 بيتا.

اختبار الانحدار الصارم

يُنصح دائمًا بإجراء اختبارات صارمة لأي تغييرات على نظامك. في هذا السياق ، عند تحديث العقد ، ستحتاج إلى اختبار للتأكد من أن تطبيقك وبنيتك التحتية يواصلان العمل كما هو متوقع. قد يؤدي القيام بخلاف ذلك إلى تعريض المستخدمين وأنظمتك للانقطاع. مع وجود العديد من العقد قيد التشغيل ، فإن أفضل طريقة لضمان ذلك هي اختبار العقد الثابتة السابقة مقابل عقدة الكناري المحدثة. إذا تم الكشف عن أي تغييرات فاصلة ، فتأكد من أن أنظمتك يمكنها التعامل معها بأمان قبل تحديث بقية المجموعة.

بالنسبة لاختبارات الانحدار ، نذهب مباشرة إلى المصدر من خلال إعادة تشغيل طلبات الإنتاج مقابل عقدنا. يمكن القيام بذلك يدويًا لإجراء فحوصات لمرة واحدة ، ولكن نظرًا لأننا ندعم العديد من المشاريع ، فقد أنشأنا إطار عمل اختبارًا آليًا موسعًا يقوم بتجربة الطلبات المباشرة الحديثة ، وإعادة إرسالها على إصدارات مختلفة من العملاء ، ومقارنة النتائج. يسمح لنا ذلك بالتحقق من أن الكود الخاص بنا يمكنه التفاعل بأمان مع العقد المحدثة قبل الشحن إلى الإنتاج. يمكن الاستفادة من هذا الإطار لاختبارات الانحدار حول التغييرات في الكود الداخلي أيضًا.

مثال 2: تغيير تنسيق الإخراج استجابة

كانت هذه مشكلة شيقة واجهناها عندما قام عميل تم تحديثه حديثًا بإرجاع استجابة مختلفة عن خطأ تنفيذ EVM. عرضت Parity 1.11.1-beta ردًا بدا كالتالي:

{"jsonrpc": "2.0" ، "error": {"code": - 32015 ، "message": "خطأ تنفيذ VM." ، "data": "Reverted 0x"} ، "id": 1}

بدلاً من الردود من الإصدارات السابقة التي بدت كالتالي:

{ "jsonrpc": "2.0"، "الهوية": 1، "نتيجة": "0X"}

يعد تغيير تنسيق الاستجابة مفيدًا في الواقع لأنه يضيف مزيدًا من تفاصيل التنفيذ إلى المتصل بدلاً من الفشل بصمت ، ولكنه قد يتسبب في حدوث مشكلات إذا لم يتم إعداد الكود للتعامل معه. في هذا السيناريو ، اكتشفت مقارنة مخرجات الاستجابة التغيير وقمنا ببساطة بتحديث أنظمتنا وتحذير عملائنا بحيث لا يشعرون بالقلق من الاستجابة الجديدة ، ويمكنهم تحديث خدماتهم لتكون متوافقة.

بناء على!

نأمل أن يكون هذا مفيدًا ، وأن أفضل الممارسات هذه ستجعل تحديثات العقدة غير مؤلمة بالنسبة لك في المستقبل. لقد ساعدونا في ضمان أن التحديثات دائمًا بسلاسة سواء لأنظمتنا أو للعملاء الذين يعتمدون علينا. نحن نعلم مدى صعوبة تعقيدات صيانة العقد وتوسيع نطاقها ، ونريد نشر ما تعلمناه على مر السنين.

إذا كنت تعمل في مشروع Ethereum ولا تريد التعامل مع النفقات العامة لصيانة العقد ، فتحدث إلينا! توفر Alchemy البنية التحتية الأسرع والأكثر قابلية للتوسعة والأكثر موثوقية كخدمة بحيث يمكنك التركيز على بناء منتجك. تحت غطاء محرك السيارة ، قامت Alchemy ببناء بنية تحتية جديدة ثورية تعمل بالفعل على تشغيل أفضل مشاريع blockchain مثل Augur ، وكبرى شركات blockchain مثل CryptoKitties ، وصناديق التحوط العليا (التي تدير أكثر من 3 مليارات دولار). معرفة المزيد في alchemyapi.io.