يتم الآن تشغيل شبكة اختبار Polygon Avail. عندما يبدأ المستخدمون في دمج Avail في تصميمات السلسلة الخاصة بهم ، فإن السؤال الذي يطرح نفسه غالبًا هو "كم عدد المعاملات التي يمكن أن تتم معالجتها؟"
هذه هي المقالة الأولى في سلسلة من المقالات التي ستتناول الأداء الحالي لـ Polygon Avail ، بالإضافة إلى قدرتها على التوسع على المدى القريب والبعيد. لقد نشرنا بالفعل مقالات توضح كيفية تطبيق Avail تقنيًا. للبدء ، سنقارن إنتاجية Ethereum مع Avail بالنظر إلى البنية الحالية لكلتا السلسلتين.
Polygon Avail مقابل Ethereum
يمكن أن تستوعب كتل Ethereum بحد أقصى 1.875 ميجابايت ، مع وقت كتلة يصل إلى 13 ثانية تقريبًا. ومع ذلك ، لا يتم ملء كتل Ethereum عادة. تصل كل كتلة تقريبًا إلى حد الغاز قبل الوصول إلى حد البيانات ، لأن كلاً من التنفيذ والتسوية يكلفان الغاز. نتيجة لذلك ، فإن كمية البيانات المخزنة لكل كتلة متغيرة.
تعد الحاجة إلى الجمع بين التنفيذ والتسوية وتوافر البيانات في نفس الكتلة هي المشكلة الأساسية في بنيات blockchain المتجانسة. بدأت مجموعات Layer-2 (L2) حركة blockchain المعيارية من خلال السماح بالتنفيذ على سلسلة منفصلة ، مع كتل مخصصة فقط للتنفيذ. يأخذ Polygon Avail التصميم المعياري خطوة أخرى إلى الأمام عن طريق فصل توافر البيانات أيضًا ، والسماح بسلسلة بها كتل مخصصة فقط لتوافر البيانات.
حاليًا ، يمتلك Avail وقت حظر يبلغ 20 ثانية مع قدرة كل كتلة على الاحتفاظ بحوالي 2 ميغابايت من البيانات. بافتراض متوسط حجم معاملة يبلغ 250 بايت ، يمكن أن تحتوي كل كتلة Polygon Avail اليوم على حوالي 8400 معاملة (420 معاملة في الثانية).
الأهم من ذلك ، يمكن أن يملأ Avail الكتل باستمرار حتى حد التخزين ، ويزيد الحجم حسب الحاجة. هناك العديد من الروافع التي يمكننا سحبها - العديد منها بسرعة كبيرة - للحصول على هذا الرقم فوق 500000 معاملة لكل كتلة (25000 معاملة في الثانية) حسب الحاجة.
هل يمكننا زيادة الإنتاجية؟
لزيادة الإنتاجية (على وجه التحديد ، المعاملات في الثانية) ، يحتاج مهندسو السلسلة إما إلى زيادة حجم الكتلة ، أو تقليل وقت الكتلة.
لإضافتها إلى السلسلة ، يجب على كل كتلة إنتاج الالتزامات ، وبناء البراهين ، ونشرها ، وجعل جميع العقد الأخرى تتحقق من البراهين. ستستغرق هذه الخطوات دائمًا وقتًا ، وستوفر قيودًا على أوقات الحظر.
نتيجة لذلك ، لا يمكننا فقط تقليل وقت الحظر إلى ما يشبه ثانية واحدة. لن يكون هناك وقت كافٍ تقريبًا لإنتاج الالتزامات ، وإنشاء البراهين ، ونشر هذه القطع لجميع المشاركين عبر الشبكة بأكملها. في وقت الكتلة النظري لمدة ثانية واحدة ، حتى لو كان كل مشارك في الشبكة يشغل أقوى الأجهزة التي يمكن أن تنتج التزامات وإثباتات على الفور ، فإن العقبة هي نشر البيانات. الشبكة غير قادرة على توصيل الكتلة لجميع العقد الكاملة بسرعة كافية بسبب قيود سرعة الإنترنت. لذلك يجب أن نتأكد من أن وقت الكتلة مرتفع بما يكفي للسماح بتوزيع البيانات عبر الشبكة بعد الوصول إلى توافق في الآراء.
بدلاً من ذلك ، ستأتي زيادة الإنتاجية من خلال زيادة حجم الكتلة - زيادة في كمية البيانات التي يمكننا تضمينها في كل كتلة.
العمارة الحالية: إضافة كتلة إلى السلسلة
للبدء ، دعنا نلقي نظرة على ما هو مطلوب لإضافة كتلة إلى السلسلة. تتطلب إضافة كل كتلة إلى السلسلة ثلاث خطوات رئيسية. الوقت المستغرق لإنتاج كتلة ونشر تلك الكتلة والتحقق من الكتلة المذكورة.
1. إنتاج البلوك
تتضمن هذه الخطوة الوقت الذي يستغرقه جمع معاملات Avail وطلبها ، وبناء الالتزامات ، وتوسيع (محو رمز) مصفوفة البيانات.
يقيس إنتاج الكتلة الوقت اللازم لإنتاج كتلة لأنه يستغرق دائمًا بعض الوقت على الأقل. نتيجة لذلك ، يجب ألا ننظر فقط في أفضل وقت ، ولكن في الوقت المتوسط والأسوأ بالنسبة للآلات المختلفة.
إن أضعف آلة يمكن أن تشارك في إنتاج كتل جديدة هي تلك التي تصل سعتها إلى أقصى حد في متوسط وقت الحالة. ستنتهي حتمًا جميع الآلات الأبطأ بالتخلف ، لأنها غير قادرة على اللحاق بالآلات الأسرع.
2. تأخير الانتشار
تأخير الانتشار هو مقياس للوقت الذي يستغرقه نشر الكتل من المنتجين إلى المدققين وشبكة الند للند.
حاليًا ، يحتوي Avail على كتل بحجم 2 ميغابايت. يمكن نشر كتل بهذا الحجم ضمن قيود الوقت الحالية البالغة 20 ثانية. تجعل أحجام الكتل الكبيرة الانتشار أكثر صعوبة.
إذا أردنا زيادة Polygon Avail لدعم كتل 128 ميجابايت ، على سبيل المثال ، فمن المحتمل أن يكون الحساب قادرًا على التوسع (~ 7 ثوانٍ). ومع ذلك ، فإن عنق الزجاجة يصبح مقدار الوقت الذي يستغرقه إرسال هذه الكتل وتنزيلها عبر الشبكة.
من المحتمل أن يكون إرسال كتل بحجم 128 ميغابايت عبر العالم عبر شبكة نظير إلى نظير في 5 ثوانٍ هو الحد الأقصى لما يمكن إنجازه في هذا الوقت.
الحد 128 ميجابايت ليس له علاقة بتوافر البيانات أو مخطط الالتزام الخاص بنا ، ولكنه بالأحرى مسألة قيود النطاق الترددي للاتصال.
توفر لنا هذه الحاجة لحساب تأخير الانتشار حدًا لحجم الكتلة النظري الحالي لـ Polygon Avail.
3. منع التحقق
بمجرد النشر ، لا يثق المدققون المشاركون في الكتلة المقدمة لهم من قبل مقدم الكتلة - فهم بحاجة إلى التحقق من أن الكتل المنتجة بالفعل تقول منتجو البيانات إنهم يفعلون ذلك.
تقدم هذه الخطوات الثلاث القليل من التوتر مع بعضها البعض. يمكننا أن نجعل جميع أجهزة التحقق من الصحة القوية متصلة بإحكام من خلال شبكات ممتازة في نفس مركز البيانات - مما يقلل من أوقات الإنتاج والتحقق ويسمح لنا بنشر المزيد من البيانات على نطاق واسع. ولكن لأننا نريد أيضًا شبكة لا مركزية ومتنوعة تضم أنواعًا مختلفة من المشاركين ، فهذا ليس نهجًا مرغوبًا فيه.
بدلاً من ذلك ، ستأتي التحسينات في الإنتاجية من خلال فهم الخطوات المطلوبة لإضافة كتلة إلى سلسلة Avail ، والتي يمكن تحسينها.
في الوقت الحالي ، يأخذ المدققون الذين يستخدمون Polygon Avail الكتلة بأكملها ويعيدون إنتاج جميع الالتزامات التي تم إنشاؤها بواسطة مقدم الاقتراح ، من أجل التحقق من الكتلة. يُترجم هذا إلى قيام منتجي الكتل وجميع المدققين بتنفيذ كل خطوة من الرسم أعلاه.
إعادة إنشاء الكتلة بالكامل بواسطة كل مدقق هو الإعداد الافتراضي في سلاسل الكتل المتجانسة. ومع ذلك ، فهو ليس ضروريًا في سلسلة مثل Avail ، حيث لا يتم تنفيذ المعاملات. نتيجةً لذلك ، تتمثل إحدى الطرق التي يمكننا من خلالها تحسين Avail في السماح للمدققين بالوصول إلى ضماناتهم الخاصة لتوافر البيانات من خلال أخذ العينات ، بدلاً من منع الاستجمام. هذا يضع متطلبات موارد أقل على المدققين مما لو طُلب منهم إعادة إنتاج جميع الالتزامات.