السؤال المفضل حول أي نظام موزع من شخص غير تقني هو "كم عدد tps الموجودة على blockchain الخاص بك؟". ومع ذلك ، فإن الرقم المعطى للرد عادة لا علاقة له بما يود السائل أن يسمعه. في الواقع ، أراد أن يسأل "هل blockchain الخاص بك مناسبًا لمتطلبات عملي" ، وهذه المتطلبات ليست رقمًا واحدًا ، ولكن العديد من الشروط - إليك التسامح مع أخطاء الشبكة ، ومتطلبات النهاية ، وحجم وطبيعة المعاملات والعديد من المعلمات الأخرى. لذا فإن الإجابة على السؤال "كم عدد tps" من غير المرجح أن تكون بسيطة ، وتقريبًا لن تكون كاملة. يمكن أن يكون النظام الموزع الذي يحتوي على عشرات أو مئات العقد التي تؤدي عمليات حسابية معقدة للغاية في عدد كبير من الحالات المختلفة المتعلقة بحالة الشبكة ومحتويات blockchain والفشل الفني والمشكلات الاقتصادية والهجمات على الشبكة والعديد من الحالات. أسباب أخرى. تختلف المراحل التي تكون فيها مشكلات الأداء ممكنة عن الخدمات التقليدية ، وخادم شبكة blockchain عبارة عن خدمة شبكة تجمع بين وظائف قاعدة البيانات وخادم الويب وعميل التورنت ، مما يجعلها معقدة للغاية من حيث ملف تعريف التحميل على جميع الأنظمة الفرعية: المعالج ، الذاكرة ، الشبكة ، التخزين
لقد حدث أن الشبكات اللامركزية والبلوكشين هي برامج محددة وغير عادية لمطوري البرامج المركزية. لذلك ، أود أن أسلط الضوء على الجوانب المهمة لأداء واستدامة الشبكات اللامركزية ، ونهج قياسها وإيجاد الاختناقات. سننظر في مشكلات الأداء المختلفة التي تحد من سرعة تقديم خدمة لمستخدمي blockchain ونلاحظ الميزات الخاصة بهذا النوع من البرامج.
خطوات طلب خدمة من قبل عميل blockchain
من أجل التحدث بصدق عن جودة أي خدمة أكثر أو أقل تعقيدًا ، يجب أن تأخذ في الاعتبار ليس فقط القيم المتوسطة ، ولكن أيضًا الحد الأقصى / الأدنى ، والمتوسطات ، والنسب المئوية. من الناحية النظرية ، يمكننا التحدث عن 1000 tps في بعض blockchain ، ولكن إذا تم إكمال 900 معاملة بسرعة هائلة ، و 100 "مجمدة" لعدة ثوان ، فإن متوسط الوقت الذي تم جمعه في جميع المعاملات ليس مقياسًا صادقًا تمامًا للعميل الذي في غضون ثوانٍ قليلة ، لم أتمكن من إكمال المعاملة. يمكن أن تؤثر المزالق المؤقتة التي تسببها جولات الإجماع الضائعة أو انقسامات الشبكة بشدة على الخدمة التي كانت تعمل بشكل جيد في مناضد الاختبار.
من أجل تحديد مثل هذه الاختناقات ، من الضروري أن يكون لديك فهم جيد للمراحل التي يمكن أن تواجه فيها blockchain الحقيقي صعوبات في خدمة المستخدمين. دعنا نصف دورة التسليم والمعالجة للمعاملة ، وكذلك تلقي حالة جديدة من blockchain ، والتي يمكن للعميل من خلالها التحقق من أن معاملته قد تمت معالجتها وحسابها.
- يتم إنشاء المعاملة على العميل
- يتم توقيع المعاملة على العميل
- يختار العميل إحدى العقد ويرسل معاملته إليها
- يشترك العميل في تحديثات قاعدة بيانات الحالة الخاصة بالعقدة ، في انتظار نتائج تنفيذ معاملته
- تقوم العقدة بنشر المعاملة عبر شبكة p2p
- تقوم عدة BP (منتج كتلة) أو واحد بمعالجة المعاملات المتراكمة ، وتحديث قاعدة بيانات الدولة
- تشكل BP كتلة جديدة بعد معالجة العدد المطلوب من المعاملات
- توزع BP كتلة جديدة عبر شبكة p2p
- يتم تسليم الكتلة الجديدة إلى العقدة التي يصل إليها العميل
- العقدة بتحديث قاعدة بيانات الدولة
- ترى العقدة التحديث المتعلق بالعميل وترسل إليه إشعارًا بالمعاملة
الآن دعنا نلقي نظرة فاحصة على هذه المراحل ونصف مشكلات الأداء المحتملة في كل مرحلة. على عكس الأنظمة المركزية ، سننظر أيضًا في تنفيذ التعليمات البرمجية على عملاء الشبكة. في كثير من الأحيان ، عند قياس tps ، يتم جمع وقت معالجة المعاملة من العقد ، وليس من العميل - وهذا ليس عادلاً تمامًا. لا يهتم العميل بمدى سرعة معالجة العقدة لمعاملته ، فالشيء الأكثر أهمية بالنسبة له هو اللحظة التي تصبح فيها المعلومات الموثوقة حول هذه المعاملة المضمنة في blockchain متاحة له. هذا المقياس هو في الأساس وقت تنفيذ الصفقة. هذا يعني أن العملاء المختلفين ، حتى الذين يرسلون نفس المعاملة ، يمكن أن يحصلوا على أوقات مختلفة تمامًا ، والتي تعتمد على القناة والحمل وقرب العقدة ، إلخ. لذلك من الضروري قياس هذا الوقت على العملاء ، لأن هذه هي المعلمة التي يجب تحسينها.
تحضير معاملة من جانب العميل
لنبدأ بالنقطتين الأوليين: يتم تشكيل الصفقة وتوقيعها من قبل العميل. ومن الغريب أن هذا يمكن أن يكون أيضًا عقبة في أداء blockchain من وجهة نظر العميل. هذا أمر غير معتاد بالنسبة للخدمات المركزية التي تأخذ جميع العمليات الحسابية والبيانات لأنفسهم ، ويقوم العميل ببساطة بإعداد طلب قصير يمكنه طلب كمية كبيرة من البيانات أو الحسابات ، والحصول على النتيجة النهائية. في blockchains ، يصبح رمز العميل أكثر قوة ، ويصبح جوهر blockchain خفيف الوزن أكثر فأكثر ، ومن المعتاد إعطاء مهام حوسبة ضخمة لبرنامج العميل. في blockchains ، هناك عملاء يمكنهم إعداد معاملة واحدة لفترة طويلة جدًا (أتحدث عن العديد من أدلة Merkle والبراهين الموجزة وتوقيعات العتبة والعمليات المعقدة الأخرى من جانب العميل). مثال جيد على التحقق السهل على السلسلة والتحضير المكثف للمعاملات على العميل هو دليل عضوية قائمة Merkle-tree ، هنا .
أيضًا ، لا تنس أن رمز العميل لا يرسل المعاملات إلى blockchain فحسب ، بل يطلب أولاً حالة blockchain - ويمكن أن يؤثر هذا النشاط على عبء العمل على الشبكة وعقد blockchain. لذلك عند إجراء القياسات ، من الحكمة محاكاة سلوك رمز العميل بأكبر قدر ممكن. حتى إذا كان لدى blockchain الخاص بك عملاء ضوء عاديون يضعون توقيعًا رقميًا عاديًا على أبسط معاملة لنقل نوع من الأصول ، فلا تزال هناك حسابات ضخمة على العميل كل عام ، كما أن خوارزميات التشفير تزداد قوة ، وهذا الجزء من يمكن أن تتحول المعالجة إلى عنق زجاجة كبير في المستقبل. لذلك ، احرص على عدم تفويت الموقف عندما يتم إنفاق 3.5 ثانية في إعداد المعاملة وتوقيعها في معاملة تدوم 2.5 ثوانٍ ، ويتم إنفاق 1.0 ثانية في إرسالها إلى الشبكة وانتظار الرد. لتقييم مخاطر هذا الاختناق ، تحتاج إلى جمع المقاييس من أجهزة العميل ، وليس فقط من عقد blockchain.
إرسال معاملة ومراقبة حالتها
الخطوة التالية هي إرسال المعاملة إلى عقدة blockchain المحددة والحصول على حالة قبولها في تجمع المعاملات. تشبه هذه الخطوة الوصول العادي إلى قاعدة البيانات ، يجب على العقدة كتابة المعاملة إلى التجمع والبدء في توزيع المعلومات عنها عبر شبكة p2p. يشبه نهج تقييم الأداء هنا تقييم عمل الخدمات المصغرة لواجهة برمجة تطبيقات الويب التقليدية ، ويمكن تحديث المعاملات نفسها في البلوكشين وتغيير حالتها بشكل فعال. بشكل عام ، يمكن أن يحدث تحديث المعلومات حول معاملة في بعض سلاسل الكتل عدة مرات ، على سبيل المثال ، عند التبديل بين مفترقات السلسلة أو عندما تشير BPs إلى نيتها تضمين معاملة في كتلة. يمكن أن تؤثر القيود المفروضة على حجم هذا التجمع وعدد المعاملات فيه على أداء blockchain. إذا تم ملء تجمع المعاملات بأقصى حجم ممكن ، أو لم يكن مناسبًا لذاكرة الوصول العشوائي ، فقد ينخفض أداء الشبكة بشكل حاد. لا تتمتع بلوكتشين بحماية مركزية ضد تدفق الرسائل غير المرغوب فيها ، وإذا كانت البلوكشين تدعم المعاملات ذات الحجم الكبير والرسوم المنخفضة ، فقد يؤدي ذلك إلى تجاوز مجموعة المعاملات - وهذا هو عنق الزجاجة المحتمل الآخر في الأداء.
في blockchains ، يرسل العميل معاملة إلى أي عقدة من blockchain التي يحبها ، وعادة ما يكون تجزئة المعاملة معروفة للعميل قبل الإرسال ، لذلك كل ما يحتاجه هو إنشاء اتصال ، وبعد الإرسال ، انتظر وصول blockchain إلى تغيير حالتها ، بما في ذلك معاملته. لاحظ أنه من خلال قياس "tps" ، يمكنك الحصول على نتائج مختلفة تمامًا عن طرق مختلفة للاتصال بعقدة blockchain. يمكن أن يكون هذا HTTP RPC عاديًا أو WebSocket يسمح لك بتنفيذ نمط "الاشتراك". في الحالة الثانية ، سيتلقى العميل إشعارًا في وقت سابق ، وستنفق العقدة موارد أقل (الذاكرة وحركة المرور بشكل أساسي) على الاستجابات حول حالة المعاملة. لذلك عند قياس "tps" ، يجب أن تأخذ في الاعتبار طريقة اتصال العملاء بالعقد. لذلك ، من أجل تقييم مخاطر هذا الاختناق ، يجب أن تكون blockchain المعيارية قادرة على محاكاة العملاء مع طلبات WebSocket و HTTP RPC ، بنسب تتوافق مع الشبكات الحقيقية ، وكذلك تغيير طبيعة المعاملات وحجمها.
لتقييم مخاطر هذا الاختناق ، تحتاج أيضًا إلى جمع المقاييس من أجهزة العميل ، وليس فقط من عقد blockchain.
نقل المعاملات والكتل عبر شبكة P2P
في blockchains ، يتم استخدام شبكات نظير إلى نظير (p2p) لنقل المعاملات والكتل بين المشاركين. تنتشر المعاملات عبر الشبكة ، بدءًا من إحدى العقد ، حتى تصل إلى أقرانهم من منتجي الكتلة ، الذين يحزمون المعاملات في كتل ، وباستخدام نفس p2p ، يوزعون كتل جديدة على جميع عقد الشبكة. أساس معظم شبكات p2p الحديثة هو التعديلات المختلفة لبروتوكول Kademlia. نظرة عامة جيدة على هذا البروتوكول ، و - مقال يحتوي على قياسات مختلفة في شبكة BitTorrent ، يمكن من خلالها فهم أن هذا النوع من الشبكات أكثر تعقيدًا وأقل قابلية للتنبؤ به من شبكة مكونة بشكل صارم لخدمة مركزية. أيضًا، مقال حول قياس مختلف المقاييس المثيرة للاهتمام لعقد Ethereum.
باختصار ، يحتفظ كل نظير في هذه الشبكات بقائمته الديناميكية الخاصة بالأقران الآخرين التي يطلب منها كتل المعلومات التي يمكن معالجتها بواسطة المحتوى. عند استلام الطلب ، يقوم النظير إما بإعطاء المعلومات اللازمة ، أو تمرير الطلب إلى النظير العشوائي الزائف التالي من القائمة ، وبعد تلقي الإجابة ، يقوم بتمريرها إلى مقدم الطلب وتخزينها مؤقتًا لفترة من الوقت ، مع إعطاء هذا الحظر من المعلومات في وقت سابق في المرة القادمة. وهكذا ، ينتهي الأمر بالمعلومات الشائعة في عدد كبير من مخابئ عدد كبير من الأقران ، ويتم إجبار المعلومات التي لا تحظى بشعبية على الخروج تدريجياً. يحتفظ الأقران بسجل لمن أرسل المعلومات إلى من ، وتحاول الشبكة تحفيز الموزعين النشطين من خلال زيادة تصنيفهم وتزويدهم بمستوى أعلى من الخدمة ، مع استبعاد المشاركين غير النشطين تلقائيًا من قوائم الأقران.
لذلك ، يجب الآن نشر المعاملة عبر الشبكة حتى يتمكن منتجو الكتل من رؤيتها وإدراجها في الكتلة. تقوم العقدة بنشاط "بتوزيع" معاملة جديدة للجميع وتستمع إلى الشبكة ، في انتظار كتلة في الفهرس ستظهر المعاملة المطلوبة لإخطار العميل المنتظر. يعتمد الوقت المستغرق حتى تنقل الشبكة معلومات حول المعاملات والكتل الجديدة إلى بعضها البعض في شبكات p2p على عدد كبير جدًا من العوامل: عدد العقد الصادقة التي تعمل جنبًا إلى جنب (من وجهة نظر الشبكة) ، و "الإحماء" ذاكرات التخزين المؤقت لهذه العقد ، وحجم الكتل ، والمعاملات ، وطبيعة التغييرات ، وجغرافية الشبكة ، وعدد العقد والعديد من العوامل الأخرى. يعد القياس الشامل لمقاييس الأداء في مثل هذه الشبكات مهمة صعبة ، فمن الضروري إجراء تقييم متزامن لوقت معالجة الطلبات على كل من العملاء والأقران (عقد blockchain). المشاكل في أي من آليات p2p ، الاستباق غير الصحيح للبيانات والتخزين المؤقت ، الإدارة غير الفعالة لقوائم الأقران النشطة ، والعديد من العوامل الأخرى يمكن أن تسبب تأخيرات تؤثر على كفاءة الشبكة بأكملها ، وهذا الاختناق هو الأكثر صعوبة في التحليل ، اختبار وتفسير النتائج.
معالجة سلسلة الكتل وتحديث قاعدة بيانات الحالة
الجزء الأكثر أهمية في blockchain هو خوارزمية الإجماع ، وتطبيقها على الكتل الجديدة المستلمة من الشبكة ومعالجة المعاملات مع النتائج المسجلة في قاعدة بيانات الدولة. يجب أن تعمل إضافة كتلة جديدة إلى السلسلة ثم اختيار السلسلة الرئيسية بأسرع ما يمكن. ومع ذلك ، في الحياة الواقعية ، لا تعني كلمة "should" "أعمال" ، ويمكن للمرء ، على سبيل المثال ، تخيل موقف حيث تقوم سلسلتان متنافستان طويلتان بالتبديل باستمرار فيما بينهما ، مما يؤدي إلى تغيير البيانات الوصفية لآلاف المعاملات في المجموعة على كل مفتاح ، وإجراء عمليات التراجع المستمرة عن حالة قاعدة بيانات الولاية. هذه المرحلة ، من حيث تعريف عنق الزجاجة ، أبسط من طبقة شبكة p2p ، لأن يعد تنفيذ المعاملات وخوارزمية الإجماع محددين بدقة ، ومن الأسهل قياس أي شيء هنا.
الشيء الرئيسي هو عدم الخلط بين التدهور العشوائي في الأداء لهذه المرحلة ومشاكل الشبكة - تكون العقد أبطأ في إعطاء كتل ومعلومات حول السلسلة الرئيسية ، وبالنسبة للعميل الخارجي قد تبدو شبكة بطيئة ، على الرغم من أن المشكلة تكمن في مكان مختلف تمامًا.
لتحسين الأداء في هذه المرحلة ، من المفيد جمع المقاييس ومراقبتها من العقد نفسها ، وتضمين تلك المتعلقة بتحديث قاعدة بيانات الحالة: عدد الكتل التي تمت معالجتها على العقدة ، وحجمها ، وعدد المعاملات ، والرقم عدد المفاتيح بين مفترقات السلسلة ، وعدد الكتل غير الصالحة ، ووقت تشغيل الآلة الافتراضية ، ووقت تنفيذ البيانات ، وما إلى ذلك. سيؤدي ذلك إلى تجنب الخلط بين مشاكل الشبكة والأخطاء في خوارزميات معالجة السلسلة.
يمكن أن تكون الآلة الافتراضية لمعالجة المعاملات مصدرًا مفيدًا للمعلومات التي يمكنها تحسين تشغيل blockchain. يمكن أن يوفر عدد عمليات تخصيص الذاكرة وعدد تعليمات القراءة / الكتابة والمقاييس الأخرى المتعلقة بكفاءة تنفيذ رمز العقد الكثير من المعلومات المفيدة للمطورين. في الوقت نفسه ، تعد العقود الذكية برامج ، مما يعني أنه من الناحية النظرية يمكنهم استهلاك أي من الموارد: وحدة المعالجة المركزية / الذاكرة / الشبكة / التخزين ، لذا فإن معالجة المعاملات هي مرحلة غير محددة إلى حد ما ، والتي ، بالإضافة إلى ذلك ، تتغير بشكل كبير عند التبديل بين الإصدارات وعند تغيير كود العقود. لذلك ، هناك حاجة أيضًا إلى المقاييس المتعلقة بمعالجة المعاملات لتحسين أداء blockchain بشكل فعال.
استلام العميل لإشعار بشأن إدراج معاملة في blockchain
هذه هي المرحلة الأخيرة في استلام الخدمة من قبل عميل blockchain ، مقارنة بالمراحل الأخرى ، لا توجد تكاليف عامة كبيرة هنا ، ولكن لا يزال من الجدير النظر في إمكانية تلقي العميل استجابة كبيرة من العقدة (لـ على سبيل المثال ، عقد ذكي يقوم بإرجاع مجموعة من البيانات). على أي حال ، هذه اللحظة بالذات هي الأهم بالنسبة لمن طرح السؤال "كم عدد tps في blockchain الخاص بك؟" في هذه اللحظة ، يتم تحديد وقت تلقي الخدمة.
في هذا المكان ، هناك بالضرورة إرسال للوقت الكامل الذي كان على العميل أن يقضيه في انتظار رد من blockchain ، هذه المرة سينتظر المستخدم التأكيد في تطبيقه ، والتحسين هو المهمة الرئيسية للمطورين.
اختتام
نتيجة لذلك ، من الممكن وصف أنواع العمليات التي يتم إجراؤها على البلوكشين وتقسيمها إلى عدة فئات:
- تحويلات التشفير وبناء البراهين
- شبكات الند للند والمعاملات والنسخ المتماثل
- معالجة المعاملات وتنفيذ العقود الذكية
- تطبيق التغييرات في blockchain على قاعدة بيانات الدولة ، وتحديث بيانات المعاملات والكتل
- طلبات قاعدة بيانات الحالة للقراءة فقط ، واجهات برمجة تطبيقات عقدة blockchain ، وخدمات الاشتراك
بشكل عام ، تعتبر المتطلبات الفنية لعقد سلاسل الكتل الحديثة خطيرة للغاية - فهذه وحدات معالجة مركزية سريعة للتشفير ، وكمية كبيرة من ذاكرة الوصول العشوائي لتخزين قاعدة بيانات الحالة والوصول إليها بسرعة ، وتفاعل الشبكة باستخدام عدد كبير من الاتصالات المفتوحة في وقت واحد ، تخزين ضخم. تؤدي هذه المتطلبات العالية ووفرة الأنواع المختلفة من العمليات حتماً إلى حقيقة أن موارد العقد قد لا تكون كافية ، ومن ثم يمكن أن تصبح أي من المراحل التي تمت مناقشتها أعلاه عنق زجاجة آخر لأداء الشبكة بشكل عام.
عند تصميم أداء سلاسل الكتل وتقييمها ، سيتعين عليك مراعاة كل هذه النقاط. للقيام بذلك ، تحتاج إلى جمع المقاييس وتحليلها في وقت واحد من العملاء وعُقد الشبكة ، والبحث عن الارتباطات بينها ، وتقييم وقت تقديم الخدمة للعملاء ، ومراعاة جميع الموارد الرئيسية: وحدة المعالجة المركزية / الذاكرة / الشبكة / التخزين ، وفهم كيف يتم استخدامها والتأثير على بعضها البعض. كل هذا يجعل مقارنة سرعات سلاسل الكتل المختلفة في شكل "كم عدد TPS" مهمة غير مجدية للغاية ، نظرًا لوجود عدد كبير من التكوينات والحالات المختلفة. في الأنظمة المركزية الكبيرة ، مجموعات المئات من الخوادم ، هذه المشكلات معقدة أيضًا وتتطلب أيضًا تجميع عدد كبير من المقاييس المختلفة ، ولكن في blockchain ، بسبب شبكات p2p ، وعقود معالجة الآلات الافتراضية ، والاقتصاد الداخلي ، وعدد الدرجات الحرية أكبر بكثير ، مما يجعل الاختبار حتى على العديد من الخوادم ، غير واضح ولا يُظهر سوى قيم تقريبية للغاية لا علاقة لها بالواقع تقريبًا.
لذلك ، عند التطوير في جوهر blockchain ، لتقييم الأداء والإجابة على السؤال "ما إذا كان قد تحسن مقارنةً بآخر مرة" ، نستخدم برنامجًا معقدًا إلى حد ما ينظم إطلاق blockchain مع عشرات العقد ويطلق تلقائيًا a قياس الأداء وتجميع المقاييس ، وبدون هذه المعلومات يكون من الصعب للغاية تصحيح أخطاء البروتوكولات التي تعمل مع عدة مشاركين.
لذا ، بعد تلقي السؤال "ما مقدار TPS في blockchain الخاص بك؟" ، قدم الشاي للمحاور واسأل عما إذا كان مستعدًا للتعرف على عشرات الرسوم البيانية والاستماع أيضًا إلى جميع المربعات الثلاثة لمشاكل أداء blockchain واقتراحاتك لحلها هم…
المصدر: www.habr.com