تصميم رسوم الوقود الأول للغة MOVE: كيفية حساب الاستهلاك داخل السلسلة
قياس رسوم الوقود هو مفهوم أساسي في العديد من سلاسل الكتل، حيث يعرف كمية الموارد الحسابية والتخزينية المطلوبة لتنفيذ وتخزين المعاملات داخل السلسلة. تحدد خطة رسوم الوقود جميع التكاليف المستهلكة أثناء التنفيذ على السلسلة، وتستخدم لحساب تكلفة رسوم الوقود المستخدمة خلال تنفيذ المعاملات.
عملية
لضمان التنفيذ الفعال، فإن العملية داخل السلسلة هي:
مبادئ التعريف
إعداد إطار التقييم، وتحديد سعر كل تنفيذ
إنشاء نظام قياس رسوم الوقود لـ MOVE وأمان رسوم الوقود الجبرية
استيراد إطار تكلفة الوقود العلوية
جعل إطار رسوم الوقود مدركًا للتخزين
مزيد من التفاصيل حول خطة رسوم الوقود
مبدأ
المبدأ المحدد هو:
يجب أن تكون تكلفة التشغيل مرتبطة مباشرة بالموارد المتاحة في الشبكة ( مثل وحدة المعالجة المركزية، والذاكرة، والشبكة، وتخزين الإدخال/الإخراج، واستخدام المساحة، وما إلى ذلك ). بعد تحسين التكنولوجيا والعمليات، يجب أن تنخفض تكلفة الوقود.
يجب أن يتم تعيين رسوم الوقود من خلال الحوكمة داخل السلسلة، ويمكن تكوينها بسلاسة.
يمكن أن تمنع رسوم الوقود هجمات DoS على الموارد الثابتة للشبكة، وقد تحتاج إلى تعديل سريع بناءً على حالة الشبكة من خلال اقتراحات الحوكمة.
تعكس أسعار رسوم الوقود رؤية تسريع النمو والحفاظ على انتشار داخل السلسلة.
تشجيع اتخاذ قرارات جيدة في التصميم، مثل إعطاء الأولوية للأمان، والتجزئة، والأحداث مثل التأكيدات.
حساب تكلفة الوقود
يجب على المستخدمين تحديد كميتين في المعاملة عند تقديم المعاملة:
أقصى عدد من رسوم الوقود: يقاس بوحدات رسوم الوقود. هذا هو الحد الأقصى لوحدات رسوم الوقود التي يرغب المستخدم في إنفاقها لتنفيذ المعاملة.
سعر وحدة رسوم الوقود: يتم حساب رسوم الوقود لكل وحدة بالنظام الثماني، 1 ثماني = 0.00000001 APT(=$10^{-8}$). هذا هو سعر رسوم الوقود الذي يرغب المستخدم في دفعه.
أثناء التنفيذ، سيتم فرض رسوم على الصفقة:
التكاليف الثابتة، القاعدة الثابتة بالإضافة إلى الرسوم الإضافية للمعاملات الكبيرة.
تكلفة التنفيذ، تستخدم لتنفيذ تعليمات MOVE.
تكلفة القراءة، المستخدمة لقراءة البيانات من التخزين الدائم.
تكلفة الكتابة، تُستخدم لكتابة البيانات إلى التخزين الدائم.
يمكن حساب رسوم المعاملة النهائية عن طريق ضرب إجمالي كمية رسوم الوقود المستهلكة في سعر وحدة رسوم الوقود. على سبيل المثال، إذا استهلكت معاملة ما 670 وحدة من رسوم الوقود، وكان سعر رسوم الوقود المحدد من قبل المستخدم هو 100 Octa لكل وحدة، فإن رسوم المعاملة النهائية هي 670 * 100 = 67000 Octa = 0.00067 APT.
إذا نفدت رسوم الوقود أثناء تنفيذ المعاملة، سيقوم المرسل بفرض رسوم وفقًا لأقصى كمية من رسوم الوقود، وسيتم استعادة جميع التغييرات التي أجرتها المعاملة.
إنشاء جدول خطة رسوم الوقود
1. التكوين الأساسي
هناك عدة مكونات في خطة رسوم الوقود لا تتعلق بتفاصيل العمليات الفردية، بما في ذلك حجم المعاملة ووحدات رسوم الوقود القصوى ( التي تختلف عن الكمية القصوى لرسوم الوقود المحددة من قبل المستخدم في المعاملة ).
2. حجم المعاملات
قد يكون حجم معظم المعاملات في نطاق الكيلوبايت. ومع ذلك، فإن إصدار وحدة MOVE يمكن أن يكون بسهولة عدة آلاف من الكيلوبايت، بينما يكون حجم الإطار حوالي 100 كيلوبايت. يكون حجم وحدات المستخدمين عادةً بين 4 كيلوبايت و 40 كيلوبايت. تم تعيين قيمة حجم المعاملة في البداية إلى 32 كيلوبايت، ولكن بناءً على ردود فعل المجتمع، تم طلب توفير مساحة أكبر لتبسيط تطوير التطبيقات، لذا تم تعديل حجم المعاملة إلى 64 كيلوبايت.
يمكن أن تؤدي المعاملات واسعة النطاق إلى زيادة تكاليف عرض النطاق الترددي للشبكة بأكملها، مما قد يؤثر سلبًا على الأداء. إذا تم إساءة استخدامها، ستشجع الذاكرة المؤقتة على تجاهل المعاملات الأكبر حجمًا، لذا فإن طريقتنا هي تحقيق التوازن بين حجم المعاملات الكبيرة وقابلية الوصول.
3. أقصى وحدة لرسوم الوقود
تعريف الحد الأقصى لوحدة تكلفة الوقود في خطة تكلفة الوقود يحدد عدد العمليات التي يمكن تنفيذها في صفقة واحدة. ملاحظة! هذا يختلف عن الحد الأقصى لمبلغ تكلفة الوقود الذي يحدده المستخدم في الصفقة.
تؤثر الوحدة القصوى لرسوم الوقود في خطة رسوم الوقود بشكل مباشر على المدة التي يمكن أن يتم فيها تنفيذ المعاملة، وقد تؤدي الإعدادات المرتفعة جداً إلى تأثيرات سلبية على أداء السلسلة. على سبيل المثال، قد ينسى المستخدم وجود زيادة في حلقة while، مما يؤدي إلى حلقة لانهائية، وهو خطأ شائع. حتى مع إجراء أكبر ترقية للإطار، لا يزال أقل من الوحدة القصوى لرسوم الوقود في خطة رسوم الوقود ( محددة على 90% من 1,000,000).
4. التنفيذ
لتقييم تكلفة التنفيذ، تم بناء إطار مرجعي، واستخدم Valgrind لتحليل MOVE VM عند تنفيذ هذا الإطار. الناتج هو مجموعة من الشيفرات المصدرية المعلقة، تخبرنا بعدد تعليمات الآلة التي تنتجها كل سطر من الشيفرة.
بمساعدة التحليل المذكور أعلاه، تم تقدير التكلفة النسبية لجميع تعليمات MOVE والدوال الأصلية بشكل تقريبي. ومع ذلك، توجد بعض المشاكل في هذه الطريقة مع الدوال المضمنة: فهي لن تشمل تلقائيًا في حسابات المستدعي. لقد رأينا أيضًا أن هذا يحدث فقط عند تحليل بعض تعليمات MOVE، ويمكن حل هذه المشكلة عن طريق جمع الأرقام.
بعد ذلك، من خلال النظر في أمثلة التشفير التي تعزز متانة النظام وأمانه، توصل الفريق إلى العدد النهائي لتعليمات الآلة التي سيتم تنفيذها. يتم موازنة هذا الرقم بالتتابع مع وحدات التخزين وأقصى تكلفة وقود لتحديد قيمتها الحالية في خطة تكلفة الوقود.
5. التخزين
كلما تم الوصول إلى عناصر حالة دفتر الحسابات أو البيانات المخزنة في التخزين الدائم، يقوم العقد بإصدار قراءة أو كتابة إلى جهاز التخزين. يعتمد إجمالي عدد وصول البيانات في الثانية على عرض النطاق الترددي لجهاز التخزين وسعة IOPS. مثل دورات CPU في جزء حساب رسوم الوقود، فإن وصول البيانات هو ندرة لحظية تنافسية من قبل مستخدمي البلوكشين في ظل تحميل النظام، بالإضافة إلى ذلك، فإن تكلفة شغل القرص لكتابة البيانات على داخل السلسلة دائمة. يقوم الفريق بتصميم خطة رسوم تخزين الوقود من خلال الأخذ بعين الاعتبار هذه التكاليف.
إن الوصول إلى أي عنصر حالة وتخزينه ينتج عنه تكاليف مرتبطة بهيكل البيانات الذي يتحقق من حالة سلسلة الكتل بأكملها. تتعلق هذه التكاليف بالأساس المختلف لعناصر الحالة ($2^{256}$). هناك أيضًا تكلفة تتناسب مع حجم كل عنصر. لتشغيل عنصر حالة، تكون الرسوم ( باستثناء الحالات الاستثنائية الموصوفة في القسم التالي ):
تكلفة تخزين الوقود = item_fee + (byte_fee * bytes)
اقرأ، أنشئ واكتب
أي وصول إلى عناصر الحالة ينتمي إلى واحدة من الأنواع الثلاثة التالية: قراءة، إنشاء أو كتابة. يتم فرض رسوم على الوصول حسب رسوم العناصر ورسوم البايت، كما هو موضح في المعادلة أعلاه.
تُعتبر عملية القراءة هي أكثر العمليات شيوعًا، وهي مقيدة فقط بنقص الموارد اللحظي. وبالتالي، فإن تكاليف القراءة يتم معايرتها بناءً على تكلفة مشروع قرص IOPS( وسعة النطاق الترددي للمواصفات الفنية المرجعية.
create هو إضافة عنصر جديد إلى تخزين الحالة. لذلك، create يزيد من هيكل بيانات المصادقة، مما يجعل كل شيء أكثر تكلفة، وبالتالي فإن التكلفة هي الأعلى. تكلفة الإنشاء يتم معايرتها بناءً على مساحة القرص المرجعية التي تمتلكها الشبكة. لذلك، يتطلب ملء القرص بالعناصر )item_fee( والبايت )byte_fee( الكثير من رسوم الوقود.
تقوم عمليات الكتابة بتحديث العناصر الموجودة في تخزين الحالة. لذلك، لن تنتج عمليات الكتابة عن أي تكاليف إضافية في بنية بيانات المصادقة. ومع ذلك، من خلال تعديل العناصر الموجودة إلى بايت أكبر، لا يزال من الممكن إتلاف القرص. لذلك، نحن نفرض نفس الرسوم على بايتات العناصر المحدثة كما هو الحال عند الإنشاء.
يجب أن نلاحظ أن التكاليف المتعلقة بالتخزين يتم تقييمها بناءً على كل معاملة: حتى لو تم قراءة/كتابة نفس المورد عدة مرات، فإنك تحتاج فقط إلى دفع الرسوم مرة واحدة.
استنادًا إلى الاعتبارات المذكورة أعلاه، قمنا بتعريف 6 معلمات لرسوم الوقود، والتي تشكل جزءًا من التكلفة الإجمالية لرسوم الوقود. انظر أدناه:
per_item_read: وفقًا لـ IOPs لتصحيح
per_byte_read: حسب عرض النطاق الترددي الفعلي
per_item_create:تعديل وفقًا للإجمالي المستهدف للمشروع
per_byte_create: يتم المعايرة بناءً على الحجم الإجمالي المستهدف - يحتوي كل عنصر على 1KB الأول.
per_item_write: مثل per_item_read
per_byte_write: مثل per_byte_create
) تكلفة وحدة رسوم الوقود المستقرة
بغض النظر عن تكلفة تنفيذ العمليات حسب القيمة السوقية لـ APT أو العملات القانونية، يتطلب كل عملية وتجارة نفسها تكلفة وحدة ثابتة بالنسبة لتكاليف التخزين والتنفيذ. تساعد تكلفة وحدة الوقود الثابتة في الحفاظ على خطة رسوم الوقود ثابتة، وفصلها عن القيمة السوقية الحرة لـ APT. بالإضافة إلى ذلك، فإن الاختيار الصحيح لعدد الأرقام العشرية لوحدة الوقود يساعد في الحفاظ على خطة رسوم الوقود ثابتة. مع أخذ ذلك في الاعتبار، يُمثل الفريق وحدة رسوم الوقود بدقة تقارب 3 أرقام. لذلك، فإن تكلفة معاملات التحويل حوالي 700 وحدة من رسوم الوقود.
المشاركة المجتمعية
حتى مع بذل الكثير من الجهد في خطة رسوم الوقود، إلا أنها لا تزال غير مكتملة. ك مشروع مجتمعي، يمكن لأعضاء المجتمع اختيار:
بناءً على الخبرة، حدد الأماكن التي تكون فيها خطة تكلفة الوقود غير معقولة.
أعرب عن مخاوفك بشأن خطة رسوم الوقود وشارك في مناقشة المجتمع
التصويت على مقترحات الحوكمة المتعلقة برسوم الوقود
كيف يمكن تعديل تكلفة رسوم الوقود؟
يتم تخزين خطة رسوم الوقود كإعداد داخل السلسلة، ولكن يمكن تعديلها من خلال مقترحات الحكم، ويمكن إضافة تعليمات جديدة أو ميزات أصلية بسلاسة.
تم تصميم خطة رسوم الوقود لتكون قابلة للتوسع، مما يسمح بترقيتها من خلال مقترحات الحوكمة. مع التحسين المستمر لـ MOVE VM ودمج ملاحظات المستخدمين، يمكن تعديل معلمات رسوم الوقود بمرور الوقت.
أحيانًا، قد تتطلب صيغة رسوم الوقود تغييرات معقدة تتجاوز التكوين داخل السلسلة. عادةً ما يتم ترميز هذه الصيغ باستخدام Rust، وتُميز من خلال علامات ميزات رسوم الوقود داخل السلسلة. لترقية هذه الصيغ، يجب تحديث برنامج العقد باستخدام الصيغة الجديدة، وتمييزها بعلامات ميزات رسوم وقود مختلفة. ثم يجب نشر برنامج العقد واعتماده بشكل كبير من قبل مشغلي العقد، وأخيرًا، يجب نشر واعتماد مقترح الحكم لاستخدام إصدار رسوم الوقود الجديد.
العمل المستقبلي
هذا هو إطار رسوم الوقود القابل للتطبيق الأول لـ MOVE. يتطلب تعديلات كبيرة على MOVE VM و Core. نأمل أن تمهد هذه الأعمال الطريق للأعمال المستقبلية:
1### خفض تكلفة التنفيذ، يمتلك نموذج حقيقي لرسوم الوقود يوضح مكان فعالية المترجم والآلة الافتراضية، يمكن للفريق تحسين معظمها لخفض تكلفة التنفيذ.
2) حساب تكلفة الوقود متعددة الأبعاد, يسمح للمستخدمين بتخصيص ميزانية منفصلة للتنفيذ والتخزين. بهذه الطريقة، لن يضطر المستخدمون لدفع أسعار مرتفعة لتكاليف الوقود بسبب وقت التنفيذ الطويل الناتج عن تطبيقات ذات كود ضعيف. كما سيسمح أيضًا بتعريف أكثر دقة لأقصى سعر لتكاليف الوقود للمعاملات على داخل السلسلة.
3) تخفيف حالة الانتفاخ، لا توجد حاليًا طرق بسيطة لتقليل مجموعة الحالة، باستثناء العقد ) أو المستخدم ( لحذف العناصر بشكل صريح. قد يؤدي دفع المستخدم لحذف البيانات إلى خلق فرص للمراجحة، حيث يقوم المستخدم بإنشاء التخزين عندما يكون رخيصًا، وحذفه عندما يكون مكلفًا. تأخير حل هذا التحدي قد يضعف دافع المطورين لحذف البيانات داخل السلسلة. الفريق يستكشف مفهوم TTL لكل مشروع، والذي سيؤدي إلى حذف عناصر الحالة غير المصرح بها عند انتهاء صلاحية TTL.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 24
أعجبني
24
9
إعادة النشر
مشاركة
تعليق
0/400
SatoshiLegend
· 07-18 12:03
داخل السلسلة الأمن هو الأساس جوهر حساب رسوم الوقود هو إعادة تجريد توزيع الموارد
شاهد النسخة الأصليةرد0
LayoffMiner
· 07-18 04:42
تحرك غير مألوف فقط انظر إلى الصورة لتستمتع
شاهد النسخة الأصليةرد0
ZkSnarker
· 07-18 00:42
تقنيًا مجرد جبر مع خطوات إضافية... بصراحة، يجب أن يتحسن التحرك في تجريدات التكاليف.
تصميم رسوم الوقود الأصلي للغة MOVE: كيف يتم تحديد تكلفة حساب داخل السلسلة
تصميم رسوم الوقود الأول للغة MOVE: كيفية حساب الاستهلاك داخل السلسلة
قياس رسوم الوقود هو مفهوم أساسي في العديد من سلاسل الكتل، حيث يعرف كمية الموارد الحسابية والتخزينية المطلوبة لتنفيذ وتخزين المعاملات داخل السلسلة. تحدد خطة رسوم الوقود جميع التكاليف المستهلكة أثناء التنفيذ على السلسلة، وتستخدم لحساب تكلفة رسوم الوقود المستخدمة خلال تنفيذ المعاملات.
عملية
لضمان التنفيذ الفعال، فإن العملية داخل السلسلة هي:
مبدأ
المبدأ المحدد هو:
يجب أن تكون تكلفة التشغيل مرتبطة مباشرة بالموارد المتاحة في الشبكة ( مثل وحدة المعالجة المركزية، والذاكرة، والشبكة، وتخزين الإدخال/الإخراج، واستخدام المساحة، وما إلى ذلك ). بعد تحسين التكنولوجيا والعمليات، يجب أن تنخفض تكلفة الوقود.
يجب أن يتم تعيين رسوم الوقود من خلال الحوكمة داخل السلسلة، ويمكن تكوينها بسلاسة.
يمكن أن تمنع رسوم الوقود هجمات DoS على الموارد الثابتة للشبكة، وقد تحتاج إلى تعديل سريع بناءً على حالة الشبكة من خلال اقتراحات الحوكمة.
تعكس أسعار رسوم الوقود رؤية تسريع النمو والحفاظ على انتشار داخل السلسلة.
تشجيع اتخاذ قرارات جيدة في التصميم، مثل إعطاء الأولوية للأمان، والتجزئة، والأحداث مثل التأكيدات.
حساب تكلفة الوقود
يجب على المستخدمين تحديد كميتين في المعاملة عند تقديم المعاملة:
أقصى عدد من رسوم الوقود: يقاس بوحدات رسوم الوقود. هذا هو الحد الأقصى لوحدات رسوم الوقود التي يرغب المستخدم في إنفاقها لتنفيذ المعاملة.
سعر وحدة رسوم الوقود: يتم حساب رسوم الوقود لكل وحدة بالنظام الثماني، 1 ثماني = 0.00000001 APT(=$10^{-8}$). هذا هو سعر رسوم الوقود الذي يرغب المستخدم في دفعه.
أثناء التنفيذ، سيتم فرض رسوم على الصفقة:
يمكن حساب رسوم المعاملة النهائية عن طريق ضرب إجمالي كمية رسوم الوقود المستهلكة في سعر وحدة رسوم الوقود. على سبيل المثال، إذا استهلكت معاملة ما 670 وحدة من رسوم الوقود، وكان سعر رسوم الوقود المحدد من قبل المستخدم هو 100 Octa لكل وحدة، فإن رسوم المعاملة النهائية هي 670 * 100 = 67000 Octa = 0.00067 APT.
إذا نفدت رسوم الوقود أثناء تنفيذ المعاملة، سيقوم المرسل بفرض رسوم وفقًا لأقصى كمية من رسوم الوقود، وسيتم استعادة جميع التغييرات التي أجرتها المعاملة.
إنشاء جدول خطة رسوم الوقود
1. التكوين الأساسي
هناك عدة مكونات في خطة رسوم الوقود لا تتعلق بتفاصيل العمليات الفردية، بما في ذلك حجم المعاملة ووحدات رسوم الوقود القصوى ( التي تختلف عن الكمية القصوى لرسوم الوقود المحددة من قبل المستخدم في المعاملة ).
2. حجم المعاملات
قد يكون حجم معظم المعاملات في نطاق الكيلوبايت. ومع ذلك، فإن إصدار وحدة MOVE يمكن أن يكون بسهولة عدة آلاف من الكيلوبايت، بينما يكون حجم الإطار حوالي 100 كيلوبايت. يكون حجم وحدات المستخدمين عادةً بين 4 كيلوبايت و 40 كيلوبايت. تم تعيين قيمة حجم المعاملة في البداية إلى 32 كيلوبايت، ولكن بناءً على ردود فعل المجتمع، تم طلب توفير مساحة أكبر لتبسيط تطوير التطبيقات، لذا تم تعديل حجم المعاملة إلى 64 كيلوبايت.
يمكن أن تؤدي المعاملات واسعة النطاق إلى زيادة تكاليف عرض النطاق الترددي للشبكة بأكملها، مما قد يؤثر سلبًا على الأداء. إذا تم إساءة استخدامها، ستشجع الذاكرة المؤقتة على تجاهل المعاملات الأكبر حجمًا، لذا فإن طريقتنا هي تحقيق التوازن بين حجم المعاملات الكبيرة وقابلية الوصول.
3. أقصى وحدة لرسوم الوقود
تعريف الحد الأقصى لوحدة تكلفة الوقود في خطة تكلفة الوقود يحدد عدد العمليات التي يمكن تنفيذها في صفقة واحدة. ملاحظة! هذا يختلف عن الحد الأقصى لمبلغ تكلفة الوقود الذي يحدده المستخدم في الصفقة.
تؤثر الوحدة القصوى لرسوم الوقود في خطة رسوم الوقود بشكل مباشر على المدة التي يمكن أن يتم فيها تنفيذ المعاملة، وقد تؤدي الإعدادات المرتفعة جداً إلى تأثيرات سلبية على أداء السلسلة. على سبيل المثال، قد ينسى المستخدم وجود زيادة في حلقة while، مما يؤدي إلى حلقة لانهائية، وهو خطأ شائع. حتى مع إجراء أكبر ترقية للإطار، لا يزال أقل من الوحدة القصوى لرسوم الوقود في خطة رسوم الوقود ( محددة على 90% من 1,000,000).
4. التنفيذ
لتقييم تكلفة التنفيذ، تم بناء إطار مرجعي، واستخدم Valgrind لتحليل MOVE VM عند تنفيذ هذا الإطار. الناتج هو مجموعة من الشيفرات المصدرية المعلقة، تخبرنا بعدد تعليمات الآلة التي تنتجها كل سطر من الشيفرة.
بمساعدة التحليل المذكور أعلاه، تم تقدير التكلفة النسبية لجميع تعليمات MOVE والدوال الأصلية بشكل تقريبي. ومع ذلك، توجد بعض المشاكل في هذه الطريقة مع الدوال المضمنة: فهي لن تشمل تلقائيًا في حسابات المستدعي. لقد رأينا أيضًا أن هذا يحدث فقط عند تحليل بعض تعليمات MOVE، ويمكن حل هذه المشكلة عن طريق جمع الأرقام.
بعد ذلك، من خلال النظر في أمثلة التشفير التي تعزز متانة النظام وأمانه، توصل الفريق إلى العدد النهائي لتعليمات الآلة التي سيتم تنفيذها. يتم موازنة هذا الرقم بالتتابع مع وحدات التخزين وأقصى تكلفة وقود لتحديد قيمتها الحالية في خطة تكلفة الوقود.
5. التخزين
كلما تم الوصول إلى عناصر حالة دفتر الحسابات أو البيانات المخزنة في التخزين الدائم، يقوم العقد بإصدار قراءة أو كتابة إلى جهاز التخزين. يعتمد إجمالي عدد وصول البيانات في الثانية على عرض النطاق الترددي لجهاز التخزين وسعة IOPS. مثل دورات CPU في جزء حساب رسوم الوقود، فإن وصول البيانات هو ندرة لحظية تنافسية من قبل مستخدمي البلوكشين في ظل تحميل النظام، بالإضافة إلى ذلك، فإن تكلفة شغل القرص لكتابة البيانات على داخل السلسلة دائمة. يقوم الفريق بتصميم خطة رسوم تخزين الوقود من خلال الأخذ بعين الاعتبار هذه التكاليف.
إن الوصول إلى أي عنصر حالة وتخزينه ينتج عنه تكاليف مرتبطة بهيكل البيانات الذي يتحقق من حالة سلسلة الكتل بأكملها. تتعلق هذه التكاليف بالأساس المختلف لعناصر الحالة ($2^{256}$). هناك أيضًا تكلفة تتناسب مع حجم كل عنصر. لتشغيل عنصر حالة، تكون الرسوم ( باستثناء الحالات الاستثنائية الموصوفة في القسم التالي ):
تكلفة تخزين الوقود = item_fee + (byte_fee * bytes)
اقرأ، أنشئ واكتب
أي وصول إلى عناصر الحالة ينتمي إلى واحدة من الأنواع الثلاثة التالية: قراءة، إنشاء أو كتابة. يتم فرض رسوم على الوصول حسب رسوم العناصر ورسوم البايت، كما هو موضح في المعادلة أعلاه.
تُعتبر عملية القراءة هي أكثر العمليات شيوعًا، وهي مقيدة فقط بنقص الموارد اللحظي. وبالتالي، فإن تكاليف القراءة يتم معايرتها بناءً على تكلفة مشروع قرص IOPS( وسعة النطاق الترددي للمواصفات الفنية المرجعية.
create هو إضافة عنصر جديد إلى تخزين الحالة. لذلك، create يزيد من هيكل بيانات المصادقة، مما يجعل كل شيء أكثر تكلفة، وبالتالي فإن التكلفة هي الأعلى. تكلفة الإنشاء يتم معايرتها بناءً على مساحة القرص المرجعية التي تمتلكها الشبكة. لذلك، يتطلب ملء القرص بالعناصر )item_fee( والبايت )byte_fee( الكثير من رسوم الوقود.
تقوم عمليات الكتابة بتحديث العناصر الموجودة في تخزين الحالة. لذلك، لن تنتج عمليات الكتابة عن أي تكاليف إضافية في بنية بيانات المصادقة. ومع ذلك، من خلال تعديل العناصر الموجودة إلى بايت أكبر، لا يزال من الممكن إتلاف القرص. لذلك، نحن نفرض نفس الرسوم على بايتات العناصر المحدثة كما هو الحال عند الإنشاء.
يجب أن نلاحظ أن التكاليف المتعلقة بالتخزين يتم تقييمها بناءً على كل معاملة: حتى لو تم قراءة/كتابة نفس المورد عدة مرات، فإنك تحتاج فقط إلى دفع الرسوم مرة واحدة.
استنادًا إلى الاعتبارات المذكورة أعلاه، قمنا بتعريف 6 معلمات لرسوم الوقود، والتي تشكل جزءًا من التكلفة الإجمالية لرسوم الوقود. انظر أدناه:
per_item_read: وفقًا لـ IOPs لتصحيح per_byte_read: حسب عرض النطاق الترددي الفعلي per_item_create:تعديل وفقًا للإجمالي المستهدف للمشروع per_byte_create: يتم المعايرة بناءً على الحجم الإجمالي المستهدف - يحتوي كل عنصر على 1KB الأول. per_item_write: مثل per_item_read per_byte_write: مثل per_byte_create
) تكلفة وحدة رسوم الوقود المستقرة
بغض النظر عن تكلفة تنفيذ العمليات حسب القيمة السوقية لـ APT أو العملات القانونية، يتطلب كل عملية وتجارة نفسها تكلفة وحدة ثابتة بالنسبة لتكاليف التخزين والتنفيذ. تساعد تكلفة وحدة الوقود الثابتة في الحفاظ على خطة رسوم الوقود ثابتة، وفصلها عن القيمة السوقية الحرة لـ APT. بالإضافة إلى ذلك، فإن الاختيار الصحيح لعدد الأرقام العشرية لوحدة الوقود يساعد في الحفاظ على خطة رسوم الوقود ثابتة. مع أخذ ذلك في الاعتبار، يُمثل الفريق وحدة رسوم الوقود بدقة تقارب 3 أرقام. لذلك، فإن تكلفة معاملات التحويل حوالي 700 وحدة من رسوم الوقود.
المشاركة المجتمعية
حتى مع بذل الكثير من الجهد في خطة رسوم الوقود، إلا أنها لا تزال غير مكتملة. ك مشروع مجتمعي، يمكن لأعضاء المجتمع اختيار:
كيف يمكن تعديل تكلفة رسوم الوقود؟
يتم تخزين خطة رسوم الوقود كإعداد داخل السلسلة، ولكن يمكن تعديلها من خلال مقترحات الحكم، ويمكن إضافة تعليمات جديدة أو ميزات أصلية بسلاسة.
تم تصميم خطة رسوم الوقود لتكون قابلة للتوسع، مما يسمح بترقيتها من خلال مقترحات الحوكمة. مع التحسين المستمر لـ MOVE VM ودمج ملاحظات المستخدمين، يمكن تعديل معلمات رسوم الوقود بمرور الوقت.
أحيانًا، قد تتطلب صيغة رسوم الوقود تغييرات معقدة تتجاوز التكوين داخل السلسلة. عادةً ما يتم ترميز هذه الصيغ باستخدام Rust، وتُميز من خلال علامات ميزات رسوم الوقود داخل السلسلة. لترقية هذه الصيغ، يجب تحديث برنامج العقد باستخدام الصيغة الجديدة، وتمييزها بعلامات ميزات رسوم وقود مختلفة. ثم يجب نشر برنامج العقد واعتماده بشكل كبير من قبل مشغلي العقد، وأخيرًا، يجب نشر واعتماد مقترح الحكم لاستخدام إصدار رسوم الوقود الجديد.
العمل المستقبلي
هذا هو إطار رسوم الوقود القابل للتطبيق الأول لـ MOVE. يتطلب تعديلات كبيرة على MOVE VM و Core. نأمل أن تمهد هذه الأعمال الطريق للأعمال المستقبلية:
1### خفض تكلفة التنفيذ، يمتلك نموذج حقيقي لرسوم الوقود يوضح مكان فعالية المترجم والآلة الافتراضية، يمكن للفريق تحسين معظمها لخفض تكلفة التنفيذ.
2) حساب تكلفة الوقود متعددة الأبعاد, يسمح للمستخدمين بتخصيص ميزانية منفصلة للتنفيذ والتخزين. بهذه الطريقة، لن يضطر المستخدمون لدفع أسعار مرتفعة لتكاليف الوقود بسبب وقت التنفيذ الطويل الناتج عن تطبيقات ذات كود ضعيف. كما سيسمح أيضًا بتعريف أكثر دقة لأقصى سعر لتكاليف الوقود للمعاملات على داخل السلسلة.
3) تخفيف حالة الانتفاخ، لا توجد حاليًا طرق بسيطة لتقليل مجموعة الحالة، باستثناء العقد ) أو المستخدم ( لحذف العناصر بشكل صريح. قد يؤدي دفع المستخدم لحذف البيانات إلى خلق فرص للمراجحة، حيث يقوم المستخدم بإنشاء التخزين عندما يكون رخيصًا، وحذفه عندما يكون مكلفًا. تأخير حل هذا التحدي قد يضعف دافع المطورين لحذف البيانات داخل السلسلة. الفريق يستكشف مفهوم TTL لكل مشروع، والذي سيؤدي إلى حذف عناصر الحالة غير المصرح بها عند انتهاء صلاحية TTL.