هناك العديد من المقاييس المتعلقة بالمنطق ونوعية blockchain. أنها تساعد في تحديد الاختناقات في التعليمات البرمجية وإيجاد المشاكل المنطقية والأمثلية في الإجماع والخوارزميات النهائية في المجموعات الرئيسية. يتطلب أي تطوير للأنظمة الموزعة ، بما في ذلك blockchains ، تحليل عمل العديد من العقد دفعة واحدة. أنها تسمح لفريق المشروع بمراقبة حالة الشبكة blockchain بأكملها ، ومشاهدة مشاكل العقد الفردية ، واكتشاف حدوث هجمات حجب الخدمة على الشبكة وأكثر من ذلك بكثير. دعونا ننظر إلى أهمها. دعونا الغوص في.
"المعاملات في الثانية"
في حالة الأنظمة الموزعة ، يعتبر TPS رقمًا مزاجيًا وغامضًا جدًا ، ولا يعكس دائمًا الجودة الحقيقية للخدمة المقدمة للمستخدمين. جاءت قياسات TPS إلينا من قواعد البيانات الموزعة. TPS في قواعد البيانات هي بعض المعايير للمعاملات الاختبار أو مجموعاتها (بعض INSERT ، بعض UPDATE ، الكثير من الحذف على خلفية ثابت SELECT) لتكوين نظام المجموعة الثابت تلوينها أو حتى على نفس الجهاز. عادة ما تقدم هذه المقاييس تقديرات تقريبية فقط لأداء قواعد البيانات الموزعة أو مجموعات الحظر ، حيث يمكن أن يختلف وقت معالجة المعاملات بشكل كبير اعتمادًا على العديد من العوامل.
لا تلتزم قواعد البيانات الموجهة نحو الاتساق (انظر "نظرية CAP") بالمعاملة حتى تتلقى عددًا كافيًا من التأكيدات من العقد الأخرى وهذا بطيء. وتعتبر قواعد البيانات الموجهة للتوفر معاملة تمت كتابتها ببساطة على القرص بنجاح. يقومون على الفور بتزويد العميل بالبيانات المحدثة وهو سريع جدًا (على الرغم من أنه قد يتم التراجع عن هذه المعاملة في المستقبل). وأيضًا ، إذا كانت المعاملات المستخدمة في المعيار تقوم بتحديث خلية واحدة فقط تحتوي على بيانات ، فمن الواضح أن TPS ستكون أعلى من الحالات التي يمكن أن تؤثر فيها المعاملات على العديد من الخلايا وتحظر بعضها البعض. يتم تنفيذ خوارزميات العمل مع هذه الأقفال في كل قاعدة بيانات بطريقتها الخاصة - لهذا السبب لا نرى "مسابقات TPS" بين Oracle و MSSQL و PostgreSQL من ناحية و MongoDB و Redis و Tarantool من ناحية أخرى - إنها آليات داخلية مختلفة ومهام مختلفة .
في رأيي ، يعني "قياس TPS" من blockchain أخذ مجموعة كاملة من قياسات أدائها:
- في ظروف قابلة للتكرار
- مع ما يقرب من الواقع عدد من المدققين كتلة
- باستخدام أنواع مختلفة من المعاملات:
- نموذجي للكتلة المدروسة (على سبيل المثال ، نقل () العملة المشفرة الرئيسية)
- تحميل نظام التخزين الفرعي (كمية كبيرة من التغييرات من كل معاملة)
- عرض النطاق الترددي للتحميل (حجم المعاملة الكبير)
- تحميل وحدة المعالجة المركزية (في حالة عمليات تحويل التشفير أو الحسابات الضخمة)
للحديث عن "المعاملات في الثانية" العزيزة ، تحتاج إلى وصف جميع الشروط (عدد المدققين ، التوزيع الجغرافي ، مستوى packetloss ، إلخ) ووصف منطق القياس. في عمليات الحظر ، لا يعني مجرد نقل معاملة إلى قاعدة بيانات داخلية قبولها بتوافق الآراء. على سبيل المثال ، في حالة Proof-of-Work ، من الناحية الإحصائية ، لا تكتمل المعاملات أبدًا على الإطلاق ، وإذا تم تضمين معاملة في كتلة على جهاز ما ، فإن هذا لا يعني أنه سيتم قبولها من قبل الشبكة بالكامل (على سبيل المثال ، في حالة فوز مفترق آخر).
إذا كان لدى blockchain خوارزمية إضافية لضمان نهائية المعاملات (EOS ، Ethereum 2.0 ، Polkadot parachains التي تستخدم الإجماع مع نهائي GRANDPA) ، فيمكن اعتبار وقت المعالجة هو الفجوة بين العقدة "شهدت" المعاملة والكتلة النهائية التالية حيث كانت هذه المعاملة المدرجة. هكذا ، أقرب إلى الواقع ، نادراً ما يُرى "TPS" في وعود المشروع. وبطبيعة الحال ، فهي أقل من تلك الموضحة في الورقة البيضاء ، لكنها مفيدة قدر الإمكان.
لذلك أنا أحذرك مرة أخرى ، يمكن تضمين الكثير من المعاني المختلفة في مصطلح "TPS". كن متشككا واسأل عن التفاصيل.
مقاييس Blockchain الخاصة
tps المحلية
عدد المعاملات التي تتم معالجتها بواسطة العقدة ووقت الحد الأقصى / المتوسط / دقيقة لمعالجتها على العقدة المحلية مناسب جدًا للقياس ، حيث إن الوظائف التي تؤدي هذه العملية عادةً ما يتم تخصيصها بشكل صريح في الكود. يمكنك ببساطة قياس مدة عمل المعاملة من خلال تحديث قاعدة بيانات الحالة. قد لا يتم قبول هذه المعاملات بعد بتوافق الآراء ، لكنها مرت بالفعل على التحقق من الصحة ، ويمكن للعقدة بالفعل أن تقدم للعميل بيانات محدثة (على افتراض أن سلسلة الشوكة لا تظهر).
هذا المقياس ليس صادقًا جدًا: إذا تم اختيار مفترق آخر من السلسلة باعتباره العنصر الرئيسي ، فيجب أيضًا استعادة الإحصاءات المتعلقة بالمعاملات التي تم التراجع عنها. ولكن للاختبار ، يمكن دائمًا إهمال ذلك.
في كثير من الأحيان ، هذا هو الرقم المكتوب في تقارير موجزة: "حصلت كتلة المفاتيح لدينا على 8000 نقطة في الثانية بالأمس" ، نظرًا لأنه من السهل قياسها - عقدة واحدة فقط قيد التشغيل وكتابة نصية تحملها كافية. في هذه الحالة ، لا يوجد أي تأخير في الشبكة ، مما يؤدي إلى إبطاء الوصول إلى توافق في الشبكة ، ويظهر المقياس أداء قاعدة بيانات الحالة دون تأثير الشبكة. هذا الرقم ليس هو النطاق الترددي الحقيقي لشبكة blockchain ، ولكنه يوضح الحد الذي سيسعى إليه إذا كان الإجماع والشبكة بسرعة كافية.
نتيجة أي معاملة blockchain العديد من التحديثات الذرية للتخزين. على سبيل المثال ، معاملة الدفع في Bitcoin هي إزالة العديد من UTXOs القديمة (حذف) وإضافة العديد من UTXOs الجديدة (insert) ، وفي Ethereum ، يتم تنفيذ رمز عقد ذكي قصير ، ومرة أخرى ، تحديث العديد من أزواج القيمة الرئيسية. يمكن أن يكون عدد عمليات الكتابة "الذرية" مقياسًا ممتازًا يسمح لك بتحديد الاختناقات في نظام التخزين الفرعي ومنطق المعاملة الداخلي.
أيضا ، يمكن تنفيذ العقد blockchain بعدة لغات البرمجة - وهذا هو أكثر موثوقية. يجب أن يؤخذ ذلك في الاعتبار عند تقييم أداء الشبكة ، على سبيل المثال ، توجد عقدة Ethereum في تطبيقات على Rust و Go. وتسعى وحدات الحظر الأخرى أيضًا إلى الحصول على تطبيقات إضافية من أجل الموثوقية.
كمية الكتل المنتجة المحلية
يوضح هذا المقياس البسيط أي من المدققين عدد الكتل المنتجة. إنه منتج توافق الآراء ويمكن اعتباره المنتج الرئيسي لتقييم "الفائدة" لشبكة من المدققين الفرديين.
كسب المال على كل كتلة ، يهتم المدققون بالتشغيل المستقر وسلامة أجهزتهم. يساعد هذا الرقم في تحديد أي من المدققين المرشحين هو الأكثر مؤهلاً ومحميًا ومستعدًا للعمل على شبكة عامة ذات أصول مستخدمين حقيقيين. يمكن التحقق من قيمة المقياس بشكل عام عن طريق تنزيل blockchain ببساطة وحساب من أنتج عدد الكتل.
النهائي والبلوك النهائي لا رجعة فيه
في الشبكات ذات النهاية النهائية (EOS ، Ethereum ، Tendermint ، Polkadot ، إلخ) ، بالإضافة إلى الإجماع الأساسي السريع (حيث يكفي توقيع مدقق واحد لكل كتلة) ، تتطلب بعض الكتل التنسيق من قبل مجموعة من المدققين. تعتبر هذه الكتل نهائية وتعتبر خوارزمية مجموعة التوقيع نهائية. تتمثل مهمة النهاية في التأكد من أن جميع المعاملات المضمنة في blockchain قبل الكتلة النهائية لا يتم ضخها أبدًا ولا يتم استبدالها بشوكة أخرى من السلسلة. هذه هي الحماية ضد هجمات الإنفاق المزدوج في شبكات إثبات الحصة ، وطريقة للإرجاع بسرعة في غضون ثوانٍ إلى تأكيد موثوق بمعاملة عملة مشفرة للمستخدم.
من وجهة نظر مستخدم blockchain ، لا تكتمل المعاملة في الوقت الحالي عندما يتم قبولها من قبل العقدة ، ولكن عندما تظهر كتلة تضع اللمسات الأخيرة على السلسلة التي توجد بها المعاملة. لوضع اللمسات الأخيرة على كتلة ، يجب أن يتلقى المدققون هذه الكتلة على شبكة p2p ، وتبادل التواقيع مع بعضهم البعض. يتم هنا التحقق من السرعة الحقيقية لـ blockchain ، لأن المستخدم مهتم بلحظة الانتهاء من الكتلة مع معاملتها ، وليس فقط قبولها وكتابتها على قرص إحدى العقد.
تختلف خوارزميات النهاية أيضًا ، وتتقاطع ، وتجمع مع الإجماع الرئيسي (لقراءة: Casper in Ethereum ، Last Blocks لا رجعة فيه في EOS ، GRANDPA في Parity Polkadot وتعديلاتها ، على سبيل المثال MixBytes RANDPA).
بالنسبة للشبكات التي لا يتم فيها الانتهاء من كل كتلة ، يكون المقياس المفيد هو تأخر آخر كتلة نهائية من الكتلة الأخيرة الحالية. يوضح هذا الرقم كيف يتخلف المدققون عنهم ، متفقين على السلسلة الصحيحة. إذا كانت الفجوة كبيرة ، فإن خوارزمية الانتهاء تتطلب تحليلًا إضافيًا وتحسينًا.
مقاييس blockchain الأخرى
تعتمد بقية المقاييس عادةً بشكل كبير على نوع الإجماع ، لذلك ليس من الصواب تمثيلها بين المقاييس الرئيسية. من بين هذه المعلمات ، على سبيل المثال: عدد شوكات السلسلة ، طولها في القطع ، شغل القطع مع المعاملات ، إلخ. يمكن استخدامها لتحديد مواقف فصل الشبكة أو ترجمة مشاكل مدقق معين بسرعة.
طبقة P2P
من الأهمية بمكان أن نتذكر الأساس الوسيط لشبكات blockchain - النظام الفرعي من نظير إلى نظير. هي التي تقدم تأخيرات غامضة في تسليم الكتل والمعاملات بين المدققين. عندما يكون عدد المدققين صغيرًا ، يتم ترجمته ، وتكون قوائم الأقران مشفرة ، وكل شيء يعمل بشكل جيد وبسرعة. لكن الأمر يستحق إضافة أجهزة التحقق ، وتوزيع العقد جغرافيا ومحاكاة packetloss ، حيث تظهر حالات فشل كبيرة في "tps".
على سبيل المثال ، عند اختبار إجماع EOS باستخدام خوارزمية النهاية النهائية الاختيارية ، فإن زيادة عدد أجهزة التحقق حتى 80-100 آلات متباعدة عبر أربع قارات لم تؤثر بشكل كبير على سرعة الوصول إلى النهاية. في الوقت نفسه ، أثرت الزيادة في packetloss بشدة على تأخر النهاية ، مما يشير إلى الحاجة إلى تكوين إضافي لطبقة p2p لمزيد من المقاومة لفقدان حزم الشبكة ، وليس الكمون الكبير. لسوء الحظ ، هناك الكثير من الإعدادات والعوامل المختلفة ، وبالتالي ، فإن المقاييس فقط تسمح لنا بفهم العدد الفعال من أجهزة التحقق التي توفر سرعة مريحة إلى حد ما من blockchain.
يمكن فهم النظام الفرعي p2p للجهاز من الوثائق ، على سبيل المثال ، على libp2p أو الوثائق الموجودة على بروتوكول Kademlia أو BitTorrent .
المقاييس المهمة لـ p2p هي:
- حركة المرور الصادرة
- عدد الاتصالات الناجحة / غير الناجحة مع الزملاء الآخرين
- عدد المرات التي تم فيها إرجاع بيانات القطعة المخزنة مؤقتًا مسبقًا ، وعدد المرات التي كان من الضروري إعادة توجيه الطلب إليها بشكل أكبر بحثًا عن القطعة المطلوبة (التماثلية لمضاعفات عدد مرات قراءة / أخطاء التخزين المؤقت)
على سبيل المثال ، يعني عدد كبير من الأخطاء عند الوصول إلى البيانات أن عددًا صغيرًا فقط من العقد يحتوي على البيانات المطلوبة ، وليس لديهم الوقت لتوزيعها على الجميع ، وسيسمح لك مقدار حركة مرور p2p المستلمة / المقدمة بتأسيس عقدة لديها مشاكل في تكوين الشبكة أو القناة.
مقاييس نظام العقدة Blockchain
يتم وصف مقاييس النظام القياسية للعقد blockchain في عدد كبير من المصادر ، لذلك سوف أصفها بإيجاز. يتمثل دورهم في المساعدة في البحث عن الاختناقات والأخطاء الموجودة في جميع أجزاء التعليمات البرمجية ، والتي توضح أكثر النظم الفرعية للعُقد التي يتم تحميلها وما هي المهام.
وحدة المعالجة المركزية
يتحدثون عن عدد الحسابات التي يؤديها المعالج. إذا كان حمل وحدة المعالجة المركزية مرتفعًا ، فإن العقدة تحسب شيئًا ما ، باستخدام المنطق أو FPU بنشاط (لا تستخدم تقريبًا في بلوكينشنز). في عمليات الحظر ، يمكن أن يكون هذا ، على سبيل المثال ، بسبب حقيقة أن العقدة تتحقق من التوقيعات الإلكترونية ، أو تعالج المعاملات باستخدام تشفير كبير ، أو تقوم بإجراء عمليات حسابية معقدة.
يمكن "تقطيع" وحدة المعالجة المركزية إلى عدة مقاييس أخرى مفيدة لفهم أجزاء الكود الأكثر تكلفة. على سبيل المثال ، النظام هو رمز kernel ، المستخدم هو عمليات المستخدم ، io ينتظر الإدخال / الإخراج من الأجهزة الخارجية البطيئة (القرص / الشبكة) ، إلخ. هنا مقالة جيدة ذات صلة.
ذاكرة
تستخدم البلوكات الحديثة قواعد البيانات ذات القيمة الرئيسية (LevelDB ، RocksDB) ، والتي تحتفظ باستمرار بالبيانات الساخنة في الذاكرة. كما هو الحال مع أي خدمات محملة ، تكون تسريبات الذاكرة ممكنة دائمًا نتيجة للأخطاء أو الهجمات المستهدفة على عقدة العقدة. إذا زاد استهلاك عقدة الذاكرة أو زاد بشكل حاد ، فغالبًا ما يكون السبب في ذلك هو زيادة عدد المفاتيح في قاعدة بيانات الحالة أو قوائم انتظار المعاملات الكبيرة أو زيادة عدد الرسائل بين الأنظمة الفرعية المختلفة للعقدة. قد يشير التحميل الزائد للذاكرة إلى زيادة محتملة في حدود البيانات في الكتل أو الحد الأقصى لتعقيد المعاملة.
بالنسبة إلى العقد الكاملة ، وهي https://habrastorage.org/webt/qa/sn/m5/qasnm5bougkjuagneevjkpg9x0w.png التي تتوافق مع عملاء الشبكة ، تعد مقاييس ذاكرة التخزين المؤقت للملفات مهمة أيضًا. عملاء الوصول إلى أجزاء مختلفة من قاعدة بيانات الدولة وسجل المعاملات. يؤدي هذا إلى زيادة عدد الكتل القديمة من القرص ، مما يؤدي إلى تخطي الكتل الجديدة ، مما يؤدي بدوره إلى إبطاء الاستجابة للعميل.
شبكة
تتمثل مقاييس الشبكة الداخلية الرئيسية في مقدار حركة المرور بالبايت وعدد حزم الشبكة المرسلة والمستلمة لكل من البروتوكولات ونسبة فقد الحزمة. في القيود ، غالبا ما لا تحظى هذه المقاييس باهتمام كبير ، لأن لا تقوم بلوكتشينز بمعالجة المعاملات بسرعة 1 جيجابت / ثانية.
هناك مشاريع blockchain تسمح للمستخدمين بمشاركة wifi الخاصة بهم أو تقديم خدمات لتخزين ونقل الملفات أو الرسائل. عند اختبار هذه الشبكات ، تصبح كمية ونوعية حركة المرور من خلال واجهة الشبكة مقاييس مهمة للغاية ، حيث تؤثر قناة الشبكة المزدحمة على جميع الخدمات الأخرى على الجهاز ، دون استثناء.
تخزين
يعد النظام الفرعي للقرص هو أبطأ مكون في أي خدمة وغالبًا ما يكون سبب مشكلات خطيرة في الأداء. تسجيل مفرط ، نسخة احتياطية غير متوقعة ، نمط قراءة / كتابة غير مريح ، وحدة تخزين كبيرة الحجم بكتل سلسلة - كل هذا يمكن أن يؤدي إلى تباطؤ كبير في تشغيل العقدة أو إلى متطلبات مفرطة بشكل خطير للأجهزة.
من الناحية الفنية ، يمكن اعتبار سجل المعاملات بمثابة WAL ( WAL ) لقاعدة بيانات الحالة ، وبالتالي فإن مقاييس التخزين هذه مهمة تتيح لك البحث عن الاختناقات في آليات قواعد البيانات الحديثة ذات القيمة الأساسية. هذه هي عدد IOPS للقراءة / الكتابة ، زمن الوصول الأقصى / الحد الأقصى / المتوسط والعديد من المقاييس الأخرى التي تساعد على تحسين عمليات القرص.
استنتاج
لذلك ، درسنا عدة مجموعات من المقاييس التي يمكن أن توفر معلومات قيمة للغاية حول تشغيل شبكة blockchain وإمكانيات تحسينها. لتلخيص ، يمكنك جمعها في ثلاث مجموعات:
- القياسات blockchain من العقد:
عدد الكتل المنتجة وعدد المعاملات التي تمت معالجتها ووقت معالجتها ووقت الانتهاء منها ، إلخ. - مقاييس p2p للنظام الفرعي:
عدد طلبات الدخول / الخطأ ، وعدد الزملاء النشطين ، وحجم وهيكل حركة مرور P2P ، إلخ. - مقاييس نظام العقد:
وحدة المعالجة المركزية ، الذاكرة ، التخزين ، الشبكة ، إلخ.
كل مجموعة من المجموعات مهمة بطريقتها الخاصة ، لأنه في كل من النظم الفرعية قد يكون هناك أخطاء تقيد تشغيل المكونات الأخرى ، ويمكن أن يؤدي تباطؤ عدد صغير من أجهزة التحقق إلى تأثير خطير على الشبكة بالكامل. أيضًا ، تنشأ الأخطاء الأكثر صعوبة في خوارزميات التوافق والنهائية فقط مع تدفق كبير للمعاملات أو تغييرات في معلمات الإجماع. يتطلب تحليلهم ظروف اختبار قابلة للتكرار وسيناريوهات تحميل معقدة.
دائمًا ما يكون تطوير المجموعات الرئيسية هو تزامن العديد من الآلات والبرامج النصية لوضع التكوينات والتشغيل المنسق للعقد والمعايير وخادم لجمع المقاييس والسجلات من جميع الأجهزة. لذلك ، عند تطوير blockchain الخاص بك ، فكر في استئجار devoop مؤهل - سيوفر دعمًا لا يقدر بثمن لفريق التطوير. حظا سعيدا