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

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

مراحل طلب خدمة عميل Blockchain

من أجل التحدث بصدق عن جودة أي خدمة أكثر أو أقل تعقيدًا ، يجب أن تأخذ في الاعتبار ليس فقط القيم المتوسطة ، ولكن أيضًا الحد الأقصى / الحد الأدنى ، المتوسطات ، النسب المئوية. من الناحية النظرية ، يمكن أن نتحدث عن 1000 tps في بعض blockchain ، ولكن إذا تم تنفيذ 900 معاملة بسرعة هائلة ، وتم "تجميد" 100 منها لعدة ثوانٍ ، فإن متوسط ​​الوقت الذي يتم جمعه لجميع المعاملات ليس مقياسًا صادقًا تمامًا للعميل في بضع ثوان لا يمكن إكمال المعاملة. يمكن لـ "الثغرات" المؤقتة التي تسببها جولات الإجماع الفائتة أو فصل الشبكة أن تفسد الخدمة بشكل كبير ، مما أظهر أداءً ممتازًا في منصات الاختبار.

لتحديد هذا الاختناق - ومن الضروري أن نفهم جيدًا المراحل التي قد تواجه فيها لعبة blockchain الحقيقية صعوبة في خدمة المستخدمين. دعنا نصف دورة التسليم والمعالجة للمعاملة ، وكذلك الحصول على حالة blockchain جديدة يمكن من خلالها العميل التحقق من أن معاملاته قد تمت معالجتها وأخذها في الاعتبار.

1. يتم تشكيل المعاملة على العميل
2. تم توقيع المعاملة على العميل
3. يختار العميل إحدى العقد ويرسل المعاملة الخاصة به إليها
4. يشترك العميل في تحديثات قاعدة بيانات حالة العقد ، في انتظار ظهور نتائج تنفيذ المعاملة الخاصة به
5. العقدة نشر معاملة عبر شبكة p2p
6. عدة أو واحد BP (منتج كتلة) سوف معالجة المعاملات المتراكمة ، وتحديث قاعدة بيانات الدولة
7. BP تشكل كتلة جديدة ، تعالج العدد المطلوب من المعاملات
8. BP توزع كتلة جديدة عبر شبكة P2P
9. يتم تسليم الكتلة الجديدة إلى العقدة التي يصل إليها العميل
10. عقدة تحديثات قاعدة بيانات الدولة
11. تشاهد العقدة التحديث المتعلق بالعميل وترسل إليه إشعارًا بالمعاملة

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

إعداد المعاملات من جانب العميل

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

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

إرسال معاملة ومراقبة حالتها

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

في block Blockins ، يرسل العميل المعاملة إلى أي عقدة blockchain التي يحبها ، وعادة ما يعرف تجزئة المعاملة للعميل قبل الإرسال ، لذلك كل ما يحتاج إليه هو الحصول على اتصال وبعد انتظار النقل حتى تتغير حالته blockchain ، تشغيل المعاملة. لاحظ أنه من خلال قياس "tps" ، يمكنك الحصول على نتائج مختلفة تمامًا عن طرق مختلفة للاتصال بالعقدة blockchain. يمكن أن يكون هذا عبارة عن HTTP RPC أو WebSocket ، مما يسمح لك بتنفيذ نمط "الاشتراك". في الحالة الثانية ، سيتلقى العميل إشعارًا في وقت مبكر ، وستنفق العقدة موارد أقل (بشكل رئيسي الذاكرة وحركة المرور) على الاستجابات حول حالة المعاملة. لذلك عند قياس "tps" ، يجب عليك التفكير في طريقة اتصال العملاء بالعقد. لذلك ، لتقييم مخاطر هذا عنق الزجاجة ، يجب أن يكون معيار سلسلة المفاتيح قادراً على محاكاة العملاء مع كل من طلبات WebSocket و HTTP RPC ، في الكسور المقابلة للشبكات الحقيقية ، وكذلك تغيير طبيعة المعاملات وحجمها.

لتقييم مخاطر عنق الزجاجة ، تحتاج أيضًا إلى جمع المقاييس من الأجهزة العميلة ، وليس فقط من العقد blockchain.

نقل المعاملات وكتل عبر شبكة P2P

في block Block ، يتم استخدام شبكة نظير إلى نظير (p2p) للنقل بين المشتركين في المعاملة والكتل. يتم توزيع المعاملات عبر الشبكة ، بدءًا من إحدى العقد ، حتى تصل إلى مجموعات النظراء للمنتجين الذين يقومون بتعبئة المعاملات في كتل واستخدام نفس p2p لتوزيع كتل جديدة عبر جميع نقاط الشبكة. أساس معظم شبكات P2P الحديثة هو التعديلات المختلفة لبروتوكول Kademlia. في ما يلي نظرة عامة موجزة جيدة على هذا البروتوكول ، وهنا مقالة تحتوي على قياسات متنوعة على شبكة BitTorrent ، والتي يمكنك من خلالها أن تفهم أن هذا النوع من الشبكات أكثر تعقيدًا وأقل قابلية للتنبؤ به من شبكة خدمة مركزية مضغوطة بشكل ثابت. أيضا ، وهنا مقال حول قياس مختلف مقاييس مثيرة للاهتمام للعقد Ethereum.

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

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

كتلة سلسلة معالجة وتحديث قاعدة بيانات الدولة

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

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

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

تلقي العميل إخطار إدراج المعاملة في blockchain

هذه هي المرحلة الأخيرة من تلقي خدمة blockchain من قبل عميل ، مقارنة مع المراحل الأخرى التي لا يوجد فيها حمل كبير ، ولكن لا يزال عليك التفكير في إمكانية تلقي عميل استجابة بحجم من عقدة (على سبيل المثال ، عقد ذكي يرسل مجموعة من البيانات). في أي حال ، هذه اللحظة هي الأكثر أهمية بالنسبة للشخص الذي طرح السؤال "كم عدد الكرات الثابتة في blockchain الخاص بك؟" ، لأن في هذه اللحظة ، يتم إصلاح وقت تلقي الخدمة.

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

استنتاج

نتيجة لذلك ، من الممكن وصف أنواع العمليات التي يتم تنفيذها على المجموعات الرئيسية وتقسيمها إلى عدة فئات:

1. التحولات التشفير ، وبناء الأدلة
2. الند للند الشبكات ، والمعاملة وكتلة النسخ المتماثل
3. معالجة المعاملات ، وتنفيذ العقود الذكية
4. تطبيق التغييرات في blockchain على قاعدة بيانات الحالة ، وتحديث المعاملة وحظر البيانات
5. طلبات للقراءة فقط إلى قاعدة بيانات الحالة ، API blockchain العقدة ، خدمات الاشتراك

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

عند تطوير وتقييم أداء المجموعات الرئيسية ، سيتعين عليك مراعاة كل هذه النقاط. للقيام بذلك ، تحتاج إلى جمع وتحليل المقاييس في نفس الوقت من العملاء وعقد الشبكة ، والبحث عن العلاقات بينهما ، وتقييم الوقت الذي يتم فيه تقديم الخدمة للعملاء ، ومراعاة جميع الموارد الرئيسية: cpu / memory / network / storage ، وفهم كيفية استخدامها والتأثير على بعضها البعض. كل هذا يجعل من مقارنة سرعات مختلف المجموعات في شكل "كم عدد TPS" مهمة عديمة الجدوى ، نظرًا لوجود عدد كبير من التكوينات والظروف المختلفة. في الأنظمة المركزية الكبيرة ، ومجموعات المئات من الخوادم ، تكون هذه المشكلات معقدة أيضًا وتتطلب أيضًا جمع عدد كبير من المقاييس المختلفة ، ولكن في شبكات الحظر ، نظرًا لشبكات p2p ، والأجهزة الافتراضية التي تعمل بعقود ، والاقتصاد الداخلي ، يكون عدد درجات الحرية أكبر بكثير ، الأمر الذي يجعل الاختبار أكثر. حتى على العديد من الخوادم ، لا يتم عرضه ولا يعرض سوى القيم التقريبية للغاية ، والتي لا ترتبط تقريبًا بالواقع.

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

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