AppChain

ما AppChain؟

AppChain، وتسمى أيضًا بلوكتشين مخصصة لتطبيق، هي بلوكتشين تُبنى أساسًا لتطبيق أو منتج أو منظومة واحدة أو مجموعة محددة من حالات الاستخدام.

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

صُممت بلوكتشين عامة الأغراض لدعم تطبيقات عديدة غير مترابطة في الوقت نفسه.

أما AppChain، فتُصمم وفق احتياجات تطبيق محدد، مثل بروتوكول DeFi أو لعبة أو شبكة مدفوعات أو دفتر أوامر على غرار منصات التداول أو نظام للأصول الحقيقية أو منصة اجتماعية أو شبكة هوية أو طبقة تسوية للمؤسسات.

تصف وثائق Cosmos SDK إطار Cosmos SDK بأنه إطار آمن مفتوح المصدر لبناء بلوكتشينات ودفاتر رقمية مخصصة للتطبيقات.

وهذا التعريف مهم لأن AppChains ليست مجرد مصطلح تسويقي.

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

قد تكون AppChain بلوكتشين Layer 1 سيادية أو Rollup أو سلسلة Layer 2 أو Layer 3 أو parachain أو شبكة على نمط subnet أو تصميم بلوكتشين مخصصًا آخر.

يعتمد هيكلها الدقيق على طريقة تعامل السلسلة مع الأمان والتسوية والإجماع وقابلية التشغيل البيني وتوافر البيانات.

الفكرة الأساسية للمستخدمين بسيطة.

AppChain هي بلوكتشين مخصصة لخدمة تطبيق معين على نحو أفضل مما قد تتيحه بيئة بلوكتشين مشتركة.

أهمية AppChains في العملات المشفرة

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

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

وقد تحتاج لعبة بلوكتشين إلى معاملات كثيرة منخفضة التكلفة ومنطق مخصص للأصول.

وقد يحتاج بروتوكول إقراض إلى ضوابط قوية للأوراكل ومعلمات للمخاطر وقواعد للتصفية وإشراف حوكمي.

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

وقد يحتاج تطبيق استهلاكي إلى تجريد الغاز واسترداد المحفظة ورسوم قابلة للتوقع.

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

تتيح AppChain للفريق تخصيص البلوكشين وفق احتياجات التطبيق بدلًا من تكييف التطبيق مع بيئة مشتركة مزدحمة.

قد يحسّن ذلك الأداء وتجربة المستخدم، لكنه يضيف مسؤوليات أيضًا.

إذ يتعين على الفريق التفكير في المدققين وsequencers وأمان الجسور ووقت التشغيل والترقيات والحوكمة والسيولة وبرمجيات العقد والاستجابة للطوارئ.

ولا تكون AppChain أفضل تلقائيًا من عقد ذكي على سلسلة مشتركة.

إنما تكون أفضل عندما يستفيد التطبيق فعلًا من تحكم أوسع في طبقة البلوكشين.

آلية عمل AppChain

تعمل AppChain عبر توفير بيئة بلوكتشين خاصة بتطبيق أو منظومة واحدة.

تعالج AppChain المعاملات وتحدّث الحالة وتفرض الرسوم وتتبع قواعدها الخاصة.

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

تملك AppChain السيادية عادةً إجماعها واقتصاديات مدققيها الخاصة.

وقد تنفذ AppChain القائمة على Rollup المعاملات على سلسلتها الخاصة، مع نشر البيانات أو البراهين على طبقة تسوية.

وقد تعمل AppChain من Layer 3 فوق Layer 2 وتستخدمها للتسوية أو الاتصال.

وقد تتصل AppChain على نمط parachain بسلسلة ترحيل وتعتمد على الأمان المشترك.

كما يمكن لـ AppChain استخدام الجسور أو بروتوكولات المراسلة لنقل الأصول والبيانات بين السلاسل.

عادةً ما يصبح التطبيق السبب الرئيسي الذي يدفع المستخدمين إلى التفاعل مع السلسلة.

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

تخفي أفضل AppChains التعقيد عن المستخدمين، مع منح المطورين تحكمًا أوسع في الخلفية.

AppChain مقابل العقد الذكي

العقد الذكي شيفرة تُنشر على بلوكتشين قائمة.

أما AppChain، فهي بيئة بلوكتشين مصممة لتطبيق أو منظومة.

يشبه الفرق بينهما استئجار مساحة في مبنى مشترك وتصميم مبنى مخصص لشركة واحدة.

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

تمنح AppChain تحكمًا أكبر، لكنها تتطلب اتخاذ قرارات إضافية بشأن البنية التحتية.

عادةً ما يتشارك العقد الذكي مساحة الكتل والرسوم وقواعد التنفيذ مع تطبيقات أخرى.

ويمكن لـ AppChain تخصيص أوقات الكتل وأسواق الرسوم وتوكنات الغاز وترتيب المعاملات والحوكمة والوحدات والأذونات وقواعد الترقية.

لكن قد يكون العقد الذكي خيارًا أكثر أمانًا للمشاريع الناشئة التي لا تحتاج بعد إلى بنية تحتية مخصصة.

وقد تكون AppChain أنسب عندما يملك التطبيق عددًا كافيًا من المستخدمين أو حجم معاملات أو قيمة اقتصادية أو متطلبات تقنية تبرر بيئته الخاصة.

تبدأ مشاريع كثيرة في عالم العملات المشفرة بعقود ذكية، ثم تدرس التحول إلى AppChain لاحقًا.

AppChain مقابل بلوكتشين عامة الأغراض

تدعم بلوكتشين عامة الأغراض تطبيقات عديدة غير مترابطة ضمن بيئة مشتركة واحدة.

أما AppChain، فتركز على تطبيق أو فئة أو منظومة مترابطة بإحكام.

تفيد السلاسل العامة لأنها توفر سيولة وأدوات تطوير ومستخدمين وافتراضات أمان مشتركة.

وتفيد AppChains لأنها تتيح التخصص.

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

وقد تكون AppChain أفضل من ناحية الأداء، إذ يمكن تحسينها لتناسب عبء عمل محددًا.

وقد تتمتع السلسلة العامة بتأثيرات شبكة أقوى.

وقد توفر AppChain تحكمًا أكبر في المنتج.

يعتمد الاختيار على احتياجات التطبيق.

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

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

أنواع AppChains

AppChain السيادية هي بلوكتشين مستقلة لها مجموعة المدققين والحوكمة واقتصاديات التوكن ونموذج الأمان الخاص بها.

غالبًا ما تُبنى AppChain على نمط Cosmos باستخدام برمجيات بلوكتشين معيارية، وتتصل بسلاسل أخرى عبر اتصالات بين السلاسل.

توضح وثائق IBC أن IBC تدعم تطبيقات عبر السلاسل، مثل تحويلات التوكنات ومبادلات الذرية والعقود الذكية متعددة السلاسل والتحكم في الحسابات عبر السلاسل.

AppChain القائمة على Rollup هي سلسلة مخصصة تنفذ المعاملات خارج طبقة أساسية وتنشر البيانات أو جذور الحالة أو البراهين على طبقة تسوية.

توضح وثائق توسيع Ethereum أن Rollups تعالج المعاملات خارج Ethereum Mainnet وتستمد الأمان من إجماع Layer 1.

AppChain من Layer 3 هي سلسلة متخصصة تُبنى فوق منظومة Layer 2 أو Rollup.

أما AppChain على نمط parachain، فهي بلوكتشين متخصصة متصلة ببنية أكبر قائمة على سلسلة ترحيل.

وتصف المرجعية التقنية لـ Polkadot parachains بأنها بلوكتشينات متخصصة تتصل بسلسلة الترحيل مع الحفاظ على منطق التطبيق الخاص بها.

وقد تكون AppChain للمؤسسات مقيّدة الأذونات أو مقيّدة جزئيًا أو مصممة لمشاركة مضبوطة.

لذلك، قد يشير مصطلح AppChain إلى تصاميم تقنية عدة، لكن القاسم المشترك بينها هو تخصيص البلوكشين لتطبيق معين.

AppChains السيادية

تتحكم AppChain السيادية في أمانها وحوكمتها ومجموعة مدققيها وترقياتها وتصميمها الاقتصادي.

يوفر هذا النموذج للتطبيق استقلالية كبيرة.

إذ تستطيع السلسلة تحديد توكنها الأصلي ونموذج الرسوم وقواعد Staking وعملية الحوكمة ومنطق الوحدات.

كما يمكنها تحديد سرعة الترقية والميزات التي ستضيفها.

لكن AppChain تتحمل مسؤولية إنشاء أمانها وصيانته.

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

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

وقد تحتاج إلى صناع سوق وبرامج للسيولة وجسور وحملات لتسهيل انضمام المستخدمين.

وهذا يجعل السيادة قوية، لكنها تتطلب جهدًا كبيرًا.

تكون AppChain السيادية أنسب عادةً للفرق التي تريد تحكمًا واسعًا وقادرة على دعم منظومة بلوكتشين كاملة.

AppChains القائمة على Rollup

AppChain القائمة على Rollup هي سلسلة مخصصة تستخدم بنية Rollup للتوسّع ومواءمة الأمان.

تعالج Rollups المعاملات عادةً بعيدًا عن الطبقة الأساسية، ثم تنشر البيانات أو البراهين أو الالتزامات على طبقة تسوية.

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

توضح وثائق OP Stack أن المطورين يستطيعون تعديل مكونات OP Stack لبناء أنظمة Layer 2 جديدة.

وتصف وثائق سلسلة Arbitrum سلاسل Arbitrum بأنها تطبيقات قابلة للنشر والتهيئة من مجموعة تقنيات Arbitrum Nitro، ومخصصة لحالة استخدام معينة.

توضح هذه الأطر سبب انتشار AppChains القائمة على Rollup بين الفرق التي تريد تسوية متوافقة مع Ethereum وتحكمًا مخصصًا في السلسلة.

وقد تخصص هذه السلاسل توكنات الغاز وسياسات الرسوم وإعدادات التنفيذ وsequencers والأذونات وخيارات توافر البيانات.

لكن عليها إدارة مخاطر sequencer والجسور وأنظمة الإثبات ومفاتيح الترقية وتوافر البيانات وافتراضات النهائية.

قد تكون AppChain القائمة على Rollup قوية، لكن ينبغي للمستخدمين فهم خصائص الأمان الموروثة وتلك التي تظل محلية للسلسلة.

AppChains من Layer 3

تُبنى AppChain من Layer 3 عادةً فوق شبكة Layer 2.

وغالبًا ما يكون الهدف منح التطبيق مزيدًا من التخصيص، مع الاستفادة من منظومة Layer 2 قائمة للتسوية أو المراسلة أو الوصول إلى السيولة.

قد يكون تصميم Layer 3 مفيدًا للألعاب والتطبيقات عالية التردد والبيئات الخاصة وسير عمل المؤسسات وقواعد التنفيذ المخصصة للتطبيق.

وقد تخفض أنظمة Layer 3 التكاليف أكثر عبر تجميع النشاط قبل تسويته على Layer 2.

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

لكن تصاميم Layer 3 تضيف طبقة أخرى من الافتراضات.

وقد يحتاج المستخدمون إلى فهم الطبقة الأساسية وLayer 2 وLayer 3 في الوقت نفسه.

وقد تصبح الجسور وعمليات السحب أكثر تعقيدًا.

وينبغي للمطورين تجنب التضحية بقدر مفرط من الأمان أو السيولة مقابل التخصيص.

قد تكون AppChains من Layer 3 مفيدة، لكن فقط عندما يُشرح نموذج تجربة المستخدم والأمان بوضوح.

AppChains على نمط Cosmos

تُعد AppChains على نمط Cosmos من أقدم الأمثلة وأوضحها على تصميم بلوكتشين مخصصة للتطبيقات.

يوفر Cosmos SDK للمطورين أدوات معيارية لبناء بلوكتشينات مخصصة بمنطق أعمال خاص بها.

وتوضح وثائقه أن SDK يمنح المهندسين تحكمًا كاملًا في التحكم بالوصول والأمان ومنطق الأعمال والحوكمة.

ولهذا يربط كثيرون مصطلح AppChain ببنية Cosmos.

يمكن لـ AppChain على نمط Cosmos استخدام وحدات جاهزة لوظائف شائعة، مثل الحسابات وStaking والحوكمة وتحويلات التوكنات.

كما يمكنها إضافة وحدات مخصصة لتلبية احتياجات التطبيق.

وقد يتيح IBC للسلاسل المتوافقة التواصل من دون الحاجة إلى تحويل إحدى السلاسل إلى عقد ذكي على سلسلة أخرى.

وهذا يدعم شبكة من البلوكشينات السيادية بدلًا من طبقة تنفيذ مشتركة واحدة.

تتمثل الفائدة في السيادة والتخصيص.

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

AppChains وقابلية التشغيل البيني

قابلية التشغيل البيني هي قدرة البلوكشينات المختلفة على تبادل الأصول أو البيانات أو الرسائل أو التعليمات.

تحتاج AppChains إلى قابلية التشغيل البيني لأن التخصص قد يؤدي إلى العزلة.

إذا كان أداء AppChain ممتازًا، لكن تعذر نقل الأصول منها وإليها، فقد لا يعتمدها المستخدمون.

يمكن ربط AppChains بالمنظومات الأكبر عبر جسور بين السلاسل وبروتوكولات المراسلة وأنظمة الأمان المشترك وطبقات السيولة.

IBC مثال على بروتوكول اتصال بين السلاسل مصمم لبيئات البلوكشين السيادية.

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

وقد تستخدم منظومات parachain المراسلة عبر سلسلة الترحيل ومعايير التشغيل البيني المشتركة.

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

فقد تصبح الجسور وأنظمة تمرير الرسائل نقاطًا رئيسية للهجوم.

لا يتجاوز أمان AppChain أمان أضعف اتصال أساسي فيها.

AppChains والأمان

الأمان من أهم المسائل المتعلقة بـ AppChain.

تتيح البلوكشين المشتركة للتطبيقات الاستفادة من قاعدة أمان قائمة.

وقد تحتاج AppChain إلى بناء الأمان من الصفر أو تحديد ما ترثه منه بوضوح.

يجب على AppChain السيادية جذب مدققين نزيهين وتوزيع الحصة أو قوة التصويت وتأمين البنية التحتية للعقد ومنع السيطرة على الحوكمة.

وعلى AppChain القائمة على Rollup إدارة ضوابط sequencer وبراهين الاحتيال أو إثباتات الصلاحية وعقود الجسور وأذونات الترقية وتوافر البيانات.

أما AppChain المقيّدة الأذونات، فعليها تحديد من يمكنه التحقق من الكتل ومن يمكنه الاطلاع على البيانات ومن يستطيع تحديث القواعد.

الأمان ليس تقنيًا فحسب.

فهو اقتصادي وتشغيلي وقانوني واجتماعي أيضًا.

قد تضر بالمستخدمين أخطاء منطق السلسلة أو ضعف مجموعة المدققين أو اختراق الجسر أو سوء عملية الترقية أو الإهمال في حماية مفتاح المسؤول.

ينبغي ألا يطلق الفريق AppChain لمجرد أنها تبدو قابلة للتوسّع.

بل ينبغي إطلاقها فقط إذا كان قادرًا على صيانة بيئة بلوكتشين آمنة بمرور الوقت.

AppChains وتوافر البيانات

يعني توافر البيانات إمكانية وصول المستخدمين أو المدققين أو المراقبين إلى بيانات المعاملات اللازمة للتحقق من حالة السلسلة أو إعادة بنائها.

تكتسب هذه المسألة أهمية خاصة لـ AppChains القائمة على Rollup، إذ يحتاج المستخدمون إلى ضمان عدم اختفاء البيانات أو حجبها.

إذا لم تتوافر بيانات المعاملات، فقد لا يتمكن المستخدمون من التحقق من السلسلة أو الخروج بأمان.

تنشر بعض AppChains بياناتها على طبقة تسوية رئيسية.

وتستخدم بعضها شبكة منفصلة لتوافر البيانات.

وتعتمد بعضها على لجان أو مدققين أو أنظمة مقيّدة الأذونات لمعالجة توافر البيانات.

لكل نهج مفاضلات بين التكلفة والأداء والثقة والأمان.

قد يخفض توافر البيانات الأقل تكلفة الرسوم، لكنه قد يضيف افتراضات جديدة أيضًا.

ينبغي لمستخدمي AppChain السؤال عن مكان تخزين البيانات والجهات التي تستطيع الوصول إليها وما يحدث إذا تعطل المشغّل.

توافر البيانات من التفاصيل الخفية التي قد تحدد مدى أمان AppChain في ظروف الضغط.

AppChains وتوكنات الغاز

غالبًا ما تستطيع AppChain اختيار توكن الغاز الخاص بها.

توكن الغاز هو الأصل الذي يدفعه المستخدمون لإرسال المعاملات أو استخدام الشبكة.

تستخدم بعض AppChains أصلًا رئيسيًا موجودًا لتغطية الغاز.

ويستخدم بعضها توكن التطبيق نفسه.

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

يؤثر تصميم توكن الغاز في تجربة المستخدم والطلب على التوكن ومكافآت المدققين وتخطيط الخزانة.

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

قد يقلل توكن الغاز المألوف صعوبة انضمام المستخدمين، لكنه قد يحد من الدور الاقتصادي لتوكن AppChain نفسها.

قد يحسن تجريد الغاز تجربة المستخدم، لكن لا بد من جهة تتحمل التكلفة في الخلفية.

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

AppChains والحوكمة

الحوكمة هي عملية تغيير القواعد وترقية البرمجيات وإدارة المعلمات والاستجابة لحالات الطوارئ.

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

قد تقرر الحوكمة تغييرات المدققين وسياسات الرسوم وترقيات الجسور واللامركزية التدريجية لـ sequencer وإنفاق الخزانة والإيقاف المؤقت في حالات الطوارئ.

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

وقد تكون الحوكمة خارج السلسلة أسرع، لكنها قد تعتمد بدرجة أكبر على فرق أو مؤسسات موثوقة.

قد تكون الحوكمة عبر محفظة متعددة التوقيعات عملية في المراحل الأولى، لكنها تنشئ مخاطر تتعلق بإدارة المفاتيح والثقة.

وقد تساعد اللامركزية التدريجية AppChain على الانتقال من سيطرة الفريق إلى سيطرة أوسع للمجتمع بمرور الوقت.

ينبغي للمستخدمين معرفة الجهة التي تستطيع ترقية السلسلة والضمانات المتاحة.

كلما زادت القيمة التي تحتفظ بها AppChain، ازدادت أهمية عملية الحوكمة.

AppChains وتجربة المستخدم

تُعد تجربة المستخدم من أقوى أسباب بناء AppChain.

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

قد يعني ذلك في لعبة أن ينفذ المستخدمون إجراءات صغيرة كثيرة من دون القلق بشأن ارتفاع رسوم المعاملات.

وقد يعني في تطبيق مدفوعات أن تبدو التحويلات سريعة وقليلة التكلفة.

وفي تطبيق تداول، قد يعني ضبط السلسلة لتناسب تحديثات الأوامر أو التصفيات المتكررة.

أما في شبكة مؤسسات، فقد يعني التزام المشاركين بقواعد الأذونات ومتطلبات إعداد التقارير.

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

لا يريد المستخدمون إدارة إعدادات شبكة معقدة لمجرد استخدام تطبيق واحد.

ينبغي أن تبدو AppChain الناجحة بسيطة من الواجهة، حتى لو كانت بنيتها التحتية متخصصة.

فوائد AppChains

الفائدة الأولى لـ AppChain هي التخصيص.

يمكن للمطورين تصميم السلسلة لتناسب الاحتياجات الفعلية للتطبيق.

والفائدة الثانية هي تخصيص مساحة الكتل.

إذ لا يضطر التطبيق إلى منافسة تطبيقات غير مرتبطة به مباشرةً عند حدوث ازدحام.

والفائدة الثالثة هي ضبط الأداء.

يمكن للسلسلة تعديل أوقات الكتل ومنطق الرسوم وإعدادات التنفيذ أو ترتيب المعاملات لتناسب حالة استخدامها.

والفائدة الرابعة هي تحسين التصميم الاقتصادي.

يمكن للفريق مواءمة الرسوم واستخدامات التوكن والمكافآت والحوكمة مع التطبيق.

والفائدة الخامسة هي التحكم في الحوكمة.

تستطيع AppChain الترقية وفق خارطة طريقها بدلًا من انتظار تغيير السلسلة المشتركة.

والفائدة السادسة هي التحكم في تجربة المستخدم.

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

قد تكون هذه الفوائد مهمة، لكن ينبغي موازنتها مع التكاليف التشغيلية والأمنية.

مخاطر AppChains

الخطر الأول لـ AppChain هو تجزؤ الأمان.

قد يكون أمان سلسلة صغيرة أضعف من أمان شبكة مشتركة رئيسية.

والخطر الثاني هو تجزؤ السيولة.

قد تتوزع الأصول على سلاسل كثيرة جدًا، ما يقلل عمق التداول ويزيد الحاجة إلى الجسور.

والخطر الثالث هو مخاطر الجسور.

تعتمد AppChains كثيرة على جسور أو أنظمة مراسلة قد تصبح نقاط فشل حرجة.

والخطر الرابع هو التعقيد التشغيلي.

إذ يتعين على الفريق صيانة العقد والبنية التحتية والترقيات والمراقبة والاستجابة للحوادث.

والخطر الخامس هو السيطرة على الحوكمة.

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

والخطر السادس هو ارتباك المستخدمين.

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

والخطر السابع هو ضعف الاقتصاديات.

قد تواجه AppChain التي لا تملك رسومًا أو مدققين أو سيولة أو مستخدمين كافيين صعوبة في الحفاظ على أمانها وفائدتها.

متى ينبغي للمشروع التفكير في AppChain؟

ينبغي للمشروع التفكير في AppChain عندما تؤثر قيود السلسلة المشتركة بوضوح في المنتج.

قد يكون حجم المعاملات الكبير أحد الأسباب.

وقد تكون الحاجة إلى رسوم قابلة للتوقع سببًا آخر.

كما قد تبرر قواعد التنفيذ الخاصة استخدام AppChain.

وقد تستفيد من سلسلة مخصصة التطبيقات التي تتطلب حوكمة أو أذونات أو إعدادات خصوصية أو مسارات امتثال خاصة.

تُعد الألعاب وأنظمة دفتر الأوامر وبروتوكولات DeFi عالية التردد وشبكات الهوية وأنظمة التسوية للمؤسسات من الحالات المرشحة الشائعة.

ينبغي للمشروع أيضًا تقييم ما إذا كان لديه عدد كافٍ من المستخدمين والموارد لدعم البنية التحتية المخصصة.

إذا كان الهدف الرئيسي هو العلامة التجارية فقط، فقد لا تكون AppChain ضرورية.

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

AppChain التزام جدي بالبنية التحتية، لا مجرد إعلان إطلاق.

متى قد تكون AppChain فكرة غير مناسبة؟

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

وقد لا تكون مناسبة إذا لم يستطع الفريق إدارة البنية التحتية للبلوكشين بأمان.

إذا كان التطبيق يعتمد كثيرًا على السيولة المشتركة وقابلية التركيب، فقد يقلل الانتقال إلى سلسلة منفصلة من فائدته.

وقد يتجنب المستخدمون التطبيق إذا كانت تجربة الجسر سيئة.

إذا لم يكن للتوكن الأصلي دور اقتصادي حقيقي، فقد يؤدي إطلاق سلسلة إلى تعقيد غير ضروري.

وقد يفقد المستخدمون الثقة بالسلسلة إذا كانت حوكمتها مركزية وغير واضحة.

وقد تتعرض السلسلة للرقابة أو التوقف إذا كان تركيز المدققين أو sequencers مرتفعًا جدًا.

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

ينبغي للمشروع اختيار AppChain فقط عندما تفوق فوائدها تكاليفها بوضوح.

التخصص قوي، لكن التخصص غير الضروري قد يتحول إلى عبء.

قائمة مراجعة معمارية AppChain

ينبغي للفريق الذي يصمم AppChain أن يحدد أولًا نموذج الأمان الذي ستستخدمه السلسلة.

وعليه أن يقرر ما إذا كانت السلسلة ستكون سيادية أو قائمة على Rollup أو تعتمد على الأمان المشترك أو مقيّدة الأذونات.

كما ينبغي تحديد مكان نشر بيانات المعاملات وكيفية التحقق من توافرها.

وعليه اختيار الجهة التي ترتب المعاملات وكيفية تحقيق اللامركزية في هذا الدور بمرور الوقت.

كما يجب تحديد كيفية نقل المستخدمين للأصول إلى السلسلة ومنها.

وعليه تحديد توكن الغاز المستخدم وإمكانية تجريد الغاز.

كما ينبغي وضع عملية واضحة للترقيات والطوارئ.

ويجب توفير نقاط نهاية RPC ومستكشفات ومفهرسات ووثائق موثوقة للمطورين.

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

AppChain القوية ليست سريعة وقليلة التكلفة فحسب.

بل يجب أن تكون مفهومة وآمنة وقابلة للصيانة وصريحة بشأن مفاضلاتها.

AppChains واقتصاديات التوكن

اقتصاديات التوكن هي التصميم الاقتصادي لأصل مشفر أو شبكة.

يمكن لـ AppChain استخدام اقتصاديات التوكن لمكافأة المدققين ودفع مستحقات sequencers وتمويل التطوير وتحفيز السيولة وتنسيق الحوكمة.

وقد يُستخدم توكن AppChain الأصلي للغاز أو Staking أو الحوكمة أو المكافآت أو حقوق الوصول.

لكن ينبغي أن تتوافق اقتصاديات التوكن مع الطلب الحقيقي على الشبكة.

فقد يؤدي توكن لا يوجد إلا لإجبار المستخدمين على دفع الرسوم إلى زيادة الاحتكاك.

وقد ينشئ التوكن الذي يمنح المطلعين نفوذًا مفرطًا في الحوكمة مشكلات تتعلق بالثقة.

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

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

ينبغي للمستخدمين السؤال عما إذا كان التوكن ضروريًا لتصميم السلسلة أم أنه أضيف أساسًا للمضاربة.

ينبغي للاقتصاديات الجيدة أن تعزز التطبيق بدلًا من تشتيت الانتباه عنه.

AppChains وDeFi

تُبنى AppChains الخاصة بـ DeFi لتطبيقات التمويل اللامركزي.

وقد تدعم التداول والإقراض والمشتقات والمنتجات المهيكلة وإدارة السيولة أو أنظمة المخاطر على السلسلة.

يمكن لـ AppChain خاصة بـ DeFi تخصيص ترتيب المعاملات وقواعد الرسوم وآليات التصفية وتصميم الأوراكل وضوابط المخاطر.

وقد يكون ذلك مفيدًا لأن DeFi يحتاج غالبًا إلى السرعة والموثوقية ودقة التنفيذ.

لكن AppChains الخاصة بـ DeFi تنطوي أيضًا على مخاطر جدية.

فقد تعتمد على الجسور للضمانات والأوراكل للتسعير وsequencers لترتيب المعاملات والحوكمة لمعلمات المخاطر.

وقد يؤدي خلل في أي من هذه الأجزاء إلى خسائر.

ينبغي تدقيق AppChains الخاصة بـ DeFi ومراقبتها واختبارها تحت ظروف السوق القصوى.

وعلى المستخدمين فهم قواعد السحب وافتراضات الجسر قبل إيداع الأصول.

قد تحسن AppChain الخاصة بـ DeFi الأداء، لكنها لا تلغي المخاطر المالية.

AppChains والألعاب

الألعاب من أوضح حالات استخدام AppChain.

غالبًا ما تحتاج الألعاب إلى معاملات كثيرة منخفضة التكلفة تتعلق بالعناصر والمكافآت والترقيات والتداول وإجراءات اللاعبين.

قد تصبح السلسلة المشتركة مرتفعة التكلفة أو بطيئة جدًا لهذا النوع من النشاط.

يمكن لـ AppChain مخصصة للألعاب تخصيص رسوم الغاز وإنشاء الحسابات وقواعد الأصول والأسواق ومسارات المعاملات داخل اللعبة.

كما يمكنها إخفاء تعقيد البلوكشين كي يركز اللاعبون على اللعبة بدلًا من إعدادات الشبكة.

لكن ينبغي لـ AppChains الخاصة بالألعاب تجنب تحويل كل إجراء إلى عبء مالي.

كما تحتاج إلى تصميم قوي لحفظ الأصول ومنع الاحتيال وقابلية نقل الأصول وأمان الأسواق.

إذا توقفت اللعبة، فقد يسأل المستخدمون عما سيحدث للسلسلة وأصولهم.

ينبغي لـ AppChain الألعاب توضيح حقوق الملكية وقواعد الأصول والدعم طويل الأجل منذ البداية.

يجب أن تحسن التقنية اللعبة، لا أن تثقلها.

AppChains والأصول الحقيقية

صُممت AppChains للأصول الحقيقية لتمثيل أصول خارج السلسلة أو إدارتها عبر البلوكشين.

وقد تشمل هذه الأصول منتجات الخزانة والسلع والائتمان الخاص والفواتير والحصص العقارية وأرصدة الكربون أو أسهم الصناديق.

قد تفيد AppChain الأصول الحقيقية، لأن هذه الأنظمة قد تحتاج إلى أذونات والتحقق من الهوية وإعداد التقارير وقيود التحويل ومسارات تدقيق.

وقد لا تلائم سلسلة مشتركة مفتوحة بالكامل جميع مسارات العمل الخاضعة للتنظيم.

يمكن لـ AppChain مخصصة تحديد الجهات التي تستطيع الاحتفاظ بالأصول والتحقق من المعاملات وآلية تطبيق قواعد الامتثال.

لكن الأصول الحقيقية المرمزة تعتمد على اتفاقيات قانونية خارج البلوكشين.

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

ينبغي للمستخدمين فهم مخاطر المُصدر والحفظ وحقوق الاسترداد وقواعد إعداد التقارير والولاية القضائية.

قد تحسن AppChain البنية التحتية، لكنها لا تستطيع وحدها إزالة المخاطر القانونية ومخاطر الائتمان.

مفاهيم خاطئة شائعة عن AppChains

من المفاهيم الخاطئة الشائعة أن كل تطبيق يحتاج إلى AppChain خاصة به.

تعمل تطبيقات كثيرة على نحو أفضل كعقود ذكية على سلاسل موجودة.

ومن المفاهيم الخاطئة الأخرى أن AppChain تحسن الأمان تلقائيًا.

فبعض AppChains أقل أمانًا من السلاسل المشتركة بسبب ضعف مجموعة المدققين أو تصميم الجسر أو عملية الحوكمة.

والمفهوم الخاطئ الثالث هو أن الرسوم المنخفضة تكفي لتحقيق الانتشار.

يحتاج المستخدمون أيضًا إلى السيولة والمحافظ والثقة والوثائق والتطبيقات المفيدة.

والمفهوم الخاطئ الرابع هو أن AppChains تكون دائمًا بلوكتشينات Layer 1.

فقد تكون AppChain أيضًا Rollup أو Layer 2 أو Layer 3 أو parachain أو تصميمًا مخصصًا آخر للسلسلة.

أما المفهوم الخاطئ الخامس، فهو أن AppChains تزيل مخاطر التعامل عبر السلاسل.

في الواقع، تعتمد AppChains كثيرة بدرجة كبيرة على الجسور وبروتوكولات المراسلة.

مصطلحات مشفرة ذات صلة

بلوكتشين Layer 1 هي سلسلة أساسية توفر طبقة التسوية والإجماع الخاصة بها.

Layer 2 بيئة توسّع تعالج المعاملات خارج سلسلة أساسية، مع الاعتماد عليها في وظائف مهمة للأمان أو التسوية.

Rollup تصميم للتوسّع يجمع المعاملات في دفعات وينشر البيانات أو البراهين أو الالتزامات على طبقة تسوية.

البلوكتشين السيادية هي سلسلة تتحكم في مدققيها وحوكمتها ونموذج أمانها.

المدقق مشارك يساعد على إنتاج الكتل أو التحقق منها، بحسب تصميم الإجماع.

sequencer جهة أو نظام يرتب المعاملات في كثير من تصاميم Rollup.

توافر البيانات يعني إمكانية الوصول إلى البيانات اللازمة للتحقق من حالة السلسلة أو إعادة بنائها.

الجسر بنية تحتية لنقل الأصول أو الرسائل بين البلوكشينات.

قابلية التشغيل البيني هي قدرة البلوكشينات المختلفة على التواصل وتبادل القيمة أو البيانات.

اقتصاديات التوكن هي التصميم الاقتصادي لتوكن أو شبكة.

الأسئلة الشائعة

ما معنى AppChain في العملات المشفرة؟

AppChain بلوكتشين مخصصة لتطبيق أو منتج أو منظومة محددة.

هل AppChain هي نفسها بلوكتشين Layer 1؟

لا. قد تكون AppChain من نوع Layer 1 سيادي، لكنها قد تكون أيضًا Rollup أو Layer 2 أو Layer 3 أو parachain أو تصميمًا متخصصًا آخر للسلسلة.

لماذا تبني المشاريع AppChains؟

تبنيها للحصول على مساحة كتل مخصصة ورسوم خاصة وأداء أفضل وحوكمة متخصصة وتحكم أوسع في تجربة المستخدم.

هل AppChains أكثر أمانًا من العقود الذكية؟

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

ما الفرق بين AppChain والعقد الذكي؟

يعمل العقد الذكي على بلوكتشين موجودة، بينما AppChain بيئة بلوكتشين مخصصة تُبنى لتطبيق أو منظومة.

هل تحتاج AppChains إلى توكنات خاصة بها؟

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

هل يمكن لـ AppChain الاتصال ببلوكشينات أخرى؟

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

ما AppChain القائمة على Rollup؟

هي سلسلة مخصصة لتطبيق تستخدم بنية Rollup لتنفيذ المعاملات بصورة منفصلة، مع تثبيت البيانات أو البراهين أو الحالة على سلسلة أخرى.

ما أكبر فائدة لـ AppChain؟

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

ما أكبر مخاطر AppChain؟

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

هل AppChains مناسبة لـ DeFi؟

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

هل AppChains مناسبة للألعاب؟

قد تفيد AppChains الألعاب لأنها تدعم معاملات كثيرة منخفضة التكلفة وقواعد مخصصة للأصول وانضمامًا أسهل للاعبين.

الخاتمة

AppChain هي بلوكتشين مخصصة لتطبيق أو منتج أو منظومة محددة.

وتمنح المطورين تحكمًا أكبر في التنفيذ والرسوم والحوكمة وتصميم التوكن وتجربة المستخدم والبنية التحتية.

وقد تكون AppChains بلوكتشينات سيادية أو Rollups أو سلاسل Layer 2 أو Layer 3 أو parachains أو تصاميم شبكات أخرى مخصصة للتطبيقات.

وتتمثل ميزتها الرئيسية في التخصص.

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

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

أما التحدي الرئيسي فهو المسؤولية.

إذ يتعين على AppChain إدارة الأمان والمدققين أو sequencers والجسور وتوافر البيانات والحوكمة والسيولة والبنية التحتية والترقيات وتوعية المستخدمين.

وقد ينشئ التصميم الضعيف لـ AppChain مخاطر تفوق القيمة التي يقدمها.

أما AppChain المصممة جيدًا، فقد توفر لتطبيق العملات المشفرة السرعة والتحكم والمرونة التي يحتاج إليها للتوسّع.

ينبغي للمستخدمين تقييم AppChain بالسؤال عن كيفية تأمينها ومكان توافر بياناتها وآلية نقل الأصول منها وإليها والجهة التي تستطيع ترقيتها والتوكن الذي يشغّلها وما يحدث إذا تعطل المشغّلون الرئيسيون.

وينبغي للمطورين اختيار AppChain فقط عندما يحتاج التطبيق فعلًا إلى بنية تحتية مخصصة.

تُعد AppChains من أوضح مؤشرات ازدياد التخصص في البنية التحتية للعملات المشفرة.

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

سيعتمد مستقبل AppChains على قدرة الفرق على الجمع بين التخصيص والأمان وقابلية التشغيل البيني والسيولة وتجربة الاستخدام البسيطة.

لن تقتصر أفضل AppChains على السرعة أو انخفاض التكلفة.

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