رموز البنية التحتية - المقابلة لشبكة الطبقة 1 (أو الجزء المجاور في مكدس الحوسبة، مثل الطبقة 2) ) - نماذجها الاقتصادية ناضجة ومفهومة على نطاق واسع، وتعتمد هذه النماذج على العرض والطلب على مساحة الكتلة. ولكن بالنسبة لرموز التطبيقات - بروتوكولات العقود الذكية التي تنشر الخدمات فوق سلاسل الكتل التي تنقل الحقوق في "الأعمال الموزعة" - لا يزال النموذج الاقتصادي قيد الإعداد.
يجب أن يكون نموذج العمل الخاص بالرمز المميز للتطبيق معبرًا مثل البرنامج الأساسي الخاص به. ولتحقيق هذه الغاية، قدمنا التدفق النقدي لرموز التطبيقات - وهو أسلوب يمكّن التطبيقات من إنشاء نماذج مرنة ومتساهلة حيث يمكن للمستخدمين اختيار كيفية مكافأتهم مقابل القيمة التي يقدمونها. يفرض هذا النهج رسومًا على الأنشطة القانونية في ولايات قضائية مختلفة، مما يشجع على قدر أكبر من الامتثال. وفي الوقت نفسه، يعمل أيضًا على زيادة القيمة المتراكمة للبروتوكول إلى الحد الأقصى مع تشجيع الحد الأدنى من الإدارة.
تنطبق المبادئ التي نشاركها هنا على جميع تطبيقات web3 - بدءًا من التمويل اللامركزي (DeFi) إلى التطبيقات الاجتماعية اللامركزية وشبكات DePIN و كل شيء بينهما.
التحديات التي تواجه نموذج الرمز المميز
تخضع الرموز المميزة للبنية التحتية للعرض والطلب المضمنين: عندما يزيد الطلب، ينخفض العرض، ويتم ضبط السوق وفقًا لذلك. تم تسريع هذا الأساس الاقتصادي الأصلي للعديد من رموز البنية التحتية من خلال اقتراح تحسين إيثريوم 1559 (EIP-1559)، والذي طبق الرسوم الأساسية لجميع معاملات إيثريوم التي سيتم حرقها. ولكن على الرغم من المحاولات المتفرقة لشراء النماذج وحرقها، فإن الرموز المميزة للتطبيق ليس لها نموذج مشابه لـ EIP-1559.
التطبيقات مستهلكون لمساحة الكتلة، وليسوا مزودين، لذلك لا يمكنهم الاعتماد على استخدام مساحة الكتلة الخاصة بهم من فواتير الغاز التي تم جمعها من قبل الآخرين هناك . ولهذا السبب يحتاجون إلى تطوير نماذجهم الاقتصادية الخاصة.
هناك أيضًا بعض التحديات القانونية هنا: النموذج الاقتصادي لرموز البنية التحتية أقل تعقيدًا بسبب الطبيعة العامة لمعاملات blockchain النموذجية والآليات البرمجية التي تستخدمها. تخضع للمخاطر القانونية. ولكن بالنسبة للنموذج الاقتصادي الذي يحتوي على رموز التطبيق، قد تعتمد التطبيقات المعنية على تسهيل الأنشطة المنظمة وقد تتطلب وسطاء للتحكم في حاملي الرموز المميزة - مما يجعل الاقتصاد أكثر تعقيدًا. بورصة لا مركزية تسهل تداول المشتقات التي تخضع لرقابة صارمة في الولايات المتحدة وتختلف تمامًا عن الإيثريوم.
إن الجمع بين هذه التحديات الداخلية والخارجية يعني أن الرموز المميزة للتطبيق تتطلب نموذجًا اقتصاديًا مختلفًا. مع أخذ ذلك في الاعتبار، نقترح حلاً ممكنًا: طريقة لتصميم البروتوكول لتعويض حاملي الرموز المميزة للتطبيق عن الخدمات المقدمة مع زيادة إيرادات البروتوكول إلى الحد الأقصى، وتحفيز الامتثال التنظيمي، ودمج تقليل الحوكمة. هدفنا بسيط: منح الرموز المميزة للتطبيق نفس الأساس الاقتصادي من خلال التدفق النقدي الذي تتمتع به العديد من الرموز المميزة للبنية التحتية بالفعل.
يركز حلنا على حل ثلاث مشكلات تواجهها الرموز المميزة للتطبيق:
< li>تحديات الحوكمة
تحديات توزيع القيمة
تحديات توزيع القيمة
p>التحديات في الأنشطة الخاضعة للتنظيم
1. تحديات الحوكمة
عادةً ما تتمتع الرموز المميزة للتطبيقات بحقوق الإدارة، وقد يؤدي وجود المنظمات المستقلة اللامركزية (DAOs) إلى إزالة عدم اليقين الذي لا تملكه الرموز المميزة للبنية التحتية. بالنسبة للمنظمات اللامركزية المستقلة التي لديها عمليات كبيرة في الولايات المتحدة، قد تنشأ المخاطر إذا كانت المنظمة اللامركزية المستقلة لديها سيطرة على إيرادات البروتوكول أو الوسطاء وبرامج الأنشطة الاقتصادية للبروتوكول. لتجنب هذه المخاطر، يمكن للمشاريع القضاء على سيطرة DAO عن طريق تقليل الإدارة. بالنسبة للمنظمات اللامركزية غير القادرة على القيام بذلك، توفر الجمعية اللامركزية غير المدمجة غير الربحية (DUNA) الجديدة في وايومنغ كيانًا قانونيًا لا مركزيًا قد يساعد في تخفيف هذه المخاطر والامتثال لقوانين الضرائب المعمول بها.
2. تحديات تعيين القيمة
يجب الاهتمام بتصميم التطبيق يجب أخذها أيضًا عند تصميم آلية تخصيص القيمة لحاملي الرمز المميز. قد يثير الجمع بين حقوق التصويت والحقوق الاقتصادية مخاوف بموجب قوانين الأوراق المالية الأمريكية، وخاصة الآليات البسيطة والمباشرة مثل التقسيم وتدمير شراء العملات الرمزية. تبدو هذه الآليات مشابهة لتوزيعات الأرباح وعمليات إعادة شراء الأسهم، مما قد يقوض الحجة القائلة بأن الرموز المميزة يجب أن يكون لها إطار تنظيمي مختلف عن الأسهم.
يجب أن تستكشف المشاريع رأسمالية أصحاب المصلحة - مكافأة حاملي الرموز المميزة على مساهمتهم في المشروع بطريقة تفيد مساهمة المشروع. تشجع العديد من المشاريع المشاركة النشطة، بما في ذلك تشغيل الواجهة الأمامية (Liquity)، والمشاركة في البروتوكول (Goldfinch)، والضمانات كجزء من وحدة الأمان (Aave). مساحة التصميم هنا مفتوحة للغاية، ولكن نقطة البداية الجيدة هي إدراج جميع أصحاب المصلحة في المشروع، وتحديد السلوكيات التي ينبغي تشجيعهم على القيام بها، وتحديد القيمة الإجمالية التي يمكن أن يخلقها البروتوكول من خلال هذا الحافز.
من أجل التبسيط، سنفترض في هذه المقالة نموذج تعويض بسيط يكافئ حاملي الرموز المميزة للمشاركة في الحوكمة، على الرغم من وجود خطط أخرى.
3. تحديات الأنشطة الخاضعة للتنظيم
الترويج للأنشطة الخاضعة للتنظيم يجب أيضًا أن تكون التطبيقات التي تنظم النشاط حذرة عند تصميم آليات لتراكم القيمة لحاملي الرمز المميز. إذا تراكمت قيمة هذه الآليات من الواجهات الأمامية أو واجهات برمجة التطبيقات غير المرخصة التي لا تتوافق مع القوانين المعمول بها، فقد يستفيد حاملو الرمز المميز من الأنشطة غير القانونية.
تركز معظم الحلول المقترحة لهذه المشكلة على الحد من تراكم القيمة في الأنشطة المسموح بها في الولايات المتحدة - على سبيل المثال، فقط لتلك التي تنطوي على أصول معينة. تم تفعيل رسوم البروتوكول الخاصة بمجمع السيولة. وهذا يُخضع المشاريع لأدنى قاسم مشترك للنهج التنظيمية ويقوض عرض القيمة لبروتوكولات البرمجيات العالمية المستقلة. وهذا أيضًا يقوض بشكل مباشر جهود التقليل من الحوكمة. إن تحديد استراتيجية الرسوم الممكنة من منظور الامتثال التنظيمي ليس مهمة مناسبة للمنظمة اللامركزية المستقلة (DAO).
في عالم مثالي، يجب أن تكون المشاريع قادرة على فرض رسوم في أي ولاية قضائية يُسمح فيها بالنشاط، دون الحاجة إلى الاعتماد على DAO لتحديد ما هو مسموح به. لا يتمثل الحل في طلب الامتثال التنظيمي على مستوى البروتوكول، ولكن في التأكد من أن الرسوم الناتجة عن البروتوكول يتم تمريرها فقط إذا كانت الواجهة الأمامية أو واجهة برمجة التطبيقات (API) التي تولد الرسوم تتوافق مع القوانين واللوائح المعمول بها في موقع الواجهة الأمامية. نهاية. إذا جعلت الولايات المتحدة من غير القانوني فرض رسوم على نوع معين من المعاملات التي يسهلها أحد التطبيقات، حتى لو كان هذا النشاط مسموحًا به تمامًا في أي بلد آخر في العالم، فقد يؤثر ذلك على القيمة الاقتصادية للرمز المميز للتطبيق إلى الصفر . إن المرونة في تراكم الرسوم وتخصيصها تعادل في نهاية المطاف المرونة في مواجهة الضغوط التنظيمية.
مشكلة أساسية: تتبع النفقات
جدوى تعد إمكانية التتبع أمرًا بالغ الأهمية لمعالجة المخاطر المحتملة التي قد تنشأ من واجهة أمامية غير متوافقة، دون إدخال مخاطر الرقابة أو جعل الاتفاقية تتطلب ترخيصًا. من خلال إمكانية التتبع، يمكن للتطبيقات التأكد من أن أي رسوم مستحقة على حاملي الرمز المميز تأتي فقط من الواجهات الأمامية القانونية والمتوافقة في الولاية القضائية التي يقيم فيها حامل الرمز المميز. إذا لم يكن من الممكن تتبع الرسوم، فلن تكون هناك طريقة لعزل حاملي الرمز المميز عن القيمة المتراكمة من الواجهات الأمامية غير المتوافقة (أي الرسوم التي يتم تحصيلها بواسطة الواجهات الأمامية غير المتوافقة)، مما قد يعرض حاملي الرمز المميز للخطر.
لجعل الرسوم قابلة للتتبع، يمكن تصميم البروتوكولات باستخدام نظام التوقيع المميز للتطبيق المكون من خطوتين.
الخطوة 1: تحديد الواجهة الأمامية التي تولد التكاليف،
الخطوة 2: توجيه الرسوم إلى مجموعات مختلفة بناءً على المنطق المخصص.

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

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

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

حل مشكلات تتبع النفقات من خلال الإعدادات
يمكن حل هذه التعقيدات من خلال الإعدادات. فكر في تطبيق بروتوكول عقد ذكي غير مسموح به يمكن لأي شخص إنشاء واجهة أمامية له، ويمكن أن يكون لأي واجهة أمامية وحدة تخزين خاصة بها. دعنا نسمي الواجهة الأمامية لتطبيق البروتوكول هذا app.xyz.
قد يخضع App.xyz لقواعد امتثال محددة في الولايات القضائية التي يقع فيها. يفرض نشاط التطبيق الناشئ من app.xyz رسوم البروتوكول. يحتوي App.xyz على وحدة التوقيع المساحي الخاصة به، ويمكن لحاملي الرموز المميزة مشاركة الرموز المميزة الخاصة بهم مباشرة في الوحدة، أو إلى المُعد الذي يريد تحديد مجموعة من الواجهات الأمامية التي يعتبرونها متوافقة بشكل فردي. سيحصل أصحاب العملات الرمزية هؤلاء على إيرادات في شكل رسوم لمجموعة الواجهة الأمامية التي يمتلكونها. إذا ولدت الواجهة الأمامية رسومًا بقيمة 100 دولار أمريكي وتشارك 100 كيان في رمز مميز واحد لكل منها، فيحق لكل كيان الحصول على 1 دولار أمريكي. قد يتقاضى المُعد في البداية رسومًا مقابل خدماته. في المستقبل، قد تصدق الحكومات على الواجهات الأمامية المتوافقة في ولاياتها القضائية على السلسلة للمساعدة في حماية المستهلكين، مع الميزة الجانبية المتمثلة في أتمتة الإعداد.
أحد المخاطر المحتملة في هذا النموذج هو أن الواجهة الأمامية غير المتوافقة قد تكون أرخص في التشغيل بسبب نقص النفقات الإدارية للواجهة المتوافقة -نهاية. ويمكنهم أيضًا تصميم نماذج لاسترداد الرسوم الأولية للمتداولين لزيادة تحفيز سلوك التجنب لديهم. هناك عاملان يخففان من هذا الخطر. أولاً، يتوقع معظم المستخدمين في الواقع أن تلتزم الواجهة الأمامية بالقوانين واللوائح المحلية الخاصة بهم. وهذا ينطبق بشكل خاص على المؤسسات الكبيرة المنظمة. ثانيًا، يمكن للحوكمة أن تمنع السلوك السيئ من خلال العمل كملاذ أخير أو "سلطة النقض" للواجهات الأمامية غير المتوافقة التي تنتهك القواعد بشكل متكرر وتهدد جدوى التطبيق.
أخيرًا، سيتم إيداع جميع الرسوم الناتجة عن المعاملات التي لم تبدأ من خلال واجهة التسجيل الأمامية في وحدة تخزين موحدة، مما يمكّن البروتوكول من التقاطه بواسطة الروبوتات وغيرها مباشرة إيرادات البروتوكول الناتجة عن المعاملات في تفاعلات العقود الذكية.
من النظرية إلى التطبيق: وضع الأساليب موضع التنفيذ
دعونا نعيد النظر في مكدس رمز التطبيق. من أجل تسهيل عملية التوقيع على الواجهة الأمامية، يحتاج البروتوكول إلى إنشاء عقد تسجيل ذكي، وتحتاج الواجهة الأمامية إلى التسجيل هنا.
يمكن لكل واجهة أمامية أو واجهة برمجة تطبيقات إضافة TXT خاص إلى سجل DNS الخاص بسجلات اسم المجال الخاص بها مثل تكامل ENS DNS. يحتوي سجل TXT هذا على المفتاح العام لزوج من المفاتيح التي تم إنشاؤها بواسطة الواجهة الأمامية. ويسمى هذا المفتاح العام بمجرد إنشائه بالشهادة.
يمكن لعميل الواجهة الأمامية بعد ذلك استدعاء وظيفة register()
وإثبات ملكيته لها. اسم المجال. تعيين أسماء النطاقات لشهادة المفاتيح العامة والعكس، يتم تخزين هذه المعلومات.
عندما يتم إنشاء معاملة عبر العميل، فإنه يقوم أيضًا بتوقيع حمولة المعاملة باستخدام مفتاح الشهادة العام الخاص به. يتم تجميع هذه المعلومات معًا وتمريرها إلى العقد الذكي للتطبيق.
يتحقق العقد الذكي للتطبيق من الشهادة، ويتحقق من أنها تتوافق مع موضوع المعاملة الصحيح وتم تسجيلها. إذا كان الأمر كذلك، سيتم معالجة الصفقة. يتم بعد ذلك إرسال الرسوم الناتجة عن المعاملة إلى عقد FeeCollector
، بالإضافة إلى معلومات اسم النطاق (من السجل).
FeeCollector
يسمح للمقيمين والمستخدمين والمتحققين وما إلى ذلك بالتحقق مباشرة من اسم النطاق أو المجموعة من أسماء النطاقات التوقيع المساحي. يجب أن تتبع هذه العقود عدد الرموز المميزة الموجودة في كل مجال، وحصة كل عنوان من تلك الحصة، وطول المدة التي تم تخزينها فيها. يمكن أن تكون تطبيقات تعدين السيولة الشائعة بمثابة نقطة انطلاق لمنطق العقد هذا.
يمكن للمستخدمين الذين تعهدوا بالشرط (أو تعهدوا مباشرة بعقد إدارة الرسوم نفسه) استخدام التطبيق لمشاركة المجال الاسم يتم استخراج حصة الرسوم المقابلة بناءً على عدد الرموز المميزة. قد تكون هذه البنية مشابهة لـ MetaMorpho/Morpho Blue.

يمكن تقديم هذا الأسلوب دون إضافة عبء إدارة DAO إلى التطبيق. في الواقع، قد يتم تقليل مسؤوليات الحوكمة حيث يمكن تشغيل تبديل الرسوم بشكل دائم لجميع المعاملات التي يسهلها البروتوكول، وبالتالي إزالة سيطرة DAO على النموذج الاقتصادي للبروتوكول.
اعتبارات إضافية تعتمد على نوع التطبيق
بينما هذه تنطبق المبادئ على نطاق واسع على النموذج الاقتصادي لرمز التطبيق، ولكن قد تكون هناك اعتبارات رسوم أخرى اعتمادًا على نوع التطبيق: التطبيقات المبنية على الطبقة 1 أو الطبقة 2، وسلاسل التطبيقات، والتطبيقات المبنية باستخدام القوائم المجمعة.
اعتبارات تطبيق L1/L2
في التطبيقات على تقوم الطبقة الأولى أو الطبقة الثانية من blockchain بنشر العقود الذكية مباشرة على السلسلة. يتم فرض الرسوم عندما يتفاعل المستخدمون مع العقد الذكي للتطبيق. يحدث هذا عادةً من خلال واجهة أمامية سهلة الاستخدام (مثل تطبيق أو موقع ويب) تعمل كواجهة بين مستخدم التجزئة والعقد الذكي الأساسي. وفي هذه الحالة، ستنشأ أي رسوم من تلك الواجهة الأمامية. يوضح المثال أعلاه على app.xyz كيف يمكن لنظام الرسوم أن يعمل مع تطبيقات المستوى 1.
لا يمكن للتطبيقات الاعتماد على المنسقين لتصفية رسوم الواجهة الأمامية، أو يمكنهم القائمة البيضاء أو القائمة السوداء طريقة. ويظل الغرض هنا هو ضمان عدم استفادة حاملي الرمز المميز والبروتوكول بأكمله أو الاستفادة من الأنشطة غير القانونية والامتثال للقوانين واللوائح الخاصة بالولاية القضائية.
في نهج القائمة البيضاء، ينشر التطبيق مجموعة من القواعد للواجهات الأمامية، وينشئ سجلًا أماميًا ملتزمًا بالقواعد، ويصدر الشهادات للواجهات الأمامية الذي يتم الاشتراك فيه، ويتطلب من الواجهات الأمامية مشاركة الرموز المميزة لتلقي جزء من رسوم الطلب. إذا لم تمتثل الواجهة الأمامية لهذه القواعد، فسيتم قطعها وإلغاء شهادات المساهمة في الرسوم الخاصة بها.
في نهج القائمة السوداء، لا يتعين على التطبيق إنشاء أي قواعد، ولكن الواجهة الأمامية التي تقوم بتشغيل التطبيق لن تكون بدون إذن. وبدلاً من ذلك، سيطلب التطبيق من أي واجهة أمامية تقديم رأي من مكتب محاماة يشهد بأن الواجهة الأمامية متوافقة مع ولايتها القضائية قبل تمكين الواجهة الأمامية من استخدام التطبيق. بمجرد تلقي التعليقات، سيصدر التطبيق شهادة للمساهمة في الرسوم على الواجهة الأمامية، والتي لن يتم إلغاؤها إلا إذا تلقى التطبيق إشعارًا من الجهة التنظيمية بأن الواجهة الأمامية غير متوافقة.
سيعكس مسار التكلفة الأمثلة المقدمة في الأقسام السابقة.
يزيد كلا النهجين بشكل كبير من عبء الحكم اللامركزي، مما يتطلب من DAO إما إنشاء مجموعة من القواعد والحفاظ عليها أو تقييم القوانين المتعلقة برأي الامتثال. في بعض الحالات، قد يكون هذا مقبولاً، ولكن في معظم الحالات سيكون من الأفضل الاستعانة بمصادر خارجية لتحمل عبء الامتثال إلى الجهة التي تضعه.
اعتبارات سلسلة التطبيقات
سلسلة التطبيقات مخصصة لتطبيق ما - blockchain خاص والذي تعمل أدوات التحقق منه فقط لهذا التطبيق.
مقابل عملهم، يحصل هؤلاء المدققون على أموال. على عكس سلاسل الكتل من الطبقة الأولى، حيث تتم مكافأة المدققين عادةً بناءً على الإصدار التضخمي للرموز، فإن بعض سلاسل التطبيقات (مثل dYdX) تمرر رسوم العميل إلى المدققين.
في هذا النموذج، يجب على حاملي الرموز المميزة المشاركة مع المدققين للحصول على المكافآت. يصبح المدقق وحدة التوقيع المساحي التي تم تكوينها.
يختلف إعداد الوظيفة هذا عن أداة التحقق من المستوى 1. تقوم أدوات التحقق من سلسلة التطبيقات بحل معاملات محددة لتطبيق معين. وبسبب هذا الاختلاف، قد يتعرض مصادقو المنفعة لدرجة أعلى من المخاطر القانونية المرتبطة بالأنشطة الأساسية التي يقومون بتسهيلها. ولذلك، ينبغي للبروتوكول أن يمنح المصادقين الحرية في أداء عملهم وفقًا لقوانين ولايتهم القضائية وراحتهم. والأهم من ذلك، أنه يمكن تحقيق ذلك دون المساس بالطبيعة غير المسموح بها لسلسلة التطبيقات أو تعريضها لمخاطر رقابة كبيرة، بشرط أن تكون مجموعة المدققين الخاصة بها منتشرة جغرافيًا.
ستكون لسلاسل التطبيقات التي ترغب في الاستفادة من فوائد تتبع الرسوم تصميمًا مشابهًا لتطبيقات المستوى 1، وصولاً إلى قناة الرسوم. لكن المدققين سيكونون قادرين على استخدام تعيين الواجهة الأمامية لتحديد الواجهات الأمامية التي يرغبون في معالجة المعاملات منها. ستتدفق بعد ذلك رسوم أي معاملة معينة إلى المجموعة النشطة من المدققين، في حين أن المدققين غير النشطين الذين يختارون عدم المشاركة سوف يفوتون هذه الرسوم. من منظور الرسوم، يؤدي المدققون نفس الوظيفة التي يؤديها واضعو وحدة الستاكينغ التي تمت مناقشتها أعلاه، ويمكن للمتعاملين مع هؤلاء المدققين التأكد من أنهم لا يتلقون دخلاً من أي نشاط غير قانوني. يمكن للمصادقين أيضًا انتخاب أمين لتحديد الواجهات الأمامية المتوافقة في كل ولاية قضائية.
ملاحظات مجمعة التطبيق
تحتوي المجموعات المجمعة على مساحة كتلة خاصة بها ، ولكن يمكن أن يرث أمان سلسلة أخرى. تحتوي معظم عمليات التجميع اليوم على مُسلسِل واحد مسؤول عن طلب المعاملات وتضمينها، على الرغم من أنه يمكن إرسال المعاملات مباشرة إلى الطبقة الأولى من خلال عملية تسمى "التضمين القسري".
إذا كانت هذه المجموعات المجمعة خاصة بالتطبيق وتحدد جهاز التسلسل الخاص بها باعتباره المدقق الوحيد، فيمكن توزيع رسوم التبادلات المضمنة بواسطة جهاز التسلسل هذا بين أصحاب المصلحة بناءً على مجموعة من الإعدادات على واجهة الامتثال، أو كمجموعة عامة.
إذا أدت عمليات التجميع إلى إلغاء مركزية مجموعة أجهزة التسلسل الخاصة بها، فستصبح أجهزة التسلسل هي وحدات التخزين الفعلية المحددة، وسيعكس مسار الرسوم حالة سلسلة التطبيق. تحل مولدات التسلسل محل أدوات التحقق من صحة توزيع الرسوم، ويمكن لكل مولد تسلسل أن يقرر بنفسه أي الواجهات الأمامية تقبل الرسوم.
على الرغم من وجود العديد من النماذج الممكنة لرموز التطبيقات، فإن توفير مجموعات تخزين منسقة يعد مسارًا للأمام يساعد في معالجة العوامل الخارجية الفريدة للتطبيقات. من خلال التعرف على التحديات الجوهرية والخارجية التي تواجهها التطبيقات، يمكن للمؤسسين تصميم نماذج رمزية للتطبيق بشكل أفضل لمشاريعهم من الألف إلى الياء.
شكرًا وتقديرًا: نود أن نشكرPorter Smith لبدء هذا المشروع.
الآراء الواردة هنا هي آراء شخصية لموظفي AH Capital Management, L.L.C ("a16z") وليست آراء a16z أو الشركات التابعة لها وجهة نظر الشركة.