لماذا يصعب قياس أداء Blockchain

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

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

قابلية التوسع مقابل الأداء

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

هذا التمييز مهم: العديد من الأساليب لتحسين الأداء لا تعمل على تحسين قابلية التوسع على الإطلاق، عندما يتم تعريفها بشكل صحيح. أحد الأمثلة البسيطة هو استخدام نظام توقيع رقمي أكثر كفاءة، مثل توقيعات BLS، والتي يبلغ حجمها تقريبًا نصف حجم توقيعات Schnorr أو ECDSA. إذا تحولت Bitcoin من ECDSA إلى BLS، فقد يرتفع عدد المعاملات لكل كتلة بنسبة 20-30٪، مما يؤدي إلى تحسين الأداء بين عشية وضحاها. ولكن يمكننا القيام بذلك مرة واحدة فقط - لا يوجد نظام توقيع أكثر كفاءة في استخدام المساحة للتبديل إليه (يمكن أيضًا تجميع توقيعات BLS لتوفير مساحة أكبر، ولكن هذه خدعة أخرى لمرة واحدة).

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

يساعد فهم التمييز أيضًا على تجنب خطأ الفئة الشائع الموجود في عبارات مثل، "إن Blockchain X قابل للتطوير بدرجة كبيرة، ويمكنه التعامل مع معاملات Y في الثانية!" قد يكون الادعاء الثاني مثيرًا للإعجاب، لكنه أ أداء متري، وليس مقياس قابلية التوسع. لا يتحدث عن القدرة على تحسين الأداء عن طريق إضافة الموارد.

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

الكمون مقابل الإنتاجية

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

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

التحديات في قياس الكمون

يبدو زمن الوصول بسيطًا في البداية: كم من الوقت يستغرق تأكيد المعاملة؟ ولكن هناك دائمًا عدة طرق مختلفة للإجابة على هذا السؤال.

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

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

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

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

الكمون هو توزيع، وليس رقم واحد.

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

مع blockchain، يمكن أن يختلف زمن الوصول للتأكيد لعدد من الأسباب:

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

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

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

لهذه الأسباب، المبدأ التوجيهي الجيد هو:

يجب أن تقدم المطالبات المتعلقة بزمن الوصول توزيعًا (أو رسمًا بيانيًا) لأوقات التأكيد، بدلاً من رقم واحد مثل المتوسط ​​أو الوسيط.

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

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

وحتى إذا كانت لدينا إحصائيات جيدة حول التوزيع الدقيق لزمن الاستجابة، فمن المحتمل أن تختلف بمرور الوقت مع تغير النظام والطلب عليه. كما أنه ليس من الواضح دائمًا كيفية مقارنة توزيعات زمن الوصول بين الأنظمة المتنافسة. على سبيل المثال، لنأخذ في الاعتبار أحد الأنظمة التي تؤكد المعاملات بزمن انتقال موزع بشكل موحد يتراوح بين دقيقة واحدة ودقيقتين (بمتوسط ​​ووسيط 1 ثانية). إذا أكد نظام منافس 2% من المعاملات في دقيقة واحدة بالضبط، و90% أخرى في 95 دقيقة (بمتوسط ​​1 ثانية ومتوسط ​​5 ثانية)، أي نظام هو الأفضل؟ ربما يكون الجواب هو أن بعض التطبيقات تفضل الخيار الأول والبعض الآخر يفضل الخيار الثاني.

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

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

التحديات في قياس الإنتاجية

تبدو الإنتاجية أيضًا بسيطة للوهلة الأولى: ما عدد المعاملات التي يمكن للنظام معالجتها في الثانية؟ تنشأ صعوبتان رئيسيتان: ما هي "المعاملة" على وجه التحديد، وهل نقوم بقياس ما يفعله النظام اليوم أو ما قد يكون قادرا على القيام به؟

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

ليست كل المعاملات متساوية.

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

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

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

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

عامة:

تتطلب مطالبات الإنتاجية شرحًا دقيقًا لعبء عمل المعاملة وعدد المدققين (الكمية والتنفيذ والاتصال بالشبكة). وفي غياب أي معيار واضح، تكفي أعباء العمل التاريخية من شبكة شعبية مثل إيثريوم.

مقايضات زمن الوصول والإنتاجية

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

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

رسوم التحويل

ومن المفهوم أن المستخدمين النهائيين يهتمون أكثر بالمفاضلة بين زمن الوصول ووقت الاستجابة الرسوم، وليس الكمون والإنتاجية. ليس لدى المستخدمين سبب مباشر للاهتمام بالإنتاجية على الإطلاق، كل ما في الأمر هو أنه يمكنهم تأكيد المعاملات بسرعة بأقل رسوم ممكنة (مع اهتمام بعض المستخدمين أكثر بالرسوم والبعض الآخر أكثر بزمن الوصول). على مستوى عال، تتأثر الرسوم بعوامل متعددة:

1. ما حجم الطلب في السوق لإجراء المعاملات؟
2. ما هي الإنتاجية الإجمالية التي يحققها النظام؟
3. ما هو إجمالي الإيرادات التي يوفرها النظام للمدققين أو القائمين بالتعدين؟
4. ما مقدار هذه الإيرادات التي تعتمد على رسوم المعاملات مقابل المكافآت التضخمية؟

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

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

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

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

وفي الختام

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

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