المؤلف: نيل سوماني ، مؤسس Eclipse ، الباحث الكمي السابق في Citadel ؛ الترجمة: Jinse Finance xiaozou
في Eclipse ، نقوم ببناء بنية تحتية مجمعة خاصة بالتطبيقات قابلة للتخصيص لدعم القطاعات العمودية مثل Gaming & Social و DePIN و DeFi.
لقد عملنا على هذا لمدة 10 أشهر أو نحو ذلك ، وأشعر بالحاجة إلى توضيح بعض المفاهيم الخاطئة. فيما يلي بعض الأفكار حول مجموعات التحديثات الخاصة بالتطبيق:
** 1. التقسيم الحالي للسوق خاطئ **
** (1) **** إطار التجميع ليس مؤسسة خيرية **
تعد أطر العمل التراكمية مثل OP Stack قواعد التعليمات البرمجية التي تنشر المكونات الرئيسية للمجموعات. لن يفرضوا عليك رسومًا مقابل استخدام الرمز ، لكنهم بحاجة إلى التقاط القيمة بطريقة ما. للتلخيص ، هناك ثلاثة أماكن يمكن الحصول على القيمة فيها:
التسوية: الجسر والتحقق من إثباتات الصلاحية أو إثباتات الخطأ
توافر البيانات: نشر أمر المعاملة
لكن التنفيذ فقط هو المناسب كنموذج عمل لإطار العمل التراكمي:
التسوية: بعد ترقية Bedrock ، تدفع شركة Optimism فقط رسوم تسوية تبلغ حوالي 5 دولارات أمريكية إلى Ethereum. تأتي بقية النفقات العامة لـ OP Stack من إصدار الكتل والرسوم ذات الصلة. قد تكسب بروتوكولات التسوية المتنافسة أقل من ذلك.
توفر البيانات: طبقات DA المجزأة أقل خطورة في تأمين الشبكة من طبقات إتاحة البيانات المشتركة (DA) مثل Celestia. لا ترغب العديد من المجموعات التراكمية في ترحيل DA الخاص بهم من Ethereum لأن ذلك من شأنه التضحية باتساقها مع Ethereum.
يجب أن يشتمل أي جزء من السوق على أطر عمل تراكمية في فئة واحدة على الأقل مرتبطة بالتنفيذ ، وأي منتج يوفر خدمات التنفيذ يمكن أن يتنافس مع أطر التجميع.
** (2) التراكم المعزول كخدمة (Raa **** S ****) غير مقبول **
التفسير الساذج لـ RaaS هو في الواقع ** جهاز التسلسل المعزول كخدمة (iSaaS) **. هذه الشركات ليس لديها بروتوكول خاص بها ، لكنها تنشر إطار عمل تراكمي مفتوح المصدر موجود وتقوم بتشغيل جهاز التسلسل. OP Stack لديها شراكة مع iSaaS.
يتمثل نموذج أعمال iSaaS في فرض بعض الرسوم القانونية المتكررة بالإضافة إلى فرض نسبة مئوية من رسوم جهاز التسلسل. (لا تمثل خدمات الدعم الإضافية أو الاستشارات أو تطوير الميزات المخصصة نموذج أعمال قابل للتطوير.) لتوضيح ذلك ، سيكون هذا منافسًا مباشرًا لشبكات التسلسل المشتركة مثل Espresso و Astria و Radius وما إلى ذلك ؛ ولكن لديهم أيضًا بعض عيوب قاتلة.
مشكلة كبيرة في iSaaS هي أنه لا يتوافق مع إطار عمل التجميع. كما هو مذكور أعلاه ، يجب على إطار العمل المتفائل للتجميع مثل OP Stack تسييل رسوم الفرز. (قد يكون إطار عمل zk-rollup قادرًا على تجاهل رسوم الطلب والاحتفاظ فقط برسوم المُثبِّت.)
المشاكل الأخرى عالية المستوى مع هذا النوع من الأعمال هي أنه سلعي ، وسهل الدخول ، وليس له أي تأثيرات على الشبكة ، على عكس النظام المشترك. يفتقر iSaaS إلى وفورات الحجم الخاصة بالمسلسلات المشتركة لأن كل جهاز تسلسل معزول.
** (3) **** O **** p **** timistic ** ** يجب أن يوفر إطار مجموعة التحديثات S **** aaS **
من أجل الأداء الجيد ، قد تعيد iSaaS رسوم التسلسل إلى إطار تراكمي متفائل ، تاركًا رسومًا متكررة فقط.
ولكن الآن يجب أن تكون كل من أطر عمل iSaaS و Rollup مربحة بشكل مستقل. سيكون التسعير المثالي للمؤسسات الكبيرة عبارة عن مدفوعات قانونية عالية متكررة ، ولكن رسوم منخفضة للطلب. ومع ذلك ، لا تتمتع iSaaS بالمرونة لتقليل رسوم الطلب ، لأن رسوم الطلب لا تنتمي إليهم في الأصل ، ولكن يتم إرجاعها مرة أخرى إلى إطار عمل التجميع. إذا لم تشارك iSaaS الإيرادات مع إطار عمل التجميع ، فيمكن لإطار عمل التجميع نشر iSaaS الخاص به ، وبما أن الثقة قد تم تأسيسها بالفعل ، فقد يخترق السوق بشكل أعمق.
السبب في ظهور الكثير من iSaaS هو أنه يبدو جذابًا للقراء الأقل خبرة. يبدو مثل SaaS ، لذلك قد يجد المستثمرون غير المشفرون أنه من الأسهل استقراء الدخل الإلزامي. لكن iSaaS ستكافح من أجل التنافس مع أطر العمل التراكمية التي لها SaaS الخاصة بها مع إيرادات ورموز بروتوكول أصلية. هذا الأخير لديه المزيد من الخيارات من حيث التسعير ، يمكن استخدام الرموز المميزة لدعم المشاريع الواعدة ، ودعم تكاليف اكتساب العملاء وتكاليف التشغيل الثابتة (الموضحة أدناه).
ستؤدي تأثيرات الشبكة الأصلية ومشاركة التكلفة الثابتة إلى إنشاء اقتصاديات وحدة أقوى للبروتوكولات ذات الرؤية الأعلى ، مما يجعل موفري التجميع الفائزين إلى حد ما.
** (4) خريطة السوق المعدلة **
يمكنني الآن إظهار كيف قمت بتعديل الرسومات في مقالة Messari ، والتي اعتقدت أنها تبدو معقولة في ذلك الوقت:
سأقوم بإعادة تسمية فئة "No Code Deployment" و Rollup SDK إلى Rollup Frameworks لأن العديد من أطر عمل Rollup لا توفر حزمة SDK كاملة للمطورين. أود أيضًا تعديل هذا الرسم التخطيطي لنظام سيليستيا البيئي:
سأزيل RaaS وطبقة الفوترة والأجهزة الافتراضية. بالنسبة للمشاريع التي تندرج تحت فئة Rollup Framework ، فمن شبه المؤكد أنها ستجد نفسها في فئة أخرى أيضًا ، أو أنها لن تكون مربحة.
** 2. ليس هناك غداء مجاني: قيود اقتصادية وتقنية **
** (1) لا ينبغي أن يكون لمعظم التطبيقات r **** ollup **
أسهل طريقة لإثبات اقتصاديات مجموعة التحديثات لتطبيق معين هي إلقاء نظرة على المجموعات الحية: التفاؤل (بعد ترقية Bedrock). هذا هو النهج الذي اتخذه فريق التفاؤل لإنشاء لوحة معلومات الكثبان الرملية.
يفترض ما يلي أن سعر الغاز على Ethereum هو حوالي 25 gwei:
· تبلغ تكلفة النشر لمرة واحدة لسلسلة الشبكة الرئيسية لـ OP Stack حوالي 1 ETH
· التكلفة الثابتة لسلسلة OP Stack (حتى لو كان عدد المعاملات الجارية هو 0) هي حوالي 0.5 ETH في اليوم
للحصول على التكلفة الثابتة ، قمت بضرب متوسط التكلفة العامة لكل معاملة في عدد المعاملات الجارية في ذلك اليوم وأكدت من خلال تشغيل سلسلة OP Stack على mainnet.
هذه التكلفة المتغيرة منخفضة ، ولكنها ليست منخفضة على مستوى Solana ، ويمكن إطفاء التكلفة الثابتة في العديد من المعاملات. في EIP-4844 في المستقبل ، يمكننا أن نفترض جيدًا أن هذه التكلفة تنخفض بمعامل 10. ومع ذلك ، لنفترض أن سعر ETH البالغ 2000 دولار يمثل حدًا أدنى قدره 0.015 دولارًا لكل معاملة بالإضافة إلى بعض التكاليف الثابتة المطفأة.
قد نعتبر 0.00001 ETH (حوالي 0.02 دولار في وقت كتابة هذا التقرير) كرمز معاملات معقول لتغطية هذه التكلفة الثابتة ، لذلك سنحتاج إلى 50000 معاملة يوميًا حتى تكون مجموعة تطبيقات معينة جديرة بالاهتمام. قبل EIP-4844 ، كان السعر حوالي 0.17 دولارًا لكل معاملة ، وبشكل متفائل ، بعد EIP-4844 ، كان 0.03 دولارًا لكل معاملة. قد نضيف علاوة صغيرة ، وبالتالي فإن سلسلة دعم فارز (المشتركة) اقتصادية.
لذا ، في حين أن شيئًا مثل Opclave رائع (تعجبني حقًا الفكرة ، فنحن نتحدث مع فريق Dogan أننا قد ندمج هذه الوظيفة في Eclipse rollup) ، إلا أنه لا معنى له كسلسلة mainnet OP Stack. القيد هنا هو أن سلسلة OP Stack ترتكز على Ethereum ، التي تعد مساحة الكتلة الخاصة بها باهظة الثمن ، والقصد من التفاؤل هو أن تكون متسقة مع Ethereum.
بالنظر إلى اقتصاديات الوحدة هذه ، فإن مشاريع DeFi dApps و NFT الصغيرة لا معنى لها في سلاسلها الخاصة. بالنسبة لهذه dApps ، قد يكون من المنطقي دعم تكاليف الغاز إذا كانت اقتصاديات الوحدة طويلة الأجل في Ethereum L2 منطقية بالنسبة إلى dApps الخاصة بهم ، أو قد يكونون على استعداد لتحمل الخسارة في appchain الخاصة بهم.
إذا كان التطبيق يتطلب قدرًا كبيرًا جدًا من المعاملات ، فلن تعمل مجموعة التحديثات المرتبطة بـ Ethereum أيضًا ، نظرًا لأن رسوم المعاملات التي تزيد عن 0.01 دولار أمريكي قد تكون مرتفعة للغاية. ستتطلب هذه الأنواع من التطبيقات نهجًا جديدًا ، مثل الأسلوب الذي يبنيه Eclipse باستخدام أجهزتنا الافتراضية المتوازية للغاية وبنية التجميع السيادية.
** (2) يجب تقييد مجموعة التحديثات القابلة للتخصيص **
كما ذكرنا أعلاه ، لن يتم تضمين OP Hacks في سلسلة التفاؤل الفائقة. هذا أمر منطقي لأنه من أجل التسوية بشكل صحيح أو توفير ترتيب الحالة للتجميع ، نحتاج إلى أن تكون بعض الثوابت صحيحة. يجب مراجعة أي تعديلات قبل دعم القيمة الاقتصادية الحقيقية.
سبب وجيه آخر لتقييد مجموعات التحديثات الخاصة بالتطبيق هو النظر في اعتماد Cosmos. يعد Cosmos SDK عامًا جدًا ، ولكنه لم يتسبب أبدًا في العدد الهائل من السلاسل المختلفة التي قد تتوقعها. قد يكون هذا بسبب أن عملية التخصيص تتطلب الكثير من التعقيد التقني ، أو على الأرجح لأن الذيل الطويل للتطبيق مناسب تمامًا لعدد صغير من البنى. من ناحية أخرى ، يمكن للقوالب الخاصة بالمجال أن تعالج نقاط الألم الشائعة عبر قطاعات مختلفة وتوفر بنية قابلة للتكرار.
شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
مؤسس Eclipse: بعض سوء الفهم حول RaaS
المؤلف: نيل سوماني ، مؤسس Eclipse ، الباحث الكمي السابق في Citadel ؛ الترجمة: Jinse Finance xiaozou
في Eclipse ، نقوم ببناء بنية تحتية مجمعة خاصة بالتطبيقات قابلة للتخصيص لدعم القطاعات العمودية مثل Gaming & Social و DePIN و DeFi.
لقد عملنا على هذا لمدة 10 أشهر أو نحو ذلك ، وأشعر بالحاجة إلى توضيح بعض المفاهيم الخاطئة. فيما يلي بعض الأفكار حول مجموعات التحديثات الخاصة بالتطبيق:
** 1. التقسيم الحالي للسوق خاطئ **
** (1) **** إطار التجميع ليس مؤسسة خيرية **
تعد أطر العمل التراكمية مثل OP Stack قواعد التعليمات البرمجية التي تنشر المكونات الرئيسية للمجموعات. لن يفرضوا عليك رسومًا مقابل استخدام الرمز ، لكنهم بحاجة إلى التقاط القيمة بطريقة ما. للتلخيص ، هناك ثلاثة أماكن يمكن الحصول على القيمة فيها:
التنفيذ: أوامر المعاملات والتنفيذ وإثباتات (zk-rollup)
التسوية: الجسر والتحقق من إثباتات الصلاحية أو إثباتات الخطأ
توافر البيانات: نشر أمر المعاملة
لكن التنفيذ فقط هو المناسب كنموذج عمل لإطار العمل التراكمي:
التسوية: بعد ترقية Bedrock ، تدفع شركة Optimism فقط رسوم تسوية تبلغ حوالي 5 دولارات أمريكية إلى Ethereum. تأتي بقية النفقات العامة لـ OP Stack من إصدار الكتل والرسوم ذات الصلة. قد تكسب بروتوكولات التسوية المتنافسة أقل من ذلك.
توفر البيانات: طبقات DA المجزأة أقل خطورة في تأمين الشبكة من طبقات إتاحة البيانات المشتركة (DA) مثل Celestia. لا ترغب العديد من المجموعات التراكمية في ترحيل DA الخاص بهم من Ethereum لأن ذلك من شأنه التضحية باتساقها مع Ethereum.
يجب أن يشتمل أي جزء من السوق على أطر عمل تراكمية في فئة واحدة على الأقل مرتبطة بالتنفيذ ، وأي منتج يوفر خدمات التنفيذ يمكن أن يتنافس مع أطر التجميع.
** (2) التراكم المعزول كخدمة (Raa **** S ****) غير مقبول **
التفسير الساذج لـ RaaS هو في الواقع ** جهاز التسلسل المعزول كخدمة (iSaaS) **. هذه الشركات ليس لديها بروتوكول خاص بها ، لكنها تنشر إطار عمل تراكمي مفتوح المصدر موجود وتقوم بتشغيل جهاز التسلسل. OP Stack لديها شراكة مع iSaaS.
يتمثل نموذج أعمال iSaaS في فرض بعض الرسوم القانونية المتكررة بالإضافة إلى فرض نسبة مئوية من رسوم جهاز التسلسل. (لا تمثل خدمات الدعم الإضافية أو الاستشارات أو تطوير الميزات المخصصة نموذج أعمال قابل للتطوير.) لتوضيح ذلك ، سيكون هذا منافسًا مباشرًا لشبكات التسلسل المشتركة مثل Espresso و Astria و Radius وما إلى ذلك ؛ ولكن لديهم أيضًا بعض عيوب قاتلة.
مشكلة كبيرة في iSaaS هي أنه لا يتوافق مع إطار عمل التجميع. كما هو مذكور أعلاه ، يجب على إطار العمل المتفائل للتجميع مثل OP Stack تسييل رسوم الفرز. (قد يكون إطار عمل zk-rollup قادرًا على تجاهل رسوم الطلب والاحتفاظ فقط برسوم المُثبِّت.)
المشاكل الأخرى عالية المستوى مع هذا النوع من الأعمال هي أنه سلعي ، وسهل الدخول ، وليس له أي تأثيرات على الشبكة ، على عكس النظام المشترك. يفتقر iSaaS إلى وفورات الحجم الخاصة بالمسلسلات المشتركة لأن كل جهاز تسلسل معزول.
** (3) **** O **** p **** timistic ** ** يجب أن يوفر إطار مجموعة التحديثات S **** aaS **
من أجل الأداء الجيد ، قد تعيد iSaaS رسوم التسلسل إلى إطار تراكمي متفائل ، تاركًا رسومًا متكررة فقط.
ولكن الآن يجب أن تكون كل من أطر عمل iSaaS و Rollup مربحة بشكل مستقل. سيكون التسعير المثالي للمؤسسات الكبيرة عبارة عن مدفوعات قانونية عالية متكررة ، ولكن رسوم منخفضة للطلب. ومع ذلك ، لا تتمتع iSaaS بالمرونة لتقليل رسوم الطلب ، لأن رسوم الطلب لا تنتمي إليهم في الأصل ، ولكن يتم إرجاعها مرة أخرى إلى إطار عمل التجميع. إذا لم تشارك iSaaS الإيرادات مع إطار عمل التجميع ، فيمكن لإطار عمل التجميع نشر iSaaS الخاص به ، وبما أن الثقة قد تم تأسيسها بالفعل ، فقد يخترق السوق بشكل أعمق.
السبب في ظهور الكثير من iSaaS هو أنه يبدو جذابًا للقراء الأقل خبرة. يبدو مثل SaaS ، لذلك قد يجد المستثمرون غير المشفرون أنه من الأسهل استقراء الدخل الإلزامي. لكن iSaaS ستكافح من أجل التنافس مع أطر العمل التراكمية التي لها SaaS الخاصة بها مع إيرادات ورموز بروتوكول أصلية. هذا الأخير لديه المزيد من الخيارات من حيث التسعير ، يمكن استخدام الرموز المميزة لدعم المشاريع الواعدة ، ودعم تكاليف اكتساب العملاء وتكاليف التشغيل الثابتة (الموضحة أدناه).
ستؤدي تأثيرات الشبكة الأصلية ومشاركة التكلفة الثابتة إلى إنشاء اقتصاديات وحدة أقوى للبروتوكولات ذات الرؤية الأعلى ، مما يجعل موفري التجميع الفائزين إلى حد ما.
** (4) خريطة السوق المعدلة **
يمكنني الآن إظهار كيف قمت بتعديل الرسومات في مقالة Messari ، والتي اعتقدت أنها تبدو معقولة في ذلك الوقت:
! [GOMqBBKqeklIYCZONYBwrO91yeaKEYMt1yw62hAq.png] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-4f03a230ec-dd1a6f-1c6801 "7078763")
! [DDAGSwDQemfdoIrAt1AXbUYzy29kVVeJ7uVjQru1.png] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-cc06a2010b-dd1a6f-1c6801 "7078764")
سأقوم بإعادة تسمية فئة "No Code Deployment" و Rollup SDK إلى Rollup Frameworks لأن العديد من أطر عمل Rollup لا توفر حزمة SDK كاملة للمطورين. أود أيضًا تعديل هذا الرسم التخطيطي لنظام سيليستيا البيئي:
! [L42KJQuXr6KSHoHYY6RQTOT6vaAdhLeRKmqxd3Vd.png] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-1ae468374a-dd1a6f-1c6801 "7078765")
! [b1wCKXfuk8dja117BvKq1Q3vT4hSdpqdXXQkYiix.png] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-2f724c75a1-dd1a6f-1c6801) "7078766"
سأزيل RaaS وطبقة الفوترة والأجهزة الافتراضية. بالنسبة للمشاريع التي تندرج تحت فئة Rollup Framework ، فمن شبه المؤكد أنها ستجد نفسها في فئة أخرى أيضًا ، أو أنها لن تكون مربحة.
** 2. ليس هناك غداء مجاني: قيود اقتصادية وتقنية **
** (1) لا ينبغي أن يكون لمعظم التطبيقات r **** ollup **
أسهل طريقة لإثبات اقتصاديات مجموعة التحديثات لتطبيق معين هي إلقاء نظرة على المجموعات الحية: التفاؤل (بعد ترقية Bedrock). هذا هو النهج الذي اتخذه فريق التفاؤل لإنشاء لوحة معلومات الكثبان الرملية.
يفترض ما يلي أن سعر الغاز على Ethereum هو حوالي 25 gwei:
· تبلغ تكلفة النشر لمرة واحدة لسلسلة الشبكة الرئيسية لـ OP Stack حوالي 1 ETH
· التكلفة الثابتة لسلسلة OP Stack (حتى لو كان عدد المعاملات الجارية هو 0) هي حوالي 0.5 ETH في اليوم
· التكلفة المتغيرة 7.5 \ * 10 ^ -5 إيثريوم لكل معاملة
للحصول على التكلفة الثابتة ، قمت بضرب متوسط التكلفة العامة لكل معاملة في عدد المعاملات الجارية في ذلك اليوم وأكدت من خلال تشغيل سلسلة OP Stack على mainnet.
هذه التكلفة المتغيرة منخفضة ، ولكنها ليست منخفضة على مستوى Solana ، ويمكن إطفاء التكلفة الثابتة في العديد من المعاملات. في EIP-4844 في المستقبل ، يمكننا أن نفترض جيدًا أن هذه التكلفة تنخفض بمعامل 10. ومع ذلك ، لنفترض أن سعر ETH البالغ 2000 دولار يمثل حدًا أدنى قدره 0.015 دولارًا لكل معاملة بالإضافة إلى بعض التكاليف الثابتة المطفأة.
قد نعتبر 0.00001 ETH (حوالي 0.02 دولار في وقت كتابة هذا التقرير) كرمز معاملات معقول لتغطية هذه التكلفة الثابتة ، لذلك سنحتاج إلى 50000 معاملة يوميًا حتى تكون مجموعة تطبيقات معينة جديرة بالاهتمام. قبل EIP-4844 ، كان السعر حوالي 0.17 دولارًا لكل معاملة ، وبشكل متفائل ، بعد EIP-4844 ، كان 0.03 دولارًا لكل معاملة. قد نضيف علاوة صغيرة ، وبالتالي فإن سلسلة دعم فارز (المشتركة) اقتصادية.
لذا ، في حين أن شيئًا مثل Opclave رائع (تعجبني حقًا الفكرة ، فنحن نتحدث مع فريق Dogan أننا قد ندمج هذه الوظيفة في Eclipse rollup) ، إلا أنه لا معنى له كسلسلة mainnet OP Stack. القيد هنا هو أن سلسلة OP Stack ترتكز على Ethereum ، التي تعد مساحة الكتلة الخاصة بها باهظة الثمن ، والقصد من التفاؤل هو أن تكون متسقة مع Ethereum.
بالنظر إلى اقتصاديات الوحدة هذه ، فإن مشاريع DeFi dApps و NFT الصغيرة لا معنى لها في سلاسلها الخاصة. بالنسبة لهذه dApps ، قد يكون من المنطقي دعم تكاليف الغاز إذا كانت اقتصاديات الوحدة طويلة الأجل في Ethereum L2 منطقية بالنسبة إلى dApps الخاصة بهم ، أو قد يكونون على استعداد لتحمل الخسارة في appchain الخاصة بهم.
إذا كان التطبيق يتطلب قدرًا كبيرًا جدًا من المعاملات ، فلن تعمل مجموعة التحديثات المرتبطة بـ Ethereum أيضًا ، نظرًا لأن رسوم المعاملات التي تزيد عن 0.01 دولار أمريكي قد تكون مرتفعة للغاية. ستتطلب هذه الأنواع من التطبيقات نهجًا جديدًا ، مثل الأسلوب الذي يبنيه Eclipse باستخدام أجهزتنا الافتراضية المتوازية للغاية وبنية التجميع السيادية.
** (2) يجب تقييد مجموعة التحديثات القابلة للتخصيص **
! [3IRIiwFDn000XSewLTo28x1rw6ikxESbnzRXj2XN.png] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-b8d7c4a7b3-dd1a6f-1c6801) "7078768"
كما ذكرنا أعلاه ، لن يتم تضمين OP Hacks في سلسلة التفاؤل الفائقة. هذا أمر منطقي لأنه من أجل التسوية بشكل صحيح أو توفير ترتيب الحالة للتجميع ، نحتاج إلى أن تكون بعض الثوابت صحيحة. يجب مراجعة أي تعديلات قبل دعم القيمة الاقتصادية الحقيقية.
سبب وجيه آخر لتقييد مجموعات التحديثات الخاصة بالتطبيق هو النظر في اعتماد Cosmos. يعد Cosmos SDK عامًا جدًا ، ولكنه لم يتسبب أبدًا في العدد الهائل من السلاسل المختلفة التي قد تتوقعها. قد يكون هذا بسبب أن عملية التخصيص تتطلب الكثير من التعقيد التقني ، أو على الأرجح لأن الذيل الطويل للتطبيق مناسب تمامًا لعدد صغير من البنى. من ناحية أخرى ، يمكن للقوالب الخاصة بالمجال أن تعالج نقاط الألم الشائعة عبر قطاعات مختلفة وتوفر بنية قابلة للتكرار.