إعادة إرسال العنوان الأصلي: آليات رسوم معاملات Solana وEthereum: مقترحات لتحسين TFM الخاصة بـ Solana

شكرًا لأندرو فيتزجيرالد ، وهارش باتل ، وجون شاربونو ، وكيفن جالر ، ولانري إيج ، وميرت ممتاز، وبراناف جاريميدي ، وريان تشيرن ، وتاو تشو ، وتارون شيترا على التعليقات والمراجعة.

مقدمة العملة

Eclipse هو أول SVM L2 لـ Ethereum. نحن متحمسون بشكل لا يصدق لجلب قوة SVM الحالية إلى عدد أكبر من المستخدمين، لكننا ملتزمون أيضًا بدفع البحث والتطوير المستمر حول SVM نفسه. نحن نركز على ضمان أن يؤدي تطوير Eclipse إلى إرجاع القيمة بلا شك إلى جميع سلاسل SVM، وخاصة Solana.

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

بشكل عام، تحدد آلية TFM ما يلي:

1. المعاملات التي يتم تضمينها في كتلة معينة،
2. الرسوم التي تدفعها معاملة معينة، و
3. كيف (ولمن) يتم توزيع رسوم المعاملات المتراكمة.

في النهاية، تهدف هذه المقالة إلى الجمع بين ثروة أبحاث TFM المتمحورة حول الإيثريوم وهندسة سولانا المبتكرة.

نظرة عامة على Solana وEthereum TFMs الحالية

سولانا مقابل أساسيات الإيثريوم

سنبدأ بإلقاء نظرة عامة على TFM الخاصة بـ Solana ونقارنها بـ Ethereum. سيؤدي ذلك إلى وضع سياق أفضل للمقترحات ذات الصلة حتى نتمكن من العمل على تعديل وتحسين آلية تيسير التجارة. للمبتدئين:

الرسوم الأساسية لـ Solana هي 5000 لامبورت (0.000005 سول) لكل توقيع، ومعظم المعاملات لها توقيع واحد. ولا يأخذ في الاعتبار الموارد الحسابية الأوسع للمعاملة (كما تم قياسها بوحدات العملة).

الرسوم الأساسية لـ Solana Tx = (5000 لامبورت) × (عدد التوقيعات في تكساس)

تختلف آلية الرسوم الأساسية لـ Ethereum بطريقتين رئيسيتين:

1. ديناميكي - الرسوم الأساسية للإيثريوم (كما تم قياسها بـ gwei لكل وحدة غاز) تطفو على أساس الطلب المتزايد في السوق.
2. المزيد من الرسوم التفصيلية لكل وحدة حسابية - رسوم Ethereum لكل معاملة أساسية خطية في كمية الغاز المستهلكة.

لذا فإن الرسوم الأساسية لكل معاملة في Ethereum هي:

الرسوم الأساسية لـ Ethereum Tx = (سعر الغاز السائد في gwei) x (الغاز المستخدم في tx)

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

1. SetComputeUnitLimit - يمكن للمعاملات تعيين الحد الأقصى من وحدات CU المسموح لها باستهلاكها (بحد أقصى 1.4 مليون وحدة CU لكل معاملة). عند التنفيذ، يمكن أن تستخدم المعاملة ما يصل إلى حد CU المطلوب. إذا لم يتم توفير تعليمات SetComputeUnitLimit، فسيتم حساب حد CU الخاص بالمعاملة على أنه (# من التعليمات في المعاملة) x (200k CUs).
2. SetComputeUnitPrice - # من المصابيح الصغيرة لكل وحدة مطلوبة أن تعرض المعاملة الدفع مقابل رسوم الأولوية الخاصة بها.

وضعهم معا:

رسوم أولوية Tx = (حد CU) × (سعر CU)

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

حرق الرسوم مقابل مكافآت المدقق

في حين أن حافز المدققين لتحديد أولويات المعاملات ذات الرسوم المرتفعة يقع خارج نطاق الإجماع، إلا أنه يتم فرضه بالإجماع على أن كلاً من الرسوم الأساسية ورسوم الأولوية يتم حرقها/إرسالها بنسبة 50/50 إلى القائد (منتج الكتلة الحالي) في Solana:

1. الرسوم الأساسية — إلزامية لإدراج الكتلة. سيتم رفض المعاملات التي تفتقر إلى الرسوم الأساسية المطلوبة.
2. رسوم الأولوية — ليست إلزامية لإدراج الكتلة. يُستخدم لتحديد أولويات المعاملات اختياريًا التي ترغب في زيادة احتمالية التضمين السريع.

لا يمكن للمستخدم تجنب دفع الرسوم الأساسية، ولكن يمكن للمرء تجنب رسوم الأولوية والإشارة إلى رغبته في الحصول على الأولوية بطريقة أخرى. لقد رأينا هذا بالفعل في الممارسة العملية - تدفع مزادات Jito-Solana 100% (أقل رسومًا) للقائد خارج النطاق. يقدم SIMD-0096 حلاً بسيطًا لهذه المشكلة، حيث يكافئ المدقق بنسبة 100% من رسوم الأولوية.

التحويل المباشر*: يتم التنسيق عبر مزادات MEV-Boost / Jito-Solana

الأهم من ذلك، أن مدققي Solana يدلون بأصواتهم لكل كتلة ذات معاملات على السلسلة. يدفعون الرسوم الأساسية لكل من هذه المعاملات.

حققت Solana أعلى مستوياتها على الإطلاق لرسوم الشبكة مؤخرًا ، مدفوعة بزيادة حادة في رسوم الأولوية. يتم عرض تقسيمات الرسوم الأخيرة أدناه:

المصدر: سولانا كومباس

Ethereum Block Builder مقابل Solana جدولة

من الأسهل عمومًا فهم عملية إنتاج كتلة الإيثريوم، لذا سنبدأ من هنا. جميع المدققين تقريبًا (ويعرف أيضًا باسم المقترحون) الاستعانة بمصادر خارجية لإنتاج الكتل لمنشئين خارج البروتوكول عبر MEV-Boost. يقوم المنشئون بإنشاء كتل كل 12 ثانية (وقت فتحة Ethereum) وتمرير هذه الكتل بأكملها إلى مقدم العرض (عبر التتابع)، الذي يختار الكتلة ذات القيمة الأعلى.

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

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

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

ستلاحظ أن هناك ضمانتين مختلفتين تحاول الرسوم تحقيقهما هنا:

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

أثبتت آلية EIP-1559 الخاصة بـ Ethereum فعاليتها تمامًا في تمكين المستخدمين من تقديم عطاءات بسهولة لإدراج الكتلة مع احتمال كبير للنجاح. هناك سعر احتياطي عالمي يعرف الجميع دفعه، ويجب أن يؤدي دفعه (عادةً إلى جانب رسوم الأولوية الاسمية) إلى تضمين معاملة المستخدم على الفور. ومع ذلك، فإن الآلية لا تسعى إلى تقديم أي ضمانات حول الطلب (أي أولوية الوصول إلى الدولة)، في حين أن الآليات خارج البروتوكول موثوقة للمستخدمين الذين يبحثون عن مثل هذه الضمانات (مباشرة من شركات البناء، على سبيل المثال).

تعمل عملية بناء الكتل التي اتبعها سولانا بشكل مختلف تمامًا. لا يقوم المدققون بالاستعانة بمصادر خارجية لإنتاج الكتلة الكاملة في فترات زمنية منفصلة لمنشئين خارج البروتوكول. "المجدول " هو الخوارزمية الافتراضية المضمنة في عميل التحقق من صحة Solana Labs ، والذي يقوم بجدولة المعاملات للتنفيذ وإنشاء الكتل بشكل مستمر.

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

داخل الكتلة، يمكن استخدام ما يصل إلى 12,000,000 وحدة عملة كحد أقصى لعمليات الكتابة المتسلسلة لحساب واحد ("قطعة الحالة"). هذا هو تقريبًا مقدار وحدات CU التي يمكن معالجتها بواسطة مؤشر ترابط واحد لكل فتحة 400 مللي ثانية على متطلبات العقدة المعقولة. يبلغ حد Solana لكل كتلة 48.000.000 وحدة عملة. يستخدم تطبيق المجدول الحالي أربعة سلاسل للمعاملات غير التصويتية، و12M x 4 = 48M. من الناحية النظرية، هذا يعني استخدام المزيد من النوى = زيادة حدود CU. التحجيم مع الأجهزة.

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

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

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

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

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

على الرغم من أنه يقع خارج نطاق هذه المقالة في الغالب، إلا أن عميل Jito-Solana يسمح للباحثين بالتقاط قيمة التعدين/القيمة القصوى القابلة للاستخراج (MEV) بشكل أكثر كفاءة بطرق تقلل من العوامل الخارجية السلبية على Solana. ينحرف Jito-Solana عن جدولة Solana الافتراضية من خلال تقديم مزادات حزمة Flashbots-esque منفصلة خارج البروتوكول تبلغ 200 مللي ثانية، والتي يتم تشغيلها بالتوازي مع إنتاج الكتلة المستمر الافتراضي وميمبول خاص (والذي ينحرف مرة أخرى عن TFM الافتراضي لـ Solana). ساعد اعتماد عميل Jito-Solana من قبل مدققي Solana (> 50% من المدققين يقومون بتشغيله اليوم) في معالجة بعض المشكلات المتعلقة بـ TFM الحالي الخاص بـ Solana - أي انتشار البريد العشوائي المعتمد على MEV.

أوجه القصور في آلية العمل المؤقتة الحالية التي وضعها سولانا

في حين أن آلية العمل المؤقتة التي وضعها سولانا واعدة للغاية، إلا أنها تعاني أيضًا من بعض أوجه القصور المحتملة في الوقت الحالي:

حافز للبريد العشوائي

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

المصدر: مؤسسة جيتو

مزاد السعر الأول

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

بشكل أكثر رسمية، نموذج FPA هو غير DSIC:

**توافق حوافز الإستراتيجية المهيمنة (DSIC): بافتراض أن منتج الكتلة ينفذ آلية TFM بأمانة، فإن إستراتيجية العطاءات المحددة يجب أن تكون الإستراتيجية السائدة للمستخدمين. وهذا يعني أن المستخدمين سيقدمون عطاءات (في رسوم المعاملات) بالقيمة الدقيقة التي ينسبونها إلى إدراج المعاملة [Chu22].

تعد DSIC إحدى الخصائص الرئيسية التي يهدف منشئو EIP-1559 إلى تقديمها إلى TFM الخاص بـ Ethereum من خلال تنفيذها، وكما وصفنا سابقًا، يمكن اعتبارها ناجحة. يعرف المستخدمون بسهولة أكبر سعر الاحتياطي العام الذي سيتم تضمينه في الكتلة في وقت معين (من خلال الرسوم الأساسية الديناميكية)، لذا فإن دفعه (بالإضافة إلى أي رسوم أولوية اسمية) سيؤدي دائمًا إلى تضمين معاملتك بسرعة.

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

50/50 حرق / دفع تعويضات التحقق

كما ذكرنا سابقًا، تحرق إيثريوم 100% من الرسوم الأساسية بينما ترسل 100% من رسوم الأولوية إلى منتج الكتل، بينما بالنسبة لـ Solana، يتم حرق/دفع كل من الرسوم الأساسية ورسوم الأولوية بنسبة 50/50 إلى منتج الكتل. ونتيجة لذلك، فإن Solana TFM غير مقاوم لـ OCA:

** مقاومة الاتفاق خارج السلسلة (مقاومة OCA أو SCP): لا يمكن لاتفاقية خارج السلسلة بين المستخدمين ومنتج الكتلة أن تحسن Pareto نتائج TFM لكتلة معينة [Rou21]. يعد بروتوكول c-SCP مقاومًا لتحالف منتج الكتلة وما يصل إلى المستخدمين الذين يمكنهم تحقيق الربح من خلال الانحراف عن الإبلاغ بصدق.

نرى مثالًا واضحًا على ذلك من خلال مزادات Jito-Solana خارج البروتوكول التي تدفع 100% من العطاءات (أقل من قطع Jito) لمنتجي الكتل، بدلاً من حرق 50% — Jito-Solana مثال على خارج السلسلة الاتفاقية المستخدمة من قبل منتجي الكتلة. ومع ذلك، نلاحظ أن نصائح Jito-Solana لا تعادل رسوم الأولوية، حيث يتم دفع الأولى فقط في حالة تنفيذ المعاملة (والحزمة) المرتبطة بنجاح.

سيقدم SIMD-0109 المقترح مؤخرًا آلية البقشيش (مماثلة لتلك المستخدمة في مزاد Jito-Solana خارج البروتوكول) في البروتوكول كتعليمات أصلية.

عدم وجود أنواع المعاملات المميزة

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

المصدر: سيتيريس، سولانا المونوليث

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

سوق الرسوم المحلية في سولانا

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

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

استخدام وطلبات CU غير فعالة

نظرًا لأن الرسوم الأساسية لـ Solana لا تأخذ في الاعتبار وحدات العملة، فإنها لا تحفز المعاملات من أجل:

1. استخدم وحدات العملة بكفاءة – تحمل المعاملة التي تحتوي على 1.4 مليون وحدة عملة نفس الرسوم الأساسية التي تحملها المعاملة التي تحتوي على 100 ألف وحدة عملة، وكلها متساوية.
2. طلب وحدات العملة بكفاءة — حتى إذا كانت المعاملة تستخدم 50 ألف وحدة عملة، فإنها تحمل نفس الرسوم الأساسية سواء طلبت 100 ألف وحدة عملة أو مليون وحدة عملة.

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

غير مكلفة لكتابة حسابات القفل

كما ذكرنا سابقًا، تحدد معاملات Solana مقدمًا جميع الحسابات التي سيقرأونها أو يكتبون إليها أثناء التنفيذ. ومع ذلك، يمكن إساءة استخدام هذه الآلية اليوم لقفل أي حساب عالميًا دون أي تكلفة. على سبيل المثال:

1. أرسل Tx_A الذي يحدد أنه سيكتب إلى الحساب_A.
2. يتلقى القائد Tx_A ويجدوله ويبدأ في تنفيذه. الحساب_A مقفل الآن - لا يمكن تنفيذ أي معاملة أخرى تمس الحساب_A حتى انتهاء Tx_A من التنفيذ.

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

مقترحات وأطر آلية تيسير التجارة

يجب على كل blockchain أن يقرر في النهاية كيفية تخصيص الموارد النادرة لمساحة الكتل المحدودة الخاصة به بين المستخدمين، وهو ما يفعله عبر TFM الخاص به. أدناه، سنناقش العديد من مقترحات وأطر آلية تيسير التجارة ذات الصلة والتي قد تكون ذات قيمة بالنسبة لسولانا.

أسواق رسوم Blockchain متعددة الأبعاد

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

على سبيل المثال، يحمل كل كود تشغيل لـ Ethereum كمية ثابتة معينة من الغاز الذي يستهلكه (على سبيل المثال، يستخدم ADD 3 غازات، بينما يستخدم MUL 5). تم تحديد سعر الغاز لكل كود تشغيل كتقدير تقريبي للموارد الأساسية التي يستخدمونها ومدى تكلفة تلك الموارد بالنسبة للعقد في الشبكة. على سبيل المثال، يمكن تحديد هذا المقياس الضمني لتكلفة العملية من خلال تشغيل معايير على أجهزة العالم الحقيقي.

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

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

**تعظيم الرفاهية: تشير قواعد التخصيص والدفع المقصودة إلى أن مجموع فائض المستهلك والقائم بالتعدين قد تم تعظيمه (تقريبًا).

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

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

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

الرسوم الأسية لحسابات قفل الكتابة

بعد مشاركة Anatoly الأخيرة حول اقتصاديات تنفيذ SVM ، اقترح Tao Zhu ، بالتعاون مع Anatoly، SIMD-0110. والدافع الأساسي لها هو ردع البريد العشوائي من خلال الضغط الاقتصادي الخلفي (أي زيادة الرسوم بطريقة مستهدفة مع مرور الوقت لتقليل الحافز للبريد العشوائي)، مما يؤدي إلى استخدام موارد الشبكة بشكل أكثر كفاءة. تستمر معاملات المراجحة الفاشلة في ملء ما يقرب من نصف (أو أكثر) مساحة كتلة Solana نظرًا لأن البريد العشوائي يعتبر أمرًا منطقيًا ورخيصًا بشكل لا يصدق.

يوصي الاقتراح بتتبع المتوسط المتحرك الأسي (EMA) لاستخدام CU لكل حساب لكل كتلة لتحقيق ذلك. ستزداد تكلفة قفل الحساب بشكل كبير بناءً على استخدام CU اللاحق الخاص به، مما يمنع البريد العشوائي. يشبه المنطق الأساسي كيفية قيام EIP-1559 بتعيين الرسوم الأساسية العالمية لـ Ethereum كدالة لاستخدام الغاز في الكتل اللاحقة. ومع ذلك، فإن SIMD هذا أكثر تفصيلاً بكثير في تحديد أسواق الرسوم الأساسية المحلية لكل حساب.

ستكون فكرة التنفيذ الأساسية لرسوم قفل الكتابة المتغيرة المستندة إلى الحساب كما يلي:

1. تتبع استخدام وحدة حساب EMA اللاحقة لكل حساب مثير للجدل خلال آخر 150 فتحة.
2. الحد الأقصى لعدد الحسابات التي سيتم تعقبها هو 2048، حيث يتم فقط تعقب الحسابات الأكثر إثارة للجدل والتي تتمتع بأعلى معدل لتكلفة قفل الكتابة.
3. إذا كان استخدام وحدة حوسبة EMA الخاصة بالحساب أكبر من 50% من الحد الأقصى لـ CU، فسيزيد معدل تكلفة قفل الكتابة الخاص به بنسبة X%. إذا كان أقل من 50% من الحد الخاص به، سينخفض معدل التكلفة بنسبة X%.
4. توصي V0 بمعدل تكلفة قفل الكتابة الأولي يبلغ 1000 مصباح صغير/وحدة CU ومعدل تعديل معدل التكلفة بنسبة 1% لكل فتحة (لاحظ أن النسب المئوية الدقيقة هنا كلها عرضة للتغيير نظرًا للطبيعة المبكرة للاقتراح).
5. يتم حساب رسوم قفل الكتابة لحساب في كتلة معينة عن طريق ضرب معدل تكلفة قفل الكتابة في وحدات CU المطلوبة للمعاملة.
6. تستمر المعاملات في دفع رسوم التوقيع، كما تظل رسوم الأولوية الاختيارية أيضًا.
7. يتم حرق رسوم قفل الكتابة المجمعة بنسبة 100%.
8. تتم مكافأة رسوم الأولوية المجمعة بنسبة 100%.
9. يتم حرق 50% من رسوم التوقيع المجمعة ومكافأة 50% منها.

هذا الاقتراح من شأنه أن يجعل ميزة قفل الكتابة الخاصة بـ Solana (عادةً) DSIC مشابهة لكيفية قيام EIP-1559 بصنع TFM الخاص بـ Ethereum (عادةً) DSIC وMMIC [Rou23] - إلا في حالة وجود ارتفاع مفاجئ في الرسوم.

يمكننا تعريف خاصية MMIC على النحو التالي:

** توافق حوافز عامل التعدين قصير النظر (MMIC): يعمل منتج الكتلة على زيادة فائدته إلى الحد الأقصى من خلال عدم إنشاء معاملات مزيفة واتباع القواعد المنصوص عليها في TFM. قصر النظر يعني أن هذا الهدف يتعلق فقط بالكتلة الحالية عند الحكم على تعظيم المنفعة [Rou21].

أي آلية لاحقة غير كاملة لأنها قد لا تمثل بدقة الحالة الحالية للطلب. على سبيل المثال، قد يكون الطلب منخفضًا لفترة طويلة من الوقت (وبالتالي، تكون الرسوم الأساسية الديناميكية منخفضة)، ثم يرتفع فجأة بالنسبة إلى عملة NFT. يمكن أن يكون هذا هو الحال على المستوى العالمي (كما هو الحال في TFM الخاص بـ Ethereum) وقد يكون أكثر تقلبًا على المستوى المحلي لكل حساب (كما هو مذكور في SIMD-0110).

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

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

أحد الانتقادات المحتملة هنا هو أن أسواق الرسوم المحلية القائمة على الحساب (وخاصة هذا الاقتراح، الذي يتطلب حساب المتوسط المتحرك الأسي المستمر لكل حساب) يمكن أن تكون مكلفة من الناحية الحسابية. هذا النوع من الرسوم متعددة الأبعاد لا حدود له، نظرًا لأن أي حساب يمكن أن يكون مزدحمًا، الأمر الذي من المحتمل أن يمثل صعوبات لمثل هذه الآلية. ومع ذلك، في حالة SIMD-0110، يتم تجنب ذلك عن طريق تعيين حد أعلى لعدد الحسابات التي يمكن تتبع EMA لاستخدام CU الخاص بها في وقت معين.

**قابلة للحساب بكفاءة: يجب تصميم آلية مزاد الكتلة بحيث يمكن حسابها بكفاءة لمنتج (أو منشئ) معين - تكون فتحات Eclipse وSolana أقل من 400 مللي ثانية، مما يضع قيدًا محكمًا على الحد الأقصى لوقت الحوسبة لفترة معينة حاجز.

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

التغييرات في جدولة Solana الافتراضية

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

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

المصدر: أندرو فيتزجيرالد، سولانا المصرفية المرحلة والمجدولة

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

جوهر الترقية إلى جدولة Solana الافتراضية يكمن في الانتقال من النهج القديم (المسمى وضع ThreadLocalMultiIterator) إلى النهج الجديد للجدولة، المسمى وضع CentralScheduler. ستوفر هذه المقالة نظرة عامة وتحليلًا للتغييرات فقط. ومع ذلك، يمكن العثور على مزيد من المعلومات في مقالة أندرو فيتزجيرالد ومدونة ملخصة مصاحبة <a href="https://medium.com/@harshpatel_36138/whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7"> بواسطة هارش باتل من فريق Tiny Dancer . يتم عرض نظرة عامة على عملية الجدولة الجديدة أدناه.

المصدر: أندرو فيتزجيرالد، سولانا المصرفية المرحلة والمجدولة

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

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

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

رسوم برنامج كتابة الحساب القابل للخصم (PRAW).

من تأليف Godmode Galactus و Max Schneider ، يقترح SIMD-0016 رسوم كتابة الحساب القابل للخصم (PRAW). وسوف يمنحون سيطرة كبيرة لمطوري التطبيقات، حيث يمكنهم وضع معايير الدفع والتخفيضات على هذه الرسوم، مما يسمح لهم بتحفيز وتثبيط سلوك المستخدم على النحو الذي يرونه مناسبا.

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

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

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

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

**مقاومة الحزن: مجموعة فرعية من DSIC حيث لا يتم تحفيز المستخدمين على تحريف قوائم الوصول الخاصة بهم - تحريف الموارد المطلوبة لمعاملاتهم [Gar23].

من المحتمل أن يفشل اقتراح PRAW في منع البريد العشوائي لأنه يعتمد على مطوري التطبيقات بشكل كافٍ: 1) القدرة على التمييز بين البريد العشوائي و"السلوك العادي" و2) الاختيار طوعًا لتحصيل رسوم أكبر مقابل العوامل الخارجية السلبية التي يتحملون المسؤولية عنها جزئيًا عندما لا يكون ذلك ممكنًا. من مصلحتهم أن يفعلوا ذلك، ويمكنهم ببساطة اختيار عدم القيام بذلك.

في المقابل، في حين أن أعضاء مجتمع أبحاث Solana منقسمون بشكل لا يمكن إنكاره حول إدخال الرسوم الأساسية لـ EMA، إلا أن هناك اتفاقًا عامًا حول إضافة بعض مكونات الرسوم الأساسية التي تتناسب مع وحدات CU. يمكن أن يؤدي ذلك إلى تحفيز تقدير CU الدقيق والاستخدام الفعال لوحدات CU من قبل المطورين.

أفكار فراق

تتطلب أهداف Solana الهندسية والأداء الفريدة اعتبارات TFM فريدة. إن مجرد نقل سوق الرسوم الحالية لـ Ethereum إلى Solana ليس هو الحل هنا بالطبع، ولكن هناك دروس قيمة يمكن تعلمها منه. وهذا أمر وثيق الصلة بالآليات التي تكون على حد سواء:

1. داخل البروتوكول - إجراءات TFM التي يتم فرضها بالإجماع (على سبيل المثال، EIP-1559 و SIMD-0110)
2. خارج البروتوكول - PBS عبر MEV-Boost، وتحسينات جدولة Solana، ومزادات Jito

بالنسبة لكل من Solana وEthereum، يبدو من المرجح أن تتعايش الآليات داخل البروتوكول وخارجه وتتطور معًا للمضي قدمًا. ويعد التوازن بينهما أحد الأسئلة الأساسية في تصميم هذه الأنظمة. غالبًا ما يتمحور الجدل الدائر حول SIMD-0110 حول وجهتي نظر متعارضتين:

1. ستؤدي تحسينات المجدول والشبكات لتقليل الارتعاش إلى معالجة المشكلات الموضحة هنا بشكل كافٍ، لذا فإن إجراء تغييرات كبيرة على TFM داخل البروتوكول غير ضروري.
2. على الرغم من أن تحسينات الجدولة والشبكات خارج البروتوكول ضرورية، إلا أنها غير كافية بطبيعتها. مطلوب ضغوط اقتصادية عكسية داخل البروتوكول.

ومن الواضح أن تسعير الموارد المتعددة الأبعاد يشكل قيمة كبيرة في كلتا الحالتين أيضاً. بدأت Ethereum في متابعة مثل هذا TFM على مستوى الموارد الأساسية، مع قيام EIP-4844 بتقسيم بيانات blob من سوق التنفيذ. وعلى العكس من ذلك، يمضي سولانا قدماً في تسعير الموارد المتعددة الأبعاد على مستوى الحساب الفردي لريادة "أسواق الرسوم المحلية".

يعد بحث TFM هنا متطورًا، ويجد الباحثون باستمرار طرقًا جديدة ومبتكرة لتحسين كيفية عمل الرسوم على Solana والسلاسل الأخرى. نحن متفائلون بأن المقترحات التي تمت مناقشتها هنا ستستمر جميعها في جعل Solana أكثر كفاءة وقابلية للتطوير وسهولة الاستخدام واستدامة اقتصاديًا.

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

تنصل:

1. تمت إعادة طباعة هذه المقالة من [Eclipse]، إعادة توجيه العنوان الأصلي "آليات رسوم المعاملات Solana & Ethereum: مقترحات لتحسين TFM في Solana"، جميع حقوق الطبع والنشر مملوكة للمؤلف الأصلي [Eclipse]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسوف يتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء والآراء الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ أو توزيع أو سرقة المقالات المترجمة.