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

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

المبادئ التي نشاركها هنا تنطبق على جميع تطبيقات web3 — من DeFi إلى تطبيقات التواصل الاجتماعي اللامركزية، وشبكات DePIN، وفي كل مكان بينهما.

تحديات نماذج الرمز

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

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

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

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

تتمحور حلولنا على حل ثلاث مشاكل تواجه الرموز التطبيقية المتعلقة بـ:

1. التحديات فيما يتعلق بالحوكمة
2. تحديات في توزيع القيمة
3. التحديات مع النشاط المنظم

1. التحديات في الحوكمة

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

2. التحديات في توزيع القيمة

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

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

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

3. التحديات المتعلقة بالنشاط المنظم

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

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

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

مشكلة أساسية واحدة: تتبع الرسوم

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

لجعل الرسوم قابلة للتتبع ، يمكن أن يستخدم البروتوكول تصميم نظام رهان عملة مشفرة بخطوتين.

الخطوة 1: التعرف على الواجهة الأمامية التي نشأت الرسوم، و

الخطوة 2: توجيه الرسوم إلى مجموعات مختلفة بناءً على منطق مخصص.

تعيين واجهات المستخدم الأمامية

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

رسوم التوجيه

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

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

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

تحديد رسوم التتبع من خلال التنقيح

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

يمكن App.xyz اتباع قواعد امتثال محددة للولاية القضائية التي يقع فيها. نشاط التطبيق الذي نشأ من app.xyz يولد رسوم البروتوكول. App.xyz لديها وحدة Staking الخاصة بها ، ويمكن لحاملي الرموز المميزة مشاركة الرموز المميزة الخاصة بهم في تلك الوحدة مباشرة أو إلى أمين يريد اختيار سلة من الواجهات الأمامية التي يرونها متوافقة بشكل فردي. سيكسب هؤلاء المخزنون الرمزيون عائدا في شكل رسوم من مجموعة الواجهات الأمامية التي يشاركون فيها. إذا كانت الواجهة الأمامية تولد رسوما بقيمة 100 دولار ، وكان كل كيان 100 يخزن رمزا مميزا واحدا ، فيحق لكل كيان الحصول على 1 دولار. يمكن للقيمين في البداية فرض رسوم مقابل خدماتهم. في المستقبل ، يمكن للحكومات تقديم شهادات على السلسلة حول امتثال الواجهات الأمامية في ولايتها القضائية للمساعدة في حماية المستهلكين ، مع الفائدة الإضافية المتمثلة في أتمتة التنظيم.

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

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

من النظرية إلى التنفيذ: وضع الطريقة في التطبيق

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

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

1. يمكن لعميل واجهة المستخدم الأمامية بعد ذلك استدعاء وظيفة التسجيل() وإثبات أنه يمتلك اسم النطاق الخاص به. يتم تخزين رسم خريطة للنطاق إلى مفتاح الشهادة العام والعكس صحيح.
2. عند إنشاء المعاملات من خلال العميل، يقوم أيضًا بتوقيع حمولة المعاملة بمفتاحه العام للشهادة. يتم تمرير هذه إلى عقود تطبيقات الذكاء الاصطناعي في حزمة.
3. يقوم العقود الذكية للتطبيق بالتحقق من الشهادة والتحقق من أنها تتطابق مع جسم التحويل الصحيح وتم تسجيلها. إذا كان الأمر كذلك، يتم معالجة المعاملة. ثم يتم إرسال الرسوم التي تم توليدها بواسطة المعاملة إلى عقد FeeCollector مع اسم النطاق (من السجل).
4. يسمح لمجمع الرسوم للمحللين والمستخدمين والموثقين وغيرهم بالمراهنة على الرموز مباشرة على نطاق أو مجموعة من النطاقات. يجب على هذه العقود تتبع كمية الرموز المراهنة على كل نطاق ونسبة كل عنوان من تلك المراهنة وكمية الوقت التي تم فيها المراهنة. يمكن استخدام تنفيذات شهيرة لتعدين السيولة كنقطة انطلاق لمنطق هذه العقدة.
5. يمكن للمستخدمين الذين قد رهنوا للمشرفين (أو مباشرة لعقود إدارة الرسوم أنفسها) سحب حصة متناسبة من الرسوم وفقًا لكمية رمز التطبيق المرهون للنطاق. يمكن أن يكون التركيب مشابهًا لـميتامورفو/مورفو بلو.

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

اعتبارات إضافية استنادًا إلى نوع التطبيق

على الرغم من أن هذه المبادئ تنطبق على نطاق واسع على نماذج الاقتصادية للرموز التطبيقية ، إلا أن هناك اعتبارات أخرى للرسوم بناءً على نوع التطبيق: التطبيقات المبنية على الطبقة 1 أو الطبقة 2 ، وسلاسل التطبيقات ، والتطبيقات المبنية باستخدام تعزيزات. [Gate] rollups.

الأخذ بعين الاعتبار لتطبيقات L1 / L2

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

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

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

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

سيعكس خط الرسوم أمثلة المقدمة في الأبواب السابقة.

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

الاعتبارات المتعلقة بسلاسل التطبيقات

Appchains are application-specific blockchains with validators that work only for that application.

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

في هذا النموذج، يجب على حاملي الرموز الرهان على المحققين لتلقي المكافآت. يصبح المحققون وحدات الرهان المنتقاة.

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

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

الاعتبارات المتعلقة بتطبيق البكرات

لدى Rollups مساحة كتلها الخاصة ولكنها يمكن أن ترث أمان سلسلة أخرى. يتحمل معظم Rollups اليوم تسلسلًا وإدراجًا للمعاملات من قبل مسلسل واحد فقط ، على الرغم من أنه يمكن تقديم المعاملات مباشرة إلى الطبقة 1 من خلال عملية تسمى "".الإدراج القسري”

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

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

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

تنويه:

1. تم نشر هذه المقالة من [Gatea16zcrypto]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [Mason HallPorter SmithMiles Jennings و Ross Shuel]. إذا كان هناك اعتراضات على هذا النشر مرجع، يرجى الاتصال بالبوابة تعلمفريق Gate، وسيتعاملون معه على الفور.
2. تنصل المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك للكاتب ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقال إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر ذلك، فإن نسخ أو توزيع أو سرقة المقالات المترجمة ممنوعة.