تقدم سلاسل الكتل السريعة تحديات جديدة لإدارة النطاق الترددي وعدالة RPC. نقدم اليوم آلية لتشكيل الوصول إلى RPC باستخدام التزامات التخزين السائل. النظام مباشر عبر ShMonad RPC من FastLane. يستكشف هذا الموضوع الهندسة المعمارية والأساس المنطقي. 🧵
الشبكات عالية الإنتاجية مثل Monad (~ 0.5 ثانية وقت الكتلة ، ~ 1 ثانية نهائية) لا تترك مجالا صغيرا للاختناق التفاعلي. بحلول الوقت الذي تكتشف فيه نقطة نهاية RPC أنها تتعرض لهجوم البريد العشوائي، يكون الضرر قد حدث بالفعل. يجب أن يكون التخفيف استباقيا ومتوافقا مع الحوافز. /2
القيد الرئيسي هو النطاق الترددي. العقد المجاورة للمدقق مقيدة بالموارد وحساسة لزمن الانتقال. إذا تم منح الوصول بدون إذن بشكل عشوائي ، يمكن للعملاء العدائيين مزاحمة المشاركين الصادقين - مما يؤدي إلى تدهور تكاليف تجربة المستخدم والمدقق دون اللجوء إليها. /3
يستفيد حلنا من ShMonad ، وهو رمز تخزين سائل قابل للبرمجة (LST) مع إمكانات الالتزام على السلسلة. يتلقى المستخدمون عنوان URL الخاص ب RPC مقابل الالتزام ب ShMON ب "نهج RPC" على السلسلة. يحكم هذا الالتزام حدود معدل الوصول. /4
يتم تخصيص النطاق الترددي بشكل متناسب: RPS للمستخدم = (ShMON الملتزم به للمستخدم / إجمالي ShMON الملتزم) × RPS_max-global ينتج عن هذا نموذج عرض نطاق ترددي قابل للمشاركة ديناميكيا ومرجح بالحصة دون إدخال محددات معدل مركزية خارج السلسلة. 5/
يتم الالتزام بالحصة لمدة (حاليا 20 كتلة) ، مما يتيح التخزين المؤقت. يقوم الترحيل بشكل متقطع باستطلاعات الرأي ولقطات حالة الالتزام على السلسلة. هذا يمنع استدعاءات EVM في المسار الحرج ويدعم الاستخدام عالي التردد دون زمن انتقال إضافي. 6/
من الناحية التجريبية ، ينتج عن هذا النظام زمن انتقال أقل باستمرار. عبر العديد من جلسات القياس المستقلة ، يعرض ShMonad RPC من FastLane متوسط / متوسط استجابة أقل ~ 20 مللي ثانية من ثاني أسرع مزود ، مع وجود فجوة أكبر مقابل RPCs العامة. 7/
يتم تكديس ShMON الملتزم بسياسة RPC مع المدققين المشاركين في شبكة ترحيل FastLane (حاليا >90٪ من مدققي Monad). هذا يخلق التوافق: يدعم مستهلكو النطاق الترددي نفس المدققين الذين يخدمون حركة المرور الخاصة بهم ، والمدققين لديهم القدرة على التعويض مباشرة عن طريق عقوبات التجاوز. 8/
ولكن لفرض حدود النطاق الترددي بشكل موثوق وبلا ثقة ، نحتاج إلى أكثر من حدود المعدل ... نحن بحاجة إلى إنفاذ يمكن إثباته. في الوقت الحالي ، يتم خنق المستخدمين في التتابع. لكن خارطة الطريق تتضمن أنظمة إثبات على السلسلة تعتمد على دلتا nonce وإيصالات الاستخدام الموقعة. 9/
يمكن للتصميم البسيط مقارنة عدم الحساب بين ارتفاعات الكتلة n و m ، والمائلة (أي "تطبيق رسوم إضافية" وإعطائها للمدقق) الاستخدام الزائد فوق الحد الأقصى RPS. ولكن هناك مشكلة: هذا عرضة لهجمات إطلاق الدفعات بواسطة مرحل مما يجعل txs تبدو متفجرة.
للتخفيف من ذلك، نقدم قناة ثانية: إيصالات الاستخدام غير المتزامنة ذات الطابع الزمني. عند إرسال معاملة ، سيتم البث المتعدد لكل من المدقق و "مصدر إيصال" منفصل. يقوم المصدر بإرجاع كائن موقع إلى المرسل، مختوما زمنيا بما في ذلك بيانات تعريف nonce قبل التنفيذ. يأخذ الحمل الزائد للتتبع والتحقق من المسار الساخن بين المستخدم والمدقق. 11/
تخدم هذه الإيصالات (التي سيتم التوقيع عليها) غرضا مزدوجا: 1. ملاحظات المستخدم: إذا توقفت الإيصالات عن الوصول ، يمكن للعملاء إيقاف حركة المرور طواعية لتجنب الرسوم الزائدة. 2. إثبات على السلسلة: ترسي الإيصالات النشاط الزمني ، وإزالة الغموض عن البريد العشوائي الحقيقي من التجميع الناجم عن التتابع. 12/
يدعم هذا النموذج كلا من EOAs و 4337 userOps (بافتراض الحزم غير المشتركة أو التكامل الرأسي مع مسؤول الدفع الخاص بنا). في الإصدارات المستقبلية، قد نفرض أن يطابق موقع المعاملة حامل البوليصة أو تم إدراجه في القائمة البيضاء أثناء الالتزام بالسياسة. يحدد لاحقا. 13/
هدفنا هو نقل التنفيذ على السلسلة دون التضحية بالأداء. بفضل مساحة الكتلة الوفيرة في Monad والنهاية السريعة ، فإن تقديم إثباتات الدولة والتحقق من الإيصالات وفرض رسوم زائدة أمر قابل للتطبيق على السلسلة ... شيء غير ممكن على الشبكات ذات التكلفة الأعلى. 14/
لا تزال عقوبات التجاوز (المماثلة لتسعير الازدحام) قيد التصميم. نحن ننتظر هيكل سوق الرسوم النهائي لشركة Monad قبل وضع اللمسات الأخيرة على جدول الرسوم الإضافية - لن يكون من المنطقي بالنسبة لنا تصميم الرسوم الزائدة دون معرفة الرسوم الأساسية. 15/
يتم قياس معدل نقل RPC حاليا بشكل إجمالي (txs + eth_call)، ولكن الترقيات المستقبلية ستقوم بتصنيف فئات النطاق الترددي. سيتم توجيه طلبات القراءة من خلال العقد المحسنة إقليميا ، وإزالتها من عنق الزجاجة الناتج عن قيود النطاق الترددي للمدقق. 16/
بالنسبة للتطبيقات الحساسة لزمن الوصول (مثل العقد الكاملة وصناع السوق) ، فإننا ندعم التناظر وتغذية الكتلة المباشرة عبر p2p. بالنسبة للكتل الكاملة، ستكون أولوية الانتشار مرجحة للرهان (LSWQoS): يتلقى المستخدمون الذين لديهم ShMON الملتزم بأعلى الكتل بشكل هامشي في وقت مبكر، مع مراعاة عتبات التضمين. 17/
يمثل هذا خروجا عن RPC التقليدي "أفضل جهد". مع طلبات القراءة إلى RPC، يحدد مبلغ الحصة الملتزم بها عدد الطلبات. بالنسبة للكتل المرسلة من العقد الخاصة بنا، يحدد مبلغ الرهان الملتزم به ترتيب الإرسال. 18/
يعد التحكم في الوصول غير الموثوق به قابلا للتطبيق على سلاسل الإنتاجية العالية إذا تم تصميم الحوافز والإنفاذ وإمكانية الملاحظة من المبادئ الأولى. ShMonad RPC هو تنفيذ مرجعي لتلك الأطروحة. نتطلع إلى التكرار والتدقيق الخارجي. 19/
‏‎6.37‏K