التقنيات والآثار المترتبة على تطبيقات السلاسل

تحليل بحثي أصلي من Web3.com Ventures

0xFishylosopher

مقدمة

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

لنفترض أنك تقوم ببناء مُبدّل لا مركزي عبر السلاسل يحتاج إلى تجميع البيانات من كل هذه السلاسل المختلفة [1]، أو أنك تريد لعبة استراتيجية في الزمن الحقيقي على السلسلة [2]، أو أنك شركة Fortune 500 تتعقّب سلسلة التوريد الخاصة بها. لا يمكن للبلوك تشينات العامة الجاهزة أن تتعامل حقًا مع متطلبات الإنتاجية أو تجميع البيانات أو الخصوصية التي تحتاجها هذه التطبيقات. وهنا يأتي مفهوم “appchain”. إن appchains هي شبكات بلوك تشين لامركزية ومخصّصة للتطبيق، صُممت لدعم حالات استخدام محددة والوفاء بمتطلبات محددة. ضمن هذه المقالة، سأستعرض ثلاث مقاربات نموذجية للمنظور الناشئ لـ appchains: منظومة Cosmos، وHyperledger Fabric، وRollups-as-a-Service (RaaS)، قبل مناقشة كيف يؤثر صعود appchains على مشهد البنية التحتية لـ Web3 بشكل أوسع.

شبكة Cosmos

تُعد شبكة Cosmos، على الأرجح، واحدة من أهم حلول appchain ضمن Web3. تعود جذورها إلى عام 2016، وتهدف شبكة Cosmos إلى إنشاء “إنترنت البلوك تشينات”، أي البنية التحتية لعالم متعدد السلاسل. وبشكل أساسي، توفر Cosmos مجموعة تطوير برمجيات (SDK)، تمنح المطورين الأدوات والواجهات التي يحتاجونها لبناء تطبيقات بلوك تشينهم الخاصة بسهولة. وعلى الرغم من أن الـ SDK يتضمن بعض البنى الافتراضية الجاهزة مثل بروتوكول إجماع Tendermint PoS، فإن المطورين يُمنحون هامشًا واسعًا لتجاوز هذه البنى الافتراضية وإعادة كتابتها وتصميم بلوك تشين يضم آلية إجماع مخصّصة خاصة به، ومعايير رمزية، ومنصات عقود ذكية.

ضمن شبكة Cosmos، توجد نوعان متميزان من البلوك تشينات: “hubs” و“zones” [3]. “الـ Zones” سهلة الفهم نسبيًا — وهي ببساطة السلاسل المخصصة للتطبيق التي تُشغّل التطبيق نفسه (مثل مُبدّل لامركزي أو لعبة على السلسلة). أما “الـ Hubs” فتعمل على ربط هذه “الـ zones” و“hubs” الأخرى معًا بهدف تمكين الاتصال بين السلاسل عبر “بروتوكول الاتصال بين البلوك تشينات” (IBC).

في قلب شبكة Cosmos توجد “Cosmos Hub”، وهي أول سلسلة “Hub” تم بناؤها على شبكة Cosmos، وتعمل عمليًا كمركز “محطة سنترال” كبرى لجميع الـ hubs وzones الأخرى. ومع ذلك، وكما يظهر في المخطط أعلاه، فإن “Hubs” لا تحتاج بالضرورة إلى الاتصال بـ Cosmos Hub. فعلى سبيل المثال، يمكن لشركة خاصة أن تختار إطلاق Hub خاص بها يربط الـ zones الخاصة بها.

في الحقيقة، يركّز Cosmos SDK على قابلية التخصيص وقابلية التشغيل البيني، ويُتاح للمطورين مجال واسع لترك خيالهم يعمل بحرية. ضمن منظومة Cosmos توجد بعض سلاسل L1 عامة الاستخدام الرئيسية، مثل سلسلة EVM-Compatible BNB Chain (التي كانت تُسمّى في الأصل Binance Smart Chain) [4]. بالنسبة لباني appchain، فإن قابلية التشغيل البيني لشبكة Cosmos تمكّن بشكل كبير، لأنها تسمح لـ appchain بالوصول إلى البيانات من مجموعة كبيرة من السلاسل عبر IBC. وهذه إحدى الأسباب التي تجعل العديد من appchains المبنية باستخدام شبكة Cosmos تكون منصات oracles أو مُبدّلات متعددة السلاسل (multi-chain DEXs) أو خدمات أخرى تتطلب تجميع البيانات من طيف واسع من السلاسل المختلفة.

Hyperledger Fabric

هناك طريقة أخرى لتنفيذ appchains وهي عبر Hyperledger Fabric، وهو نظام بلوك تشين مفتوح المصدر لبناء تطبيقات وحلول بدرجة مؤسسية. وهو واحد من المشاريع ضمن مظلة Hyperledger، والتي تستضيفها Linux Foundation [5].

مثل Cosmos SDK، صُمم Hyperledger Fabric لدعم بنية شبكة بلوك تشين نمطية ووحداتية (modular) وتقديم مرونة في بناء ونشر التطبيقات المعتمدة على البلوك تشين. يوفّر بنية قابلة للتوصيل والتشغيل (plug-and-play) تتيح إضافة أو استبدال مكونات مثل الإجماع وخدمات العضوية وتنفيذ العقود الذكية (chaincode) بسهولة. لكن الاختلاف الأهم بين Cosmos SDK وHyperledger Fabric يتمثل في نوع الجمهور: يوجّه Cosmos SDK إلى مستخدمي ومطوري Web3 الأصليين، بينما يستهدف Hyperledger Fabric عملاء مؤسسات بدرجة مؤسسية. لذلك، بينما يركز Cosmos SDK على بناء نظام لامركزي وقابل للتشغيل البيني، يركز Hyperledger Fabric على بناء شبكات خاصة ومُصرّح بها حيث يجب أن يتم الترخيص للمشاركين صراحةً للانضمام إلى الشبكة والمشاركة فيها.

في الواقع، تعمل appchains على مستوى المؤسسات بطريقة مختلفة تمامًا عن appchains من نوع Web3-native. إذ بينما تركز appchains من نوع Web3-native غالبًا على tokenomics وتستخدم بنية البلوك تشين لتسييل منتجاتها ماليًا، فإن appchains على مستوى المؤسسات تركز على استخدام البلوك تشين كوسيلة فعّالة لتسجيل البيانات والمحافظة عليها. ومن حيث الجوهر، تعتمد هذه appchains المؤسسية على حقيقة أن البلوك تشينات هياكل بيانات غير قابلة للتلاعب وقابلة للتحقق ومضافة فقط (append-only)، ويمكن أن تتوزع كُتّاب البيانات عبر الزمن والمواقع الجغرافية. وبشكل أساسي، تسعى appchain مبنية على Hyperledger Fabric إلى استبدال قواعد البيانات البالية وغير الفعالة التي احتفظت بها الشركات لسنوات طويلة.

كما هو موضح في المخطط أعلاه، فإن جميع “العُقد المصرّح بها” (permissioned nodes) على بلوك تشين Hyperledger Fabric هي موظفون في مختلف أجزاء سلسلة التوريد، يستخدمون البلوك تشين كطريقة لتسجيل حالات بيانات مختلفة بشكل متزامن — مثلًا إذا دخلت قطعة منتج إلى مصنع أو متجر. لا يوجد تقريبًا تركيز على قابلية الاتصال البيني بين سلاسل مختلفة، وعلى عكس Cosmos، لا يوجد دعم أصلي للاتصال بين السلاسل عبر Hyperledger Fabric. بدلًا من ذلك، توجد واجهات برمجة بيانات (data APIs) وواجهات للتكامل مع شبكات بلوك تشين أو أنظمة أخرى. هذا يعني أنه يمكن بناء حلول للتواصل بين السلاسل باستخدام Hyperledger Fabric، لكن ذلك يتطلب تطويرًا وتكاملًا مخصصًا، على خلاف التصميم المدمج hub-and-zone في منظومة Cosmos. ومن المنطقي حدسيًا أن هذا يحدث: فباعتبارها appchain على مستوى المؤسسة، تكون البلوك تشينات المبنية باستخدام Hyperledger fabric غالبًا معزولة عن العالم الخارجي — بعد كل شيء، لا تريد أن يتلاعب الجمهور ببيانات سلسلة التوريد الخاصة بك.

إحدى دراسات الحالة لعمل Hyperledger Fabric تتمثل في إدارة سلسلة توريد Walmart. تتمثل appchain الخاصة بـ Walmart، والمعروفة أيضًا باسم “Walmart Food Traceability Platform”، في نظام لتتبّع وتتبع الأغذية قائم على البلوك تشين صُمم لتحسين سلامة الغذاء والشفافية في سلسلة التوريد [6]. تتيح appchain الخاصة بـ Walmart تتبع وتتبع منتجات الطعام من المزرعة إلى رفوف المتاجر، مما يساعد على تحديد مشكلات سلامة الغذاء المحتملة وعزلها بسرعة. في كل مرحلة من مراحل العملية، كان على الموردين رفع الملصقات وشهادات الأصالة عبر واجهة ويب إلى البلوك تشين، حيث تصبح متاحة بشكل دائم لجميع أصحاب المصلحة ذوي الصلة. وبما أن البلوك تشين يعمل كحقيقة واحدة “ground truth” للمعلومات، فقد خفّض ذلك بشكل كبير الوقت اللازم لتسجيل وتتبع مشكلات جودة الطعام، مثل الأمراض المنقولة بالغذاء:

نجح نظام تتبع سلامة الأغذية المبني على Hyperledger Fabric للمنتجين محل التطبيق. ففي حالة لحم الخنزير في الصين، أتاح رفع شهادات الأصالة إلى البلوك تشين، مما أضاف قدرًا أكبر من الثقة إلى نظام كان يشكّل تحديًا جديًا من قبل. وبالنسبة للمانجو في الولايات المتحدة، انخفض الوقت المطلوب لتتبّع مصدره من 7 أيام إلى… 2.2 ثانية! — Hyperledger Foundation [6]

وبالتالي، يُظهر Hyperledger استخدام appchains في سياق مختلف تمامًا عن Cosmos — في حالات استخدام مؤسسية واسعة حيث يُستخدم البلوك تشين كبديل لطرق التسجيل والتتبّع التقليدية للبيانات. يمكن بالطبع القول إن حالة استخدام appchains هذه “ليست Web3 فعليًا” لأنها لا تستفيد من tokenomics واللامركزية ومبادئ التشفير الأصلية بالطريقة نفسها. لكن لا يمكن تجاهل تبنّي الشركات appchains — فالتقنية الأساسية نفسها، وهي خطوة حيوية لاكتساب ثقة عامة بتقنيات البلوك تشين تمهيدًا للتبنّي الشامل. وعلى المدى الطويل، إذا كان لدى شركات مثل Walmart إعداد appchain، يصبح من الأسهل بكثير دمجها في عالم “Web3-native”.

Rollups-as-a-Service

هناك مقاربة بديلة أحدث لبناء appchains تتمثل في استخدام rollups، وخصوصًا عبر “rollups-as-a-service” (RaaS). تُعد rollups-as-a-service نوعًا من حلول توسيع البلوك تشين يسمح بالحوسبة والتخزين خارج السلسلة مع الحفاظ على أمان وثقة البلوك تشين الأساسي. تعمل هذه الحلول عبر تجميع عدد كبير من المعاملات في معاملة واحدة مضغوطة يتم تسجيلها بعد ذلك على L1 أساسي، وغالبًا ما تكون Ethereum.

يمكن استخدام rollups من أجل appchains لأنها توفر طريقة لتوسيع معالجة وتخزين المعاملات للتطبيقات اللامركزية (dApps) المبنية على هذه السلاسل، دون التضحية بأمان وثقة البلوك تشين الأساسي. ورغم أن المطور قد يتنازل عن بعض قابلية التخصيص في طبقة الإجماع الأساسية مقارنةً بحل قائم على Cosmos، توجد عدة مزايا لاستخدام rollup-as-a-service لسلسلة بلوك تشين مخصصة لتطبيق محدد بدلًا من سلسلة كاملة.

ربما تكون أهم ميزة هي أنه لا حاجة للمطورين لتهيئة مجموعة مُصدّقين (validator set). وبما أن الإجماع والتسوية يتم تفويضهما إلى L1 أساسي، فهذا لا يؤدي فقط إلى حل appchain أرخص، بل يجعله أيضًا أكثر متانة لأنه محمي عبر L1 الأساسي. علاوة على ذلك، وبما أن rollups حلول عمودية (vertical) ووحدية في بنيتها، فهي ليست مقيدة بإطار عمل بلوك تشين واحد، ويمكنها الاستفادة من البيانات والوظائف في عدة بلوك تشينات.

بشكل أساسي، في نموذج appchain المعتمد على rollup، تصبح سلاسل L1 هي المكافئ لـ “Hubs” التي تحتوي على ثروات من البيانات والأمان. على سبيل المثال، قد تستخدم appchain للألعاب حلاً مبنيًا على rollup حيث يتم الاستفادة من أمان Ethereum للإجماع والتسوية، بينما يمكن الاستفادة من Solana ذات الإنتاجية العالية لتنفيذ أسرع [7].

توفر شركات Rollups-as-a-service البنية التحتية والخدمات اللازمة لمطوري appchain لتنفيذ حل rollup appchain المخصص الخاص بهم. تقوم RaaS المختلفة بتجريد هذه الأدوات إلى مستويات مختلفة: فبعض المشاريع مثل Op Stack [8] مبنية على SDK، مما يسمح للمطور بتخصيص الـ rollup بدرجة كبيرة نسبيًا. وفي المقابل، تركز مشاريع مثل Constellation على حل نشر كامل بدون كود (“white-glove”)، يسمح لمطوري appchain بالتركيز على جزء “التطبيق” من التطوير، بدلًا من جزء “السلسلة” من التطوير [9].

الانعكاسات المترتبة على Appchains

إن ظهور وصعود حلول appchain هذه يحمل عدة آثار عميقة على مشهد البنية التحتية لـ Web3 بشكل عام. تُدخل appchains تغييرًا نموذجيًا في العلاقة بين “السلاسل” و“التطبيقات” من نموذج قائم على العرض إلى نموذج قائم على الطلب.

في السابق، عندما كانت حلول البنية التحتية لا تزال في طور النضج، وما تزال مفاهيم حديثة عديدة للبنية التحتية مثل Proof of Stake والتجزئة (sharding) وrollups في مرحلة إثبات المفهوم، كانت مشاريع البنية التحتية غالبًا تُنفَّذ من أجل استكشاف جدوى حلول تقنية كهذه. وهذا هو الأكثر شيوعًا في “البلوك تشينات من الجيل الثالث” مثل Avalanche وCardano وNEAR وSolana. لقد قاد عرض هذه السلاسل (إنتاجيتها وتنفيذاتها التقنية) الطلب عليها. وبعبارة أخرى، فإن تصميم “السلاسل” هو الذي حدد تصميم “التطبيقات”.

ومع ذلك، فإن صعود appchains يشير إلى جيل رابع متميز من البلوك تشينات، حيث يدفع الطلب على البلوك تشينات عرض هذه البلوك تشينات. إن جميع المسارات التقنية التي سبق عرضها — شبكة Cosmos وHyperledger Fabric وRollups-as-a-Service — تقدم حلول نشر بلوك تشين plug-and-play سهلة وقابلة للتخصيص وفعالة من حيث التكلفة. لم يكن من الأسهل أبدًا تصميم بلوك تشينك وتخصيصه ونشره. وبسبب ذلك، صار الأمر معكوسًا: فتصميم “التطبيقات” هو الذي يحدد تصميم “السلاسل”.

إحدى النتائج المحتملة لذلك هي أن مشهد L1 سيصبح أكثر تركيزًا على الأرجح، مع انتقال من مشهد على نمط المنافسة الاحتكارية (حيث تتميّز L1s المختلفة عن بعضها بشكل طفيف) إلى مشهد احتكاري قِلِّي يهيمن عليه عدد قليل من سلاسل محددة تمتلك نظمًا بيئية هائلة وسيولة ضخمة. ويحدث ذلك لأنّه مع بروز appchains تقلّ الحاجة إلى قيام التطبيقات اللامركزية عالية المستوى (DApps) بالنشر على L1s أصغر بدلًا من تشغيل سلسلتها الخاصة (بميزات قابلة للتخصيص بلا حدود) أو نشر rollup appchain على L1 كبير راسخ. ببساطة، لا تستطيع سلاسل L1 الأصغر منافسة مزيج L1s الكبيرة وappchains من حيث المرونة والتخصيص والأمان والدعم.

علاوة على ذلك، تُعد appchains أيضًا آلية رئيسية لضم المؤسسات إلى Web3. كما ذُكر سابقًا، رغم أن سلاسل المؤسسات مثل Hyperledger تُستثنى عادةً من تصورنا المعتاد لـ Web3، فإنها تعتمد على تقنيات البلوك تشين الأساسية نفسها لتحقيق شفافية أكبر في اللوجستيات وإدارة سلسلة التوريد. فَلِمَ لا يمكن توسيع ذلك ليشمل المدفوعات وما وراءها؟ لذلك أعتقد أنه لن يكون إلا مسألة وقت قبل أن تصبح سلاسل البلوك تشين بدرجة مؤسسية أعلى اندماجًا مع مشاريع Web3 اللامركزية الأصلية مثل DeFi والمدفوعات وNFT. في الواقع، توجد بالفعل بعض محاولات استكشاف قابلية توسيع Cosmos IBC بعيدًا عن Cosmos appchains فقط، وربط منصات مثل Hyperledger Fabric، واستهداف حلول بلوك تشين مؤسسية بدرجات أخرى [10].

الخلاصة

في وقتنا هذا، من الواضح أنه لم يكن ولن يكون هناك بلوك تشين واحد يصلح للجميع. سواء عبر Cosmos SDK أو Hyperledger Fabric أو Rollups-as-a-Service، فإن نضج وسهولة نشر appchains مخصصة سيحوّلان مساحة البنية التحتية لـ Web3 إلى تجربة تضع التطبيق أولًا والمستخدم أولًا — علامة على ازدياد النضج في Web3. إن مستقبل مساحة Web3 هو مجرّة متعددة السلاسل، وبالنظر إلى قابلية تخصيصها وفاعليتها وسهولة نشرها، ستلعب appchains دورًا متزايد الأهمية باستمرار في هذا الكون، لتتألق مثل النجوم في مجرّة اللامركزية.

🐦 @0xfishylosopher

📅 6 فبراير 2023

المراجع

[1] Osmosis, مُبدّل (DEX) عبر السلاسل: https://osmosis.zone/

[2] Curio.gg, شركة ألعاب على السلسلة: https://www.curio.gg/

[3] https://newsletter.banklesshq.com/p/a-beginners-guide-to-cosmos

[4] انظر ورقة BNB Chain البيضاء: https://github.com/bnb-chain/whitepaper/blob/master/WHITEPAPER.md

[5] https://www.ibm.com/products/blockchain-platform-hyperledger-fabric

[6] دراسة حالة Walmart: https://www.hyperledger.org/learn/publications/walmart-case-study

[7] مثال من https://messari.vercel.app/article/the-rollups-as-a-service-ecosystem

[8] انظر https://www.optimism.io/op-stack

[9] انظر https://constellation-labs.gitbook.io/constellation-labs-documentation/getting-started/overview

[10] https://medium.com/the-interchain-foundation/expanding-the-interchain-taking-ibc-beyond-cosmos-appchains-b0f9bebb4405

إخلاء المسؤولية: المعلومات الواردة أعلاه لأغراض تعليمية بحتة ولا تشكّل نصيحة مالية، وتمثل وجهات نظر المؤلف وحده.

شكرًا جزيلاً لأصدقائي في Constellation Labs على محادثاتهم الثاقبة حول Rollups-as-a-Service.