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

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

أفهم أنها حالة واقعية لتنفيذ فكرة Execution-as-a-Service. العديد من L1 يتفاخرون بـ"الأداء العالي"، ولكن عندما يزداد عدد المستخدمين، تنفجر الأمور؛ نظام Sonic الذي يتضمن آلية VM + رسوم ديناميكية، يمكن من الناحية النظرية أن يخفف من مشكلة الزيادة المفاجئة في حركة المرور.

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