في الآونة الأخيرة، تشهد هونغ كونغ سلسلةً من المؤتمرات المهمة، بينما يشهد السوق الأولي انتعاشًا ملحوظًا. وخلال الربع الأول من العام الحالي، قام فريق ABCDE بدراسة أكثر من ١٠٠ مشروعٍ، وعاين بشكلٍ مباشرٍ عدة قطاعات ساخنة جدًّا في السوق، وأبرزها: Appchain وZK والألعاب (Gaming).
وقد شهدت هذه القطاعات الثلاثة تغيراتٍ ملحوظةً منذ بداية العام، ما دفعنا إلى إعادة التفكير فيها وتوثيق رؤيتنا في مذكّرة (Memo) نُقدّمها لكم كمرجعٍ.
أولًا: Appchain (وخاصةً RAAS — Rollup as a Service)
إن قطاع RAAS ظهر في أواخر العام الماضي، ويرتبط ظهوره ارتباطًا وثيقًا بإطلاق منصة OP Stack. ومع ذلك، فإن مفهوم «Appchain as a Service» كان موجودًا منذ وقتٍ أطول، حيث تمثّله منصّة Cosmos SDK على سبيل المثال لا الحصر. وبعد أن طرحت Celestia مفهوم «البلوكشين الوحدية» (Modular Blockchain)، بدأ هذا القطاع يكتسب زخمًا متزايدًا، ويمكن اعتبار RAAS أحد أحدث التفرعات الساخنة ضمن هذا المجال.
فلماذا يُعتقد أن قطاع «Appchain as a Service» قد وصل إلى مرحلة «التضخيم المفرط» (OverHype) حديثًا؟
أولاً، إذا كنتَ مطوّرًا وتودّ إنشاء سلسلة تطبيقات (Appchain) خاصة بك، فإن الخيارات المتاحة أمامك هي كما يلي:
إذا كانت سلسلتك تعتمد على بيئة تنفيذ الإيثريوم (EVM)، فيمكنك:
١. إنشاء سلسلة جانبية مستقلة تمامًا لـ ETH على غرار Ronin (ويُرجّح أن عدد القليل جدًّا من المطورين سيختارون هذا الخيار اليوم)
٢. استخدام منصة Skale لإنشاء سلسلة جانبية لـ ETH
٣. إطلاق سلسلة باستخدام منصة Avax والانضمام إلى سلسلة P الخاصة بها
٤. استخدام منصة Polygon Supernet لإطلاق سلسلة EVM
٥. استخدام منصة BAS لإنشاء سلسلة جانبية تعتمد على BNB Chain
٦. استخدام منصة OP Stack لإنشاء سلسلة تطبيقات على شكل Rollup
٧. استخدام منصة Caldera لإنشاء سلسلة تطبيقات على شكل Rollup (وهي في الأساس تعتمد أيضًا على OP Stack)
٨. استخدام منصة Zk-Sync لإنشاء طبقة ثالثة (L3) (ومن المتوقع ظهور أولى هذه الحلول خلال هذا العام)
٩. وفي الوقت الذي نكتب فيه هذه السطور، أعلنت Arbitrum للتو عن منصتها الجديدة Orbit، وهي بنية تحتية لطبقة ثالثة (L3) مشابهة لمنصة OP Stack
١٠. كما يوجد عددٌ كبيرٌ من المشاريع الأخرى التي لا تزال قيد التطوير، مثل Opside وStackr وSovereign SDK وغيرها
أما إذا كانت سلسلتك غير معتمدة على بيئة تنفيذ الإيثريوم (Non-EVM)، فيمكنك:
١. استخدام منصة Cosmos SDK لإنشاء سلسلة، سواء بشكل مستقل تمامًا أو بالاستفادة من أمان رمز ATOM (بعد اعتماد اقتراح ICS مؤخرًا)
٢. استخدام منصة Substrate لإطلاق سلسلة، سواء عبر المنافسة على الحصول على فتحة في شبكة Polkadot أو الانضمام إلى شبكة Octopus Network أو التشغيل المستقل دون الارتباط بأي شبكة خارجية
٣. استخدام منصة Rollkit التابعة لـ Celestia لإنشاء سلسلة تطبيقات على شكل Rollup، مع الاعتماد على Celestia لتوفير طبقة البيانات (DA)، بينما تبقى عملية التسوية اختيارية
٤. استخدام منصة Dymension لإنشاء سلسلة تطبيقات على شكل Rollup
٥. استخدام منصة Saga لإنشاء سلسلة تطبيقات على شكل Rollup
٦. الاعتماد على تقنية Starkware لإنشاء طبقة ثالثة (L3) (ومن المتوقع ظهور أولى هذه الحلول خلال هذا العام)
٧. وبلا شك، هناك العديد من المشاريع الأخرى التي لا تزال قيد التطوير، والتي قد تكون غير معروفة لنا أو لم تُذكر هنا
هل تشعر بأن «عدد الخيارات أصبح وفيرًا جدًّا؟!»
ثانيًا، أي التطبيقات بالضبط تناسب التحوّل إلى سلسلة تطبيقات (Appchain)؟ هل تتذكّر المقال الشهير الذي نُشر قبل أشهر حول ما إذا كان ينبغي لمنصة Uniswap أن تتحول إلى سلسلة تطبيقات، وما رافقه من نقاشات واسعة النطاق؟
وبشكل عام، فإن تحويل Uniswap إلى سلسلة تطبيقات قد يمنحها مزايا مثل: تحقيق عوائد من رسوم التداول، والاستحواذ على قيمة الرمز المميز، ومقاومة ظاهرة MEV، واحتكار الموارد. لكن في المقابل، ستتعرض لسلبيات تشمل: تدهور تجربة المستخدم، وانخفاض مستوى الأمان، وضعف القدرة على التكامل (Composability).
وباختصار، لم نشهد حتى الآن أي خطط أو «طموحات» من Uniswap لتحويل نفسها إلى سلسلة تطبيقات.
أما منصة Compound، فقد كانت تخطط في الأصل لإنشاء سلسلة باستخدام Substrate، لكنها تراجعت عن الفكرة لاحقًا. واليوم، تُنفّذ كلٌّ من Compound وAave V3 استراتيجيتها عبر عدة سلاسل (Multi-chain deployment)، ما يجعل احتمال تحولهما إلى سلاسل تطبيقات ضئيلًا جدًّا في الوقت الراهن.
أما منصة Curve، فلا يبدو أنها كانت تفكر في هذا الخيار إطلاقًا.
وحدها منصة dYdX، التي لا تعتمد كثيرًا على القدرة على التكامل (Composability)، اختارت الانتقال إلى نظام Cosmos لإنشاء سلسلة تطبيقات خاصة بها، ومن المتوقع أن تُطرح في الربع الثالث من هذا العام. وقد تكون هذه السلسلة، بعد انهيار Luna، أبرز سلسلة تطبيقات تستحق الترقب. وستُظهر dYdX للمطورين (Builders) مسارًا واضحًا: فإذا كنت تمتلك موقع الصدارة في قطاعٍ ما، ولا تتطلب تطبيقاتك درجة عالية من التكامل، فإن الانفصال لإنشاء سلسلة تطبيقات «ذات سيادة + أداء عالٍ» هو خيارٌ منطقيٌّ تمامًا. أما قبل ذلك، فيمكنك البدء بالانضمام إلى إحدى السلاسل العامة (General-purpose chains) لتطوير تطبيقك اللامركزي (Dapp) تدريجيًّا وتحسين أدائه، ثم الانطلاق بمفردك عند بلوغ المستوى المطلوب.
وهذا المسار يبدو عمليًّا نسبيًّا. فعلى سبيل المثال، إذا نما تطبيق SocialFi مبني على بروتوكول Lens وحقق انتشارًا واسعًا ومستوى عالٍ من النشاط اليومي (DAU)، بحيث يصبح أداء شبكة Polygon غير كافٍ لتلبية احتياجاته، فإن الانفصال وإنشاء سلسلة تطبيقات على شكل Rollup باستخدام إحدى البنية التحتية المذكورة أعلاه سيكون خيارًا منطقيًّا تمامًا. ومع ذلك، وعلى المدى القصير، يُرجّح أن عدد التطبيقات التي تحقق هذه الشروط ويكون لديها أساسٌ كافٍ لإطلاق سلسلة خاصة بها لا يزال أقل من عدد البنية التحتية المتاحة حاليًّا...
أما القطاعات التي تصلح بطبيعتها لأن تبدأ مباشرةً بإطلاق سلسلة تطبيقات، فهي القطاعات التي ستكون أكبر مستخدمٍ لهذه البنية التحتية. وقبل أن تُحلّ تمامًا مشكلة التكامل بين السلاسل المختلفة (Inter-chain Heterogeneous Composability)، فإن احتمال اعتماد منصات DeFi خارج نظام Cosmos على هذا النهج يظل ضئيلًا. أما القطاع الأنسب لهذا النموذج بلا شك فهو GameFi (بما في ذلك عوالم «الاستقلال الذاتي على السلسلة» Onchain Autonomous Worlds). ومن الأمثلة على ذلك: DFK وCrab المبنية على AVAX، ومشروع OPcraft الذي أثار اهتمامًا واسعًا مؤخرًا، ومشروع Curio الذي استخدم منصة Caldera لإطلاق سلسلته.
وبعد مراجعة محافظي الصغيرة (MetaMask) وKeplr، أدركتُ أنه بعد انهيار Luna، لم أستخدم سوى سلسلتي DFK وOsmosis من بين سلاسل التطبيقات الأخرى. وهذا ما يدفعني للتساؤل: هل حقًّا يحتاج دورة السوق الحالية إلى «عشرات السلاسل التطبيقية أو خدمات Rollup as a Service» بهذه الكثافة الهائلة من البنية التحتية؟
وأخيرًا، يمكننا تخصيص «نقد لطيف» منفصلٍ حول تقنية RAAS التي اكتسبت شعبية كبيرة مؤخرًا.
1.1. سلسلة OP
في الوقت الراهن، تعتمد معظم حلول RAAS المستندة إلى سلسلة OP على نسخ (Fork) بنية OP Stack، وهي في الأساس لا تتضمن أي عوائق تقنية حقيقية. فكود وتوثيق OP مُكتوبان بشكلٍ منظمٍ جدًّا وواضحٍ للغاية، وبفضل ذلك يستطيع خبراؤنا التقنيون في شركة ABCDE إنشاء سلسلة تطبيقات (Appchain) قائمة على OP Rollup خلال أقل من يومٍ واحدٍ فقط باتباع الوثائق المقدمة. وبالتالي فإن القيمة التي تقدمها هذه الحلول لعملائها تتركز أساسًا في خدمات مثل Sequencer ومستعرض الكتل (Block Explorer) والنشر السريع وغيرها من الخدمات الإضافية، حيث تفوق قدرتها التسويقية قدرتها التقنية بكثير.
أما فيما يخص أداء سلسلة التطبيقات (Appchain) من هذه الفئة — مثل معدل معالجة المعاملات (TPS)، ووقت إنشاء الكتل، وتكاليف الاستخدام — فهي متطابقة تمامًا مع أداء شبكة Optimism العامة، دون أي تحسينات في الأداء أو التكاليف. وبالتالي، ومن الناحية النظرية، ما لم تواجه شبكة OP ازدحامًا شديدًا، فلن تحصل على تجربة استخدام «أفضل» على هذه السلسلة مقارنةً بالشبكة العامة لـ OP. كما أن العيوب الحالية لشبكة OP ستورثها هذه الحلول بالكامل، مثل آلية إثبات الاحتيال (Fraud Proof) التي لا تزال غير مُفعَّلة حتى الآن ولا يوجد موعد محدد لإطلاقها...
ومع ذلك، لا بد من الإشادة برؤية OP Stack كـ«سلسلة فائقة» (Superchain). فكلما زاد عدد سلاسل Rollup المبنية على OP Stack أو على إصداراتها المنسوخة (OP Stack Fork)، زادت احتمالية تحول OP Superchain إلى هيكلية تشبه هيكلية Polkadot، تتميز بعدم الحاجة إلى مزاد لحجز الفتحات (slot auction)، وتدعم بروتوكولات اتصال مدمجة، وتسمح بالتركيب التفاعلي الكامل (fully asynchronous composability). وعلى الرغم من أن هذه الرؤية لا تزال بعيدة المنال، فإن «الكعكة» التي رُسِمت بها تبدو جذابةً حقًّا. كما استفادت OP من سردية OP Stack لتنافس Arbitrum بقوة في مجال الابتكارات اللامركزية في DeFi، حيث وصل التنافس بينهما إلى مستوى التعادل. وعندما كنتُ أكتب التقرير، أعلنت Arbitrum للتو عن إطلاق منصة Orbit، فقلتُ حينها إن Arb لن تفوّت فرصة الاستيلاء على هذه القطعة الكبيرة من السوق، وبالفعل أطلقت العملة الجديدة مع مشاريع جديدة دفعة واحدة. وهكذا عاد التنافس بين OP وArb ليأخذ منحنى جديدًا!
1.2. سلسلة ZK
من الناحية النظرية، قد تُحسّن حلول RAAS القائمة على تقنية ZK تجربة مستخدمي سلاسل التطبيقات (Appchain)، لأن المشاريع مثل ZK-Sync وScroll التي تتبع مسار ZKEVM تركّز بشكل أساسي على تحقيق التوافق (compatibility)، مما يعني أن تصميم الدوائر (circuit design) يضحي جزئيًّا بكفاءة الأداء، وبالتالي لا يمكنه تحسين الأداء خصيصًا لتطبيقات لامركزية (Dapps) معينة. أما إذا كانت حلول RAAS قادرة على تصميم دوائر مخصصة أو تحسينها وفقًا لاحتياجات كل تطبيق لامركزي (DAPP) على حدة، فإن أداء وتجربة سلاسل التطبيقات القائمة على ZK سيكون بالتأكيد أفضل من تلك الخاصة بسلاسل ZkEVM العامة.
ومع ذلك، فإن عدد الأشخاص الذين يجمعون بين الخبرة في تقنيات ZK ومعرفة عميقة ب(blockchain) ضئيلٌ للغاية في العالم اليوم، وأغلب هؤلاء الخبراء المتفردين يتوزعون حاليًّا بين Starknet وZk-Sync وScroll وPolygon. أما بالنسبة لحلول RAAS القائمة على ZK المتاحة حاليًّا في السوق، فهي في الغالب لا تفعل أكثر من إصدار سلسلة Zk-Sync منسوخة (Fork) باستخدام النسخة المفتوحة المصدر (Alpha open-source version) من Zk-Sync. وبعد أن تُطلق Polygon وScroll إصداراتها النهائية وتُصبح مفتوحة المصدر بالكامل، فإن دور هذه الحلول سيقتصر على تقديم خيارات للعملاء: هل تفضل استخدام بيئة EVM الخاصة بـ ZK-Sync أم Polygon أم Scroll؟ وهذا يشبه تمامًا اختيار نظام تشغيل عند إنشاء جهاز افتراضي (Linux VM) على منصة AWS: هل تختار Red Hat أم CentOS أم Debian؟
وبالتالي، فإن هذه الحلول لا تملك أيضًا أي عوائق تقنية حقيقية، بل تظل المبيعات والتسويق (BD) هي العامل الحاسم فيها، وهي أقل نضجًا من حلول سلسلة OP، إذ إن الإصدارات النهائية لمعظم سلاسل ZK-Rollup لم تُطلق بعد أو لم تُفتح مصادرها بالكامل. وكل ما هو متاح حاليًّا لا يزال عبارة عن إصدارات تجريبية مفتوحة المصدر، وهي بطبيعتها عرضة للأخطاء (Bugs) وتفتقر إلى الانسيابية في الأداء مقارنةً بسلاسل OP. ونأمل أن نرى في المستقبل ظهور حلول RAAS قائمة على ZK تقوم بتصميم دوائر مخصصة أو تحسينها لكل سلسلة تطبيقات (Appchain) على حدة.
ثانيًا. تقنية ZK
إذا اعتبرنا سوق «سلاسل التطبيقات كخدمة» (Appchain as Service) أحد أبرز المسارات التمثيلية للبلوك تشين المُعيَّرة (modular blockchain)، فإن العام الحالي يشهد صعود两大 مدرستين بارزتين في عالم البلوك تشين: المُعيَّرة (Modular) وتقنية ZK.
ويمكن تحليل العوائق التي تواجه تقنية ZK من عدة جوانب:
2.1. الطبقة الثانية (Layer 2)
التوسع (Scalability)
هذا أمرٌ لا يحتاج إلى شرح، فقد أطلقت أكبر سلاسل ZK-Rollup شبكاتها الرئيسية (mainnets) هذا العام. ومع ذلك، فإن مجرد الإطلاق لا يعني انتهاء المشكلات، بل إن العديد منها لا يزال يعاني من تحديات عديدة بعد الإطلاق.
درجة الإنجاز (Completeness)
حتى الآن، أطلقت كل من ZK-Sync وScroll وPolygon شبكاتها الرئيسية المتوافقة مع بيئة التشغيل الافتراضية لـ Ethereum (EVM)، باستثناء Starknet التي لم تُطلق بعد شبكة رئيسية متوافقة مع EVM. ومع ذلك، تعمل مشروع «كاكاروت» (Kakarot) — الذي يُعتبر المشروع الرسمي التابع لـ Starknet — على تنفيذ نسخة ZKEVM. وقد أفادني خبراء ZK من داخل القطاع أن إطلاق الشبكات الرئيسية لأبرز سلاسل ZK-Rollup كان يحمل طابع «الإجبار على الإطلاق» («forcing the launch») إلى حدٍّ ما، وأن درجة إنجاز أو نضج هذه المنتجات لا تزال بعيدة عن المستوى التقليدي المتعارف عليه لـ«الشبكة الرئيسية الجاهزة للإنتاج». ولذلك، فمن المرجح أن تواجه هذه الشبكات مشكلات في الأداء أو الأخطاء البرمجية (Bugs) بعد الإطلاق، وستحتاج بالتالي إلى تحديثات مستمرة وإصلاحات دورية. ويمكن ملاحظة هذه الحقيقة من خلال التأجيل المتكرر لإطلاق شبكات الاختبار (testnets) من العام الماضي وحتى هذا العام. ويعود السبب الرئيسي في ذلك إلى صعوبة تنفيذ ZKEVM نفسها، وهي صعوبة بالغة لدرجة أن أكفأ المهندسين في المجال يحتاجون وقتًا أطول بكثير مما كان متوقعًا في الأصل لتجاوزها. أما سبب الإسراع في إطلاق الشبكات الرئيسية هذا العام، فيرتبط على الأرجح بالضغط الناتج عن التطور المستمر في بيئات OP، وتحديثاتها المتواصلة وازدياد استقرار شبكتها الرئيسية، الأمر الذي أجبر فرق ZK على الإسراع في الإطلاق قبل أن «تبرد الوجبة» (يُقصد به تأخر الفرص). وبما أن النظام يعمل بشكل أساسي، فسنُطلقه أولًا، ثم نقوم بتحديثاته وتطويراته لاحقًا.
الأداء (Performance)
إن أداء حلول ZK، على الأقل في المرحلة الحالية، يكون أقل من أو يساوي أداء حلول OP. وبالطبع، قد لا يشعر المستخدمون بهذا الفرق، لأن كلا النوعين يوفّران تأكيدًا للمعاملات خلال بضع ثوانٍ عبر الـ Sequencer، بينما يتم إعداد إثباتات ZK تدريجيًّا (عادةً ما يستغرق إعداد إثبات كتلة واحدة من 10 إلى 20 دقيقة). أما بالنسبة لـ«الاستقرار النهائي» (Finality) الحقيقي للمعاملة على شبكة ETH L1، فهو أمرٌ لا يهتم به المستخدمون عادةً ولا يشعرون به. أما التحسينات الحالية في الدوائر (circuit optimization) أو التسريع المادي (hardware acceleration)، فهي تهدف في المقام الأول إلى تسريع فترة الإثبات التي تستغرق 10–20 دقيقة، لكنها لا تؤثر عمليًّا على تجربة المستخدم.
التكاليف (Fees)
بينما تكاد تكلفة إثبات الاحتيال (Fraud Proof) في شبكة OP تكون معدومة، فإن إعداد إثباتات ZK يتطلب استهلاك كميات هائلة من قوة الحوسبة، وهذه القوة لها ثمنٌ. بالطبع، يمكنك القول إن كمية البيانات التي ترفعها حلول ZK إلى شبكة L1 أقل من تلك التي ترفعها حلول OP، وبالتالي تكون تكلفة رسوم الغاز (Gas) المدفوعة لنقل البيانات عبر CallData أقل. لكن هذا التخفيض في الرسوم غالبًا ما لا يُعوّض التكاليف الإضافية المترتبة على عملية الإثبات (Proving)، خاصةً بعد إطلاق ترقية EIP-4844 (Blob)، التي ستقلل تكاليف رفع البيانات إلى L1 بشكل كبير، ما سيجعل ميزة OP في التكلفة أكثر وضوحًا مقارنةً بالوضع الحالي.
الأمان (Security)
هذه مسألة ذات وجهين، ويعتمد الحكم عليها على التصور الشخصي. فالفهم التقليدي يقول إن أمان ZK يستند إلى براهين رياضية، بينما يعتمد أمان OP على التوازن الاقتصادي (economic game theory)، والرياضيات أقوى من التوازن الاقتصادي، وبالتالي فإن ZK أكثر أمانًا من OP.
وهذا صحيح بالتأكيد على المدى الطويل.
لكن هذا ليس بالضرورة صحيحًا في المرحلة الحالية.
فالمعنى الحقيقي للأمان هو أن تتحقق المعاملة «نهائيًّا» (finalized) على شبكة ETH L1. وفي الوقت الراهن، تقوم شبكة Arbitrum بإرسال التحديثات كل دقيقتين أو ثلاث دقائق، بينما تقوم شبكة OP بذلك كل 10 دقائق تقريبًا. أما في حالة ZK، فإن إعداد الإثبات يستغرق وقتًا وموارد كبيرة، لذا فإن الفترة الزمنية اللازمة لتحقيق الاستقرار النهائي تبلغ عادةً 10–20 دقيقة، وذلك في حال امتلاء الكتل بالكامل. أما إذا كانت البيئة غير مزدهرة بما يكفي، وانتقلت الكتل دون اكتمالها، فإن هذه الفترة ستزداد أكثر.
وبالتالي، وعلى الرغم من أن الرياضيات تتفوق بالفعل على التوازن الاقتصادي، فإن الوقت اللازم لتحقيق الاستقرار النهائي للمعاملات في سلاسل ZK يفوق حاليًّا بكثير الوقت المطلوب في سلاسل OP. ولتقليص هذه الفترة الزمنية التي تتراوح بين 10 و20 دقيقة، لا بد من تطوير خوارزميات ZK وتحسين الدوائر (circuit optimization) والتسريع المادي (hardware acceleration). وإذا ما تمكّنت هذه الجهود من اختصار هذه الفترة إلى 10–20 ثانية (ربما بعد 5–10 سنوات)، فإن سلاسل ZK ستتفوق بلا شك على سلاسل OP في مجال الأمان.
2.2. البرمجيات الوسيطة (Middleware) وغيرها
في الواقع، يرى كثير من المراقبين أن هذا المجال يعد أكثر جاذبية من مجال التوسع، لأن استخدام ZK للتوسع هو مهمة «ثقيلة» للغاية، كما يظهر جليًّا من السنوات العديدة التي استغرقتها مشاريع Rollup المختلفة لإطلاق شبكاتها الرئيسية. أما البرمجيات الوسيطة فهي أخف وزنًا بكثير، وفي الوقت نفسه تُظهر خصائص ZK بكفاءة عالية.
وأكثر مجالات البرمجيات الوسيطة ازدهارًا هو مجال التوافق البيني (Interoperability)، حيث تُستخدم إثباتات ZK لإلغاء الحاجة إلى شهود طرف ثالث، ما يعزز أمان الجسور (bridges) بشكل كبير، بل ويتيح ربط بيئات كانت منعزلة أو يصعب ربطها سابقًا، مثل ربط طبقات L2 المختلفة مع بعضها البعض، أو ربط بيئة EVM بشبكة Cosmos عبر بروتوكول IBC. ومن أبرز الفرق العاملة في هذا المجال حاليًّا: Succinct Labs (والتي أطلقت مؤخرًا منتجها Telepathy، وهو جسر ZK أحادي الاتجاه لشبكة ETH)، وElectron Labs (التي كانت أول من قدّم مفهوم ZK-IBC)، وPolyhedra (التي تطور جسور ZK وهويات رقمية ZK، وهي أول مشروع أطلقته شركة ABCDE).
على الرغم من أن هذا المجال أخفُّ بكثيرٍ مقارنةً بـ Rollup، فإنه لا يزال مجالاً شديدَ التخصص ويتطلب جهداً كبيراً ووقتاً طويلاً. ومن غير المرجح إلى حدٍ كبيرٍ أن نشهد هذا العام جسوراً قائمةً بالكامل على تقنية ZK (ZK Bridges) تعمل في الاتجاهين وتوفِّر أداءً مرضياً ومستوى عالٍ من الأمان. أما التكامل البيني الكامل القائم على ZK، فلا يزال يتطلَّب منَّا التخطيط لفترة زمنية تتراوح بين سنتين وثلاث سنوات.
أما بالنسبة للمجالات الأخرى المرتبطة بتقنية ZK، فقد شهدت هذا العام نوعاً من الانفجار المفاجئ في عدد المشاريع. فالذين حضروا مؤتمر ETH Denver يعرفون ذلك جيداً؛ فبالفعل، هناك مشاريع تستخدم ZK في كل شيء تقريباً: خزائن آمنة على السلسلة، هويات رقمية لامركزية (DID)، وحدات تغذية بيانات خارجية (Oracles)، بل وحتى فرق تعمل على دمج الذكاء الاصطناعي والتعلُّم الآلي مع ZK. وبصراحة، فإن بعض هذه الاستخدامات منطقيةٌ فعلًا، لكن كثيراً منها يثير التساؤل: «أليس من الممكن تنفيذ هذا دون الحاجة إلى ZK؟»... باختصار، يشبه الأمر إلى حدٍ ما حالة ازدهار ICO عام ٢٠١٧، حيث كان الجميع يستخدمون البلوك تشين كـ«مطرقة» للبحث عن «مسامير» في كل مكان، فظهرت حينها مشاريع غريبة مثل خدمات النقل اللامركزية أو منصات Airbnb اللامركزية، والتي بدا معظمها اليوم غير منطقيٍّ تماماً. واليوم، استُبدلت البلوك تشين بتقنية ZK، ويبدو أننا نحاول تطبيق ZK على كل مجالٍ ممكنٍ لإعادة تصميمه...
ثالثاً: GameFi
قد يكون مجال GameFi أكثر المجالات ازدهاراً حالياً، بلا منازع. فلو قمنا بعدد المشاريع التي راقبناها أو ناقشناها خلال الأشهر الماضية، وقسمناها بدقة إلى فئات فرعية، لوجدنا أن GameFi يحتل المرتبة الأولى من حيث العدد.
والسبب في ذلك واضحٌ جداً: فمن جهة، صرَّح فيتاليك بوتيرين (Vitalik Buterin) منذ عدة سنوات بأن القطاعين المالي (Finance) والترفيهي (Gaming) سيكونان أول مجالين تُطبَّق عليهما تقنية البلوك تشين بنجاح.
ومن الجهة الأخرى، لم تحقِّق المحاولات الجارية في مجالات مثل DeFi والتخزين اللامركزي وSocialFi تقدُّماً ملموساً نحو التبني الجماعي (Mass Adoption). وعلى الرغم من انهيار أسطورة نماذج "X to Earn"، إلا أن مشاريع مثل Axie Infinity وStepN قد أظهرت لجميع المشاركين في المجال إمكانية «عبور الحدود» إلى الجمهور الأوسع، بل ويؤمن الكثيرون إيماناً راسخاً بأن تحقيق التبني الجماعي الواسع لن يتم إلا عبر «الألعاب».
وبالتالي، انصرف انتباه مطوري الألعاب من البيئة التقليدية (Web2) نحو هذا المجال بشكل متزايد، بل ويشمل ذلك حتى الفرق التقنية القادمة من شركات كبرى واستوديوهات ألعاب مرموقة. وفي الوقت نفسه، بدأ رواد البيئة اللامركزية (Web3) — مثل مطوري NFT ومشاريع DeFi — في التفكير في كيفية «إضافة طبقة GameFi» على منتجاتهم. ومثالٌ ناجحٌ نسبياً على ذلك هو لعبة Dookey Dash التي أطلقتها شركة Ape مؤخراً.
ومع ذلك، فإن مجال GameFi يمر حالياً بمرحلةٍ محرجةٍ نوعاً ما: فبعد انتهاء آلام نموذج "X to Earn" وحلقة الموت المفرغة (Death Spiral) المرتبطة بها، لا يزال الجميع يجهلون كيفية تحقيق التوازن المثالي بين الحوافز الاقتصادية وجاذبية اللعبة نفسها. فكل المشاركين يسيرون في الظلام، ويحاولون اكتشاف الطريق عبر لمس الأشياء بيدهم. والاتفاق الحالي الذي توصَّل إليه الجميع تقريباً هو أن نموذج "Free to Play" (اللعب المجاني) هو السائد الآن، بينما اختفى نموذج "Pay-to-Play" الذي يتطلب من المستخدم شراء رمز غير قابل للاستبدال (NFT) مسبقاً للبدء في اللعب — كما كان الحال في ألعاب مثل StepN وAxie Infinity.
وفي الوقت الراهن، نرى أن الجهود تتركز حول عدة نماذج مختلفة:
الفئة AAA —
إنها انتقالٌ من أحد الطُّرفين إلى الطرف المقابل: فإذا كانت Axie Infinity تركز على عنصر "الربح" (Earn)، فإن ألعاب الفئة AAA تركز على عنصر "اللعب" (Play)، وإن كانت درجة التركيز تتفاوت. فبعضها خفيف النسق، مثل الألعاب المصممة خصيصاً لجمهور Web3، والتي تستخدم الرموز غير القابلة للاستبدال (NFTs) وغيرها من العناصر لجذب اللاعبين من مجتمع Web3. وبعضها الآخر ثقيل النسق، مثل الألعاب الموجَّهة لجمهور Web2، والتي تتبع في إنتاجها وإدارتها وتسويقها النهج التقليدي لصناعة الألعاب المحمولة على الإنترنت، بحيث لا يتم سوى نقل نظام التداول إلى السلسلة، بل وقد تدمج المحفظة الرقمية داخل اللعبة بشكلٍ غير ملحوظٍ تماماً...
ألعاب الترفيه والتفاعل الاجتماعي —
لقد عشنا جميعاً في عالم Web2 عصور «سرقة الخضروات» و«المزارع» و«التنافس على أماكن الوقوف». فهل سيمر عالم Web3 أيضاً بمرحلة مشابهة في مجال GameFi؟ أي دمج بين التفاعل الاجتماعي، والترفيه الخفيف، وجرعة صغيرة من عنصر الربح؟ المستقبل غير مضمون، لكن هذا المسار يظل على الأقل اتجاهاً لم يُستكشف بشكلٍ كافٍ حتى الآن. وهناك نموذج جديد لـ "X to Earn": وأكثر ما رأيناه حتى الآن هو نموذج "Bet to Earn" (الرهان لتحقيق الربح)، الذي تمثِّله مشروع PSI، ويُعرف أيضاً باسم "Risk to Earn" (المخاطرة لتحقيق الربح). وببساطة، فهو يربط عملية "الربح" بمهارة اللاعب وكفاءته. تخيل لعبة Web3 على غرار لعبة "PUBG"، حيث يدفع ١٠٠ لاعب دولاراً واحداً كرسوم دخول، ويحصل الفائز الوحيد على الجائزة الكبرى البالغة ١٠٠ دولار. وبذلك، يمكن لهذا النموذج الاقتصادي أن يحل محل النموذج الهرمي (Ponzi) القائم سابقاً على النمو المتسارع في أعداد اللاعبين الجدد، والذي أدَّى لا محالة إلى حلقة الموت المفرغة، لأن هذا النموذج الجديد يتحول أساساً إلى نموذج تنافسي بين اللاعبين (PvP). ومع ذلك، فمثلما هو الحال مع ألعاب الفئة AAA، فإن هذا النموذج يتطلب مستوى عالياً جداً من جاذبية اللعبة للحفاظ على اللاعبين، نظراً لأن الحوافز الاقتصادية المقدمة للمستخدم العادي أصبحت ضئيلة للغاية.
نموذج "Free to Own" القائم على الرموز غير القابلة للاستبدال (NFT) —
ويُمثِّل هذا النموذج مشروع DigiDaigaku، كما أن لعبة Ape's Dookey Dash تحمل أيضاً بعض السمات المشابهة. والفكرة العامة هي جذب اللاعبين للحصول على الرموز غير القابلة للاستبدال (NFTs) مجاناً أو مقابل سعر رمزي، ثم العمل لاحقاً على إضافة قيمة مستمرة لهذه الرموز. وهذا النموذج يتطلَّب من الفريق أن يمتلك مهارات عالية جداً في خلق الغموض والتشويق والتسويق في المرحلة الأولية، كما يتطلَّب منه قدرات تطويرية وتنفيذية قوية في المراحل اللاحقة، مما يجعله مساراً ذا عتبة دخول مرتفعة للغاية. بالإضافة إلى ذلك، فإن العدد الأولي للرموز عادةً ما يقتصر على ١٠٠٠٠ وحدة، ما يشكل تحدياً كبيراً في توسيع قاعدة المستخدمين.
نموذج "Nintendo للألعاب" —
وهذا النموذج يُمثَّل طبيعياً بكل من TreasureDAO وGala، حيث تميل ألعاب Gala إلى أن تكون «أثقل» من حيث التعقيد، بينما تميل ألعاب TreasureDAO إلى أن تكون ذات طابع «ألعاب صغيرة» (Mini-games). وبعد ظهور لعبة Beacon كظاهرة ناجحة، من المؤكد أن ذلك سيجذب المزيد من الألعاب الصغيرة المماثلة للانضمام إلى بيئتها. ولطالما كانت الألعاب الصغيرة ناجحةً ومستدامةً في عالم Web2، لكن لا أحد يعلم إن كان بإمكان Web3 إعادة إنتاج هذا النجاح أم لا.
تأجيل (Gamification) تقنيات DeFi —
وفي هذا المجال، يُعتبر مشروع DefiKing المشروع الوحيد حتى الآن، وهو يتمتع برؤية طموحة للغاية، ونظامه معقَّدٌ جداً، مما يعيد إلى الأذهان انطباع «لعبة Xiyu Ji (Journey to the West) على السلسلة». ومع ذلك، وبعد الهالة الإعلامية الهائلة التي حققها في عام ٢٠٢١ (مع ارتفاع سعر الرمز بنسبة ١٠٠ ضعف)، لم يحقق المشروع تقدُّماً ملحوظاً منذ ذلك الحين، وظل سعر رمزه عند مستواه الأصلي دون أي حركة تُذكر. وبالتالي، يبدو أن مستقبل هذا النوع من مشاريع GameFi المعقدة والمترابطة ارتباطاً وثيقاً بـ DeFi ما زال مليئاً بالتحديات.
الألعاب الكاملة على السلسلة (Fully Onchain Games) —
وهذا ربما يكون أكثر أنواع GameFi إثارةً للحديث في مؤتمر ETH Denver. والسبب ببساطة هو أن باقي الفئات الأخرى تحمل جميعها بصمات واضحة من عالم Web2.5، بينما تُعد الألعاب الكاملة على السلسلة فقط هي الألعاب الحقيقية الخاصة بعالم Web3، والتي تمتلك خصائص البلوك تشين بالكامل. بل إن بعضها لا يمكن حتى اعتباره «ألعاباً» بالمعنى التقليدي، بل يجب تسميتها «عوالم مستقلة على السلسلة» (Onchain Autonomous Worlds). وقد تكون هذه الفئة ثالث نوعٍ حقيقيٍّ «أصيلٍ على البلوك تشين»، بعد DeFi وNFT. ومع ذلك، فكما ظهرت تقنيتا DeFi (عبر مشروع MakerDAO) وNFT (عبر مشروع CryptoKitties) في عام ٢٠١٧، ثم حققت كل منهما ازدهاراً كبيراً في أعوام ٢٠٢٠ و٢٠٢١ على التوالي، فإن الألعاب الكاملة على السلسلة لا تزال في مرحلة استكشافية مبكرة للغاية، وقد تحتاج أيضاً إلى فترة تتراوح بين ٣ و٤ سنوات قبل أن تصل إلى لحظة ازدهارها.
وفي الوقت الراهن، لا يمكن الجزم بأيٍّ من هذه الاتجاهات السبعة — أو بأي مجموعة منها — سينجح في الوصول إلى النهاية. علاوةً على ذلك، يواجه تطور GameFi تناقضاً جوهرياً: فعلى الرغم من أن الألعاب تعد أسهل وسيلة لجذب المستخدمين من خارج المجتمع إلى داخله، فإن جوهر الألعاب يكمن في خلق عالمٍ منفصلٍ عن الواقع، يتيح للمستخدم الهروب المؤقت من ضغوط الحياة العملية والانغماس في «ملاذ» ترفيهي نقي. أما ربط الألعاب ببنية Web3 أو البلوك تشين، فيؤدي لا محالة إلى إعادة ربطها بالعالم الحقيقي عبر أشكالٍ ماليةٍ معينة، مما يطرح سؤالاً عميقاً: هل يؤدي هذا الربط إلى تقويض الوظيفة الأساسية للعبة كـ«ملاذ نقي»؟
الخلاصة:
إن إعادة التفكير في هذه المجالات الثلاثة الأكثر ازدهاراً اليوم لا تعني إطلاقاً أننا لا نؤمن بها. بل على العكس، فإن ABCDE تؤمن إيماناً راسخاً بهذه المجالات الثلاثة على المدى الطويل، وقد بدأت بالفعل أو تخطط للاستثمار فيها. فغالباً ما نبالغ في تقدير القيمة قصيرة المدى لبعض التقنيات، وفي الوقت نفسه نقلِّل من تقدير قيمتها طويلة المدى. ومن الممكن أن تفشل هذه المجالات في تقديم عوائد استثمارية تتماشى مع توقعات المؤسسات الاستثمارية أو الأسواق الأولية والثانوية على المدى القصير. أما بالنسبة لنا، كشركة رأس مال مخاطر (VC) ذات أفق استثماري طويل المدى مدته خمس سنوات، فإن الزمن سيكون أفضل صديقٍ لنا.