الانشقاق والاستقلال: إعادة النظر في حجة ليسك

قبل ثلاث سنوات، كتبنا مقالًا عن Appchain، أثاره إعلان dYdX عن نيتها نقل بروتوكول المشتقات اللامركزية من StarkEx L2 إلى سلسلة Cosmos، وإطلاق الإصدار 4 كسلسلة بلوكتشين مستقلة تعتمد على Cosmos SDK وتوافق Tendermint. في عام 2022، ربما كانت Appchain خيارًا تقنيًا هامشيًا نسبيًا. مع اقترابنا من عام 2025، ومع إطلاق المزيد من Appchain، وخاصة Unichain وHyperEVM، يتغير المشهد التنافسي للسوق بهدوء، ويتشكل اتجاه يتمحور حول Appchain. ستستكشف هذه المقالة أطروحتنا حول Appchain، بالاعتماد على هذا الأساس. ظهرت فكرة Unichain في وقت مبكر جدًا. في عام 2022، نشر مؤسس Nascent، دان إليتزر، كتاب "حتمية UNIchain"، الذي سلط الضوء على حجم Uniswap وعلامتها التجارية وهيكل السيولة والطلب على الأداء وجذب القيمة، مشيرًا إلى حتمية إطلاق Unichain. استمرت المناقشات حول Unichain منذ ذلك الحين. تم إطلاق Unichain رسميًا في فبراير، وقد قام أكثر من 100 تطبيق ومزود للبنية التحتية بالبناء عليه بالفعل. تبلغ TVL الحالية حوالي 1 مليار دولار، مما يضعها بين أفضل خمس منصات L2. سيتم إصدار Flashblocks بأوقات كتلة 200 مللي ثانية وشبكة التحقق من Unichain في المستقبل. ▲ المصدر: DeFiLlama بصفتها perp، كان لدى Hyperliquid حاجة واضحة إلى Appchain والتخصيص العميق منذ اليوم الأول. بالإضافة إلى منتجها الأساسي، أطلقت Hyperliquid أيضًا HyperEVM، والذي، مثل HyperCore، مؤمن بواسطة آلية إجماع HyperBFT. بعبارة أخرى، بالإضافة إلى منتج perp القوي، تستكشف Hyperliquid أيضًا إمكانية بناء نظام بيئي. حاليًا، يحتوي نظام HyperEVM البيئي على أكثر من 2 مليار دولار في TVL، وبدأت مشاريع النظام البيئي في الظهور. يوضح تطوير Unichain و HyperEVM بوضوح نقطتين رئيسيتين: بدأ المشهد التنافسي L1/L2 في التباعد. يتجاوز إجمالي القيمة التفاضلية لأنظمة Unichain وHyperEVM البيئية 3 مليارات دولار. كانت هذه الأصول تُحفظ سابقًا على منصات L1/L2 للأغراض العامة مثل Ethereum وArbitrum. أدى التطوير المستقل للتطبيقات الرائدة بشكل مباشر إلى فقدان مصادر القيمة الأساسية لهذه المنصات، بما في ذلك القيمة التفاضلية وحجم المعاملات ورسوم المعاملات وMEV. في الماضي، تمتعت L1/L2 وتطبيقات مثل Uniswap وHyperliquid بعلاقة تكافلية: حيث جلبت التطبيقات النشاط والمستخدمين إلى المنصات، بينما وفرت المنصات الأمان والبنية التحتية للتطبيقات. الآن، أصبحت Unichain وHyperEVM طبقات منصة بحد ذاتها، وتتنافس بشكل مباشر مع منصات L1/L2 الأخرى. لا تتنافسان فقط على المستخدمين والسيولة، ولكن أيضًا على المطورين، مما يدعو مشاريع أخرى للبناء على سلاسلهما. وقد أدى هذا إلى تغيير كبير في المشهد التنافسي. يختلف مسار توسع Unichain وHyperEVM تمامًا عن مسار منصات L1/L2 الحالية، والتي غالبًا ما تبني البنية التحتية أولاً ثم تجذب المطورين بالحوافز. من ناحية أخرى، تتبنى Unichain وHyperEVM نموذج "المنتج أولاً"، حيث تُنشئان أولاً منتجًا أساسيًا أثبت جدارته في السوق ويتمتع بقاعدة مستخدمين واسعة وعلامة تجارية معروفة، ثم تبنيان منظومة متكاملة وتأثيرات شبكية حول هذا المنتج. يُعد هذا النهج أكثر كفاءة واستدامة. فهما لا يحتاجان إلى "شراء" منظومة متكاملة من خلال حوافز عالية التكلفة للمطورين، بل إلى "جذبها" من خلال تأثيرات الشبكة والمزايا التكنولوجية لمنتجهما الأساسي. يختار المطورون البناء على HyperEVM نظرًا لمستخدمي التداول عالي التردد وسيناريوهات الطلب الحقيقي هناك، وليس بسبب وعود تحفيزية غامضة. من الواضح أن هذا نموذج نمو أكثر استدامة وعضوية. ما الذي تغير في السنوات الثلاث الماضية؟ ▲ المصدر: zeeve. أولًا، نضج حزمة التكنولوجيا وتطور مزودي الخدمات الخارجيين. قبل ثلاث سنوات، تطلب بناء Appchain من الفرق إتقان حزمة blockchain بالكامل. مع ذلك، مع تطور خدمات RaaS ونضجها، مثل OP Stack وArbitrum Orbit وAltLayer، أصبح بإمكان المطورين دمج وحدات متنوعة عند الطلب، بدءًا من التنفيذ وتوافر البيانات وصولًا إلى التسوية والتشغيل البيني، تمامًا كما هو الحال في استخدام الخدمات السحابية. هذا يُقلل بشكل كبير من تعقيد الهندسة والاستثمار الأولي اللازم لبناء Appchain. يوفر التحول في نماذج التشغيل من البنية التحتية ذاتية البناء إلى الخدمات المشتراة مرونةً وإمكانيةً للابتكار على مستوى التطبيق. ثانيًا، يُعدّ الوعي بالعلامة التجارية والمستخدم أمرًا بالغ الأهمية. نعلم جميعًا أن الاهتمام مورد نادر. غالبًا ما يكون المستخدمون مخلصين للعلامة التجارية للتطبيق، وليس لتقنيته الأساسية: فهم يستخدمون Uniswap بسبب تجربة المنتج، وليس لأنه يعمل على Ethereum. مع الانتشار الواسع للمحافظ متعددة السلاسل والتحسينات الإضافية في تجربة المستخدم، أصبح المستخدمون يتجاهلون تقريبًا الاختلافات بين السلاسل - غالبًا ما تكون نقاط اتصالهم الأولية هي المحافظ والتطبيقات. عندما تبني التطبيقات سلاسلها الخاصة، تُدمج أصول المستخدمين وهوياتهم وعادات استخدامهم في نظام التطبيق البيئي، مما يخلق تأثيرًا شبكيًا قويًا. ▲ المصدر: Token Terminal والأهم من ذلك كله، أن سعي التطبيقات إلى السيادة الاقتصادية أصبح أكثر بروزًا تدريجيًا. في بنية L1/L2 التقليدية، يمكننا أن نرى أن تدفق القيمة يُظهر اتجاهًا واضحًا "من أعلى إلى أسفل":

1. طبقة التطبيق تُنشئ القيمة (معاملات Uniswap، إقراض Aave)

2. يدفع المستخدمون رسومًا لاستخدام التطبيق (رسوم التطبيق + رسوم الغاز)، ويذهب جزء من هذه الرسوم إلى البروتوكول، ويذهب جزء آخر إلى LP أو المشاركين الآخرين

3. 100% من رسوم الغاز تتدفق إلى مُحقق L1 أو مُفرز L2

4. يتم تقسيم MEV بواسطة الباحثين والمُنشئين والمُحققين في مناطق مختلفة النسب

5. في النهاية، تستحوذ رموز L1 على قيمة تتجاوز رسوم التطبيق من خلال التخزين. في هذه السلسلة، تستحوذ طبقة التطبيق، التي تُنتج أكبر قيمة، على أقل قيمة. وفقًا لـ Token Terminal، من إجمالي 6.4 مليار دولار أمريكي من القيمة المُولّدة من Uniswap (بما في ذلك عوائد LP ورسوم الغاز، إلخ)، حصل البروتوكول/المطورون ومستثمرو الأسهم وحاملو الرموز على أقل من 1%. منذ إطلاقه، حقق Uniswap 2.7 مليار دولار أمريكي من إيرادات الغاز لإيثريوم، وهو ما يُمثل حوالي 20% من رسوم تسوية إيثريوم. وماذا يحدث إذا كانت للتطبيقات سلاسلها الخاصة؟ يُمكنها تحصيل رسوم الغاز لأنفسها، باستخدام رموزها الخاصة كرموز غاز؛ أو استيعاب MEV، وتقليل MEV الضارة من خلال التحكم في المُفرز وإعادة MEV السليمة للمستخدمين؛ أو تخصيص نماذج الرسوم لتحقيق هياكل رسوم أكثر تعقيدًا، وما إلى ذلك. وبالتالي، يُصبح السعي لاستيعاب القيمة خيارًا مثاليًا للتطبيقات. فعندما تكون قوة تفاوض التطبيق قوية بما يكفي، سيتطلب بطبيعة الحال المزيد من الفوائد الاقتصادية. لذلك، تعتمد التطبيقات عالية الجودة بشكل ضعيف على السلسلة الأساسية، بينما تعتمد السلسلة الأساسية بشكل كبير على التطبيقات عالية الجودة. ملخص ▲ المصدر: Dune@reallario يُقارن الرسم البياني أعلاه تقريبيًا إيرادات البروتوكولات (باللون الأحمر) والتطبيقات (باللون الأخضر) منذ عام 2020. يمكننا أن نرى بوضوح أن القيمة التي تجنيها التطبيقات في تزايد تدريجي، حيث وصلت إلى حوالي 80% هذا العام. قد يُلغي هذا إلى حد ما نظرية جويل مونيغرو الشهيرة "البروتوكولات السمينة والتطبيقات الضعيفة". نشهد تحولًا جذريًا من نظرية "البروتوكول السمين" إلى نظرية "التطبيق السمين". تاريخيًا، ركز منطق تسعير مشاريع العملات المشفرة بشكل أساسي على الإنجازات التكنولوجية وتطوير البنية التحتية الأساسية. في المستقبل، سيتحول التسعير تدريجيًا إلى نهج أكثر تركيزًا يعتمد على العلامة التجارية وحركة المرور وجني القيمة. إذا تمكنت التطبيقات من بناء سلاسلها الخاصة بسهولة بالاعتماد على الخدمات المعيارية، فسيواجه نموذج "تحصيل الإيجار" التقليدي لشركة L1 تحديًا. وكما قلل صعود البرمجيات كخدمة (SaaS) من القدرة التفاوضية لشركات البرمجيات العملاقة التقليدية، فإن نضج البنية التحتية المعيارية يُضعف أيضًا احتكار L1. في المستقبل، ستتجاوز القيمة السوقية للتطبيقات الرائدة بلا شك قيمة معظم شركات L1. سيتحول منطق تقييم L1 من "الاستحواذ على القيمة الإجمالية للنظام البيئي" إلى "مُزود خدمات بنية تحتية" مستقر وآمن ولامركزي. سيكون تقييمها أقرب إلى تقييم السلع العامة التي تُولّد تدفقًا نقديًا مستقرًا، بدلًا من تقييم الشركات العملاقة "الاحتكارية" التي تستحوذ على غالبية قيمة النظام البيئي. ستتقلص فقاعة تقييمها إلى حد ما. كما تحتاج L1 إلى إعادة النظر في مكانتها. فيما يتعلق بـ Appchain، نرى أنه بفضل علامتها التجارية، وتفاعل المستخدمين معها، وقدراتها عالية التخصيص على السلسلة، يُمكن لـ Appchain أن تُراكم قيمة المستخدم على المدى الطويل بشكل أفضل. في عصر "التطبيقات الضخمة"، لا تقتصر قدرة هذه التطبيقات على الاستفادة من القيمة المباشرة التي تُنشئها فحسب، بل تُمكّنها أيضًا من بناء سلاسل كتل حولها، مما يُعزز هذه القيمة ويُعزز قيمة البنية التحتية - فهي منتجات ومنصات في آنٍ واحد، تخدم المستخدمين النهائيين والمطورين الآخرين. بالإضافة إلى السيادة الاقتصادية، ستسعى التطبيقات الرائدة أيضًا إلى الحصول على حقوق سيادية أخرى: الحق في اتخاذ قرار بشأن ترقيات البروتوكولات، وترتيب المعاملات ومقاومة الرقابة، وملكية بيانات المستخدم. بالطبع، تُركز هذه المقالة بشكل أساسي على التطبيقات الرائدة مثل Uniswap وHyperliquid، اللتين أطلقتا Appchain بالفعل. لا تزال Appchain في مراحلها الأولى من التطوير (لا تزال Uniswap تمتلك 71.4% من إجمالي القيمة الإجمالية للأصول على Ethereum). بروتوكولات مثل Aave، التي تتضمن أصولًا مُغلفة وضمانات وتعتمد بشكل كبير على قابلية التركيب على سلسلة واحدة، أقل ملاءمةً لـ Appchain. نسبيًا، تُعتبر Perps، التي تقتصر متطلباتها الخارجية على Oracles، أكثر ملاءمةً لـ Appchain. علاوة على ذلك، لا يُعد Appchain الخيار الأمثل للتطبيقات متوسطة المستوى، إذ يتطلب تحليلًا لكل حالة على حدة. لن أخوض في التفاصيل هنا.