وعد بلوكتشين دائمًا بجعل التمويل والتنسيق أكثر توفرًا. ومع ذلك، أي شخص حاول مبادلة رمزية بسيطة بين سلاسل يعرف الواقع: تفاعلات محفظة متعددة، رموز الغاز المحددة للسلسلة، حسابات الانزلاق، والتهديد المستمر بفشل المعاملات التي تستنزف أموالك. الفجوة بين إمكانات بلوكتشين وسهولة استخدامها تظل واسعة بشكل عنيد.
يظهر التصميم المعتمد على النية كبنية نموذجية ناشئة يمكن أن تعيد تشكيل كيفية تفاعل المستخدمين مع ويب3 بشكل أساسي. بدلاً من إجبار المستخدمين على تحديد كل خطوة في المعاملة - أي سلسلة، أي بروتوكول، أي تسلسل دقيق لدعوات العقود الذكية - تتيح البنية المعتمدة على النية للمستخدمين ببساطة بالإعلان عما يريدون تحقيقه. تتولى البنية التحتية بقية العمل.
يتماشى هذا التحول مع نمط أوسع في تاريخ الحوسبة. المستخدمون الأوائل للكمبيوتر كانوا يبرمجون بلغة التجميع، محددين تعليمات جهاز دقيقة. المستخدمون المعاصرون ينقرون، أو يكتبون، أو يتحدثون عن نتائجهم المرجوة. يعد التصميم المعتمد على النية بتحول مماثل لبلوكتشين: من البرمجة الأمرية ("قم بذلك، ثم هذا، ثم هذا") إلى التعبير التصريحي ("اجعل هذا يحدث").
النموذج المعتمد على المعاملة الذي هيمن على ويب3 منذ إطلاق إيثريوم يتطلب من المستخدمين فهم التفاصيل التقنية التي ينبغي تجريدها بعيدًا. إذا كنت تريد مبادلة الرموز عبر السلاسل، يجب أن تجسر الأصول، وتضمن وجود رمز الغاز الصحيح، وتنتقل إلى تبادل لامركزي مناسب، وتضبط معايير الانزلاق، وتأمل ألاّ يقوم أي روبوت MEV بتقديم معاملتك للمقدمة. كل خطوة تقدم احتكاكًا واحتمالًا للفشل.
المشاريع مثل Anoma، SUAVE من فلاش بوتز، وCoW Protocol يقودون نهجًا مختلفًا. هذه البنى المعتمدة على النية تقدم شبكات حلاّل تتنافس لتحقيق أهداف المستخدمين بشكل مثالي. المستخدمون يعبرون عن النتائج المرجوة؛ يقوم الحلاّلون بإدارة تعقيد التنفيذ. النتيجة يمكن أن تكون ويب3 يشعر بأنه أقل برمجة وأكثر كـ "الحصول على الأشياء منجزه".
يحمل هذا التحول آثارًا عميقة للمستخدمين اليوميين الذين يشعرون بالإحباط من التعقيد، والمطورين الذين يغرقون في عمل دمج السلاسل، وقدرة النظام البيئي للعملات المشفرة على التوسع إلى ما وراء القيود الحالية. لكن التصميم المعتمد على النية يقدم أيضًا مخاطر جديدة تتعلق بالمركزية، والخصوصية، ومسؤولية الحلاّل. فهم كل من الوعود والمخاطر مهم الآن، حيث يبدأ هذا التصميم في الانتقال من النظريات إلى الإنتاج.
ما هو التصميم المعتمد على النية؟
في جوهره، تمثّل النية الحالة النهائية المرجوة للمستخدم بدلاً من مسار التنفيذ المحدد. بللغة تقنية، النية هي رسالة موقعة تعبّر عن النتيجة التي يريد المستخدم تحقيقها، مع وضع القيود التي تحدد الطرق المقبولة للوصول إلى تلك النتيجة.
يوضح التمييز بين التفاعلات المعتمدة على المعاملة والمعتمدة على النية التحول النموذجي. في الأنظمة المعتمدة على المعاملة مثل إيثريوم، يصنع المستخدمون تعليمات محددة: "تنفيذ الوظيفة X بالعقد Y مع المعلمات Z." تعالج بلوكتشين هذه التعليمات بشكل حتمي. يتحمل المستخدمون المسؤولية عن فهم واجهات العقود، وإدارة الأنصبة، وحمل رموز الغاز، واستشعار التغيرات في الحالة.
تقلب الأنظمة المعتمدة على النية هذا النموذج. المستخدمون يصرحون: "أريد أن أحصل على الأصل B، بدءًا من الأصل A، مع القيود C." قد تحدد التصريح مثلا، حد التقبل الأقصى، نوافذ زمنية، أو تفضيلات الخصوصية، لكنها لا تملي مسار التنفيذ. يتلقى الحلاّلون الطرف الثالث هذه النوايا ويتنافسون لاكتشاف استراتيجيات تحقيق مثالية، مستفيدين من أي تجمع سيولة متاح ضمن السلسلة، جسور ما بين السلاسل، مؤسسات سوق خارج السلسلة، أو مقابلات من نظير إلى نظير."
**Content (Translated):**
دور بناء الكتل من السلاسل الحالية. بدلاً من أن يُقدم المستخدمون معاملات محددة إلى مجمعات السلسلة الفردية، يقدمون تفضيلات - نوايا - إلى المزاد العالمي لـ SUAVE. يمكن أن تتراوح هذه التفضيلات من بسيطة ("تبادل A مقابل B") إلى معقدة ("إعادة توازن محفظتي عبر السلاسل مع تعظيم العائد").
تقدم البنية عدة مكونات جديدة. SUAVE تستخدم الحوسبة السرية عبر Intel SGX للسماح بالحساب على تدفق أوامر المستخدم الحساسة دون كشف المعلومات للمستغلين المحتملين. تعالج هذه المقاربة توترًا أساسيًا: يحتاج الحلول إلى معلومات لتوفير التنفيذ الأمثل، لكن الإفراط في المعلومات يمكن أن يمكّن من استخراج MEV.
بناة الكتل الذين يعملون على سلسلة واحدة فقط يجدون أنفسهم في وضع غير مواتٍ بسبب MEV عبر المجالات. SUAVE تُمكّن البناة من التقاط القيمة عبر سلاسل متعددة في نفس الوقت. يزيد المدققون من الإيرادات على المساحة في الكتلة. يتعامل المستخدمون بشكل خاص بتحسين تنفيذ ونفقات ضئيلة. يهدف التصميم إلى منع المركزية الناتجة عن استخراج MEV عبر السلسلة.
تشمل خطة SUAVE مراحل تصاعدية للامركزية. تستخدم الإصدارات المبكرة بيئات تنفيذ موثوقة مع افتراضات حول Flashbots، بينما تتحرك الإصدارات اللاحقة نحو تشغيل لامركزي تمامًا. المشروع يدعو صراحة المنافسين للمشاركة، معترفًا بأن توزيع بنية MEV يخدم صحة النظام البيئي على المدى الطويل بشكل أفضل بدلاً من تحكم أي كيان واحد فيه.
في حين أن SUAVE يركز حاليًا أكثر على نوايا الباحثين من نوايا المستخدمين العامة، فإن البنية التحتية توفر أساسًا للتطبيقات القائمة على النوايا الأوسع. ومع نضوج النظام، قد يتوسع للتعامل مع المزيد من أنواع النوايا المتنوعة بخلاف تحسين تدفق الأوامر.
### CoW Protocol: تداول مبني على النوايا العملي
CoW Protocol رائد في تداول المبني على النوايا في 2021، مما يجعله أحد أقدم التطبيقات العملية لهذه المفاهيم. يشير اسم البروتوكول إلى "Coincidence of Wants" – المفهوم الاقتصادي حيث يرغب طرفان في سلع بعضهما البعض ويمكنهما التبادل مباشرة دون وسطاء.
يعمل CoW Protocol عن طريق جمع التداولات بمرور الوقت في دفعات. يوقع المستخدمون أوامر خارج السلسلة تعبر عن نوايا التداول الخاصة بهم: الأصول المطلوبة، النطاقات السعري المقبولة، حدود الزمن. تتدفق هذه النوايا إلى شبكة من الحلوليين الذين يتنافسون في مزادات لتقديم أفضل تنفيذ للدفعة بأكملها.
يمكن للحلوليين تنفيذ النوايا من خلال طرق متعددة:
- **المطابقة المباشرة**: عندما يرغب مستخدمان في تداولات متعارضة، يقوم الحل بوفق الأقران ببعضهم البعض دون استخدام سيولة على السلسلة
- **تداول الحلقات**: تداولات دائرية متعددة الأطراف تحسن عبر عدة نوايا متزامنة
- **تجميع DEX**: التوجيه عبر AMMs الحالية، الجمع بين مصادر السيولة
- **صانعو السوق الخاصون**: الاستفادة من السيولة خارج السلسلة عند تحقيق الربح
يوفر نظام مزاد الدفعات حماية طبيعية من MEV. جميع التداولات داخل الدفعة تُنفذ بأسعار تصفية موحدة، مما يلغي ديناميكيات تقديم الخدمة لمن يأتي أولا ويحمي من التجاوز الأمامي. يتحمل الحلوليون تكاليف الغاز، مما يعني أن المستخدمين لا يدفعون شيئًا إذا فشلت التداولات في تلبية المعايير المحددة.
تمكن CoW Swap من معالجة أكثر من 30 مليار دولار من الحجم، توفير أكثر من 82 مليون دولار للمستخدمين من الفائض من خلال التنفيذ الأمثل، وزاد الاستحواذ على حصة تصل إلى 63٪ في السوق بين مجمعي الـ DEX القائمين على النوايا. يوضح البروتوكول أن هياكل النوايا المبنية على النوايا يمكن أن تعمل على نطاق واسع اليوم، وليس فقط في الأنظمة المستقبلية.
### مشاريع بارزة أخرى
تساهم عدة مشاريع أخرى في نظام النوايا الموجه:
- **Essential**: بناء بروتوكولات تعتمد على النوايا فقط من الألف إلى الياء، حيث لا توجد معاملات قدمها المستخدم - فقط حلول نوايا مجموعات
- **UniswapX**: توجيه النوايا القائم على Uniswap باستخدام مزادات هولندية وشبكات ملء، مع قدرات عبر السلسلة تنطلق في الفترة 2024-2025
- **Across Protocol**: اقتراح معايير للتوافق بين النوايا عبر السلسلة بجانب UniswapX
- **1inch Fusion**: توجيه التبادل القائم على النوايا من مجمع DEX المعروف
- **DappOS**: بنية تحتية للتفاعل القائم على النوايا في التطبيقات، تشمل أصول النوايا وتنفيذ النوايا
تشارك هذه المشاريع أنماط تقنية مشتركة: بث النوايا خارج السلسلة، شبكات الحلولين التنافسية، التحقق من التسوية على السلسلة، والتنسيق عبر السلاسل. توحي تنوع الأساليب بأن الفضاء لا يزال يستكشف الخيارات البنائية الأكثر فعالية.
تطبيقات مرة واحدة. تتولى البنية التحتية الأساسية تفاصيل السلسلة المحددة. يصبح بإمكان التطبيقات أن تكون محمولة حقًا، وتتبنى سيولة المستخدمين بدلاً من أن تكون مقيدة بسلاسل محددة.
يمكن لطبقة النوايا تجميع السيولة عبر جميع المجالات المتصلة، مما يحل مشكلة الدجاجة والبيضة حيث تكافح السلاسل الجديدة لتحقيق الاستخدام بدون سيولة. إذا شارك المستخدمون والموفرون في شبكة نوايا موحدة، تصبح شظايا السيولة أقل أهمية. تتدفق الطلبات إلى حيث يمكن تلبية الطلبات بشكل أمثل.
كفاءة رأس المال والابتكار
تمكّن النماذج المبنية على النوايا أشكالاً جديدة من كفاءة رأس المال. عندما يمكن للموفرين استخدام مخزونهم الخاص لتسهيل الصفقات، لم يعد رأس المال بحاجة إلى الاستقرار في مجمعات السيولة. يمكن لصناع السوق المحترفين توفير السيولة بشكل ديناميكي، ولا يتم نشر رأس المال إلا عندما تنشأ فرص مربحة.
يفتح النظام تطبيقات لم تكن موجودة في نماذج المعاملات التقليدية. يصبح التنسيق المعقد متعدد الأطراف ممكناً عند التعبير عن النتائج بدلاً من تنسيق تسلسلات التنفيذ الدقيقة. تصبح التطبيقات التي كانت غير عملية بسبب تكاليف الغاز العالية أو تعقيد التنسيق قابلة للتطبيق عندما تتولى شبكات النوايا التفاصيل التنفيذية بكفاءة.
كيف تبدو عملية الانتقال: من العقود الذكية إلى طبقات النوايا
فهم مكان التصميم المبني على النوايا في تطور البلوك تشين يوفر منظوراً حول أهميته ومساره المحتمل.
تطور الهياكل المعمارية للويب
كان Web1 للقراءة فقط: صفحات ثابتة يتم تخديمها من خوادم مركزية. كان المستخدمون يستهلكون المحتوى ولكن نادراً ما يشاركون في إنشائه. عكست الهيكلية هذه السلبية – صفحات HTML بسيطة ذات تفاعلية منخفضة.
أدخل Web2 محتوى المستخدم والتطبيقات التفاعلية لكنه حافظ على السيطرة المركزية. كانت المنصات مثل Facebook وGoogle تتيح المشاركة بينما تستحوذ على البيانات والقيمة مركزياً. كان المستخدمون يتنازلون عن التحكم مقابل الراحة، مما يخلق نموذج رأس المال الرقابي الذي يسعى Web3 إلى تعطيله.
أدخل الجيل الأول من Web3، الممثل بـ Bitcoin، تسويات قابلة للبرمجة. يمكن للمستخدمين برمجة الأموال باستخدام منطق شرطي بسيط، لكن لغة البرمجة ظلت محدودة عمدًا. أثبتت Bitcoin أن سلاسل البلوك يمكن أن تعمل لكنها قدمت تعبيراً محدوداً.
ابتكرت Ethereum الجيل الثاني من الهيكلية مع تسويات قابلة للبرمجة بالكامل. مكنت EVM من الحوسبة العشوائية، مما أطلق انفجارًا في التطبيقات: الرموز، DAOs، بروتوكولات DeFi، أسواق NFT. لكن هذه القابلية للبرمجة جاءت مع التعقيد. أصبح المستخدمون مطورين بحكم الواقع، يؤلفون المعاملات من خلال المكالمات العقود الذكية.
أصبحت محددات العمارة من الجيل الثاني واضحة مع نمو التطبيقات تعقيداً. تتطلب التطبيقات المعقدة مثل أسواق NFT وDEXes القائمة على دفتر الطلبات مكونات مركزية لاكتشاف الطرف المقابل والتحسين – وظائف لا يوفرها البلوك تشين نفسه بكفاءة. تعمل هذه المعماريات من الجيل 2.5 لكن تتنازل عن اللامركزية.
تهدف العمارة القائمة على النوايا من الجيل الثالث إلى توفير لامركزية كاملة لأنواع التطبيقات العشوائية. من خلال جعل النوايا البريمة الأساسية، تقدم هذه الأنظمة إكمال للنوايا بشكل عام، واكتشاف الطرف المقابل، وحل وتسوية – كل ما يحتاجه التطبيقات دون إجبارها على تصميمات مركزية على البلوك تشين.
ما الذي يتغير للمطورين
يحول التحول إلى العمارة القائمة على النوايا تجربة المطور بشكل جذري. يحتاج مطورو البلوك تشين الحاليون إلى:
- إتقان لغات البرمجة المتعددة (Solidity، Rust، Move)
- فهم التفاصيل الخاصة بكل سلسلة ونماذج الغاز
- بناء جسور مخصصة ورسائل عبر السلسلة
- تنفيذ حماية MEV الإرهاب
- التعامل مع الحالات الخاصة بإعادة تنظيم السلسلة
- تحسين الحسابات المكلفة على السلسلة
يختصر التطوير المبني على النوايا العديد من هذه المخاوف. يعرف المطورون لغات النوايا – مفردات الرغبات التي يفهمها تطبيقاتهم. تتولى البنية التحتية الأساسية تفاصيل التنفيذ. بدلاً من كتابة عمليات تنفيذ مستقلة لكل سلسلة، تصبح التطبيقات قابلة للنقل بشكل افتراضي.
يشبه هذا التحولات السابقة في تطوير البرمجيات. قد كان المطورون يديرون توزيع الذاكرة يدوياً؛ الآن يتولى مجمع القمامة ذلك. كنا المطورون يكتبون التعليمات البرمجية الخاصة بالمنصة؛ الآن تقدم الأطر العامة تجريدات متعددة المنصات. يجلب التصميم المبني على النوايا نفس التجريد لتطوير البلوك تشين.
لن يحدث التحول بين عشية وضحاها. تمثل العقود الذكية الحالية استثماراً كبيراً وتأثيرات شبكية. يجب أن تتواجد مسارات الهجرة للسماح للتطبيقات الحالية بتضمين التفاعلات المبنية على النوايا تدريجياً. من المرجح أن تسود الهج’éơn(options)ингов'ihižayyatفطاتهج‘übiogejdikがжаça.ائر مركبة خلال فترة الانتقال، حيث تلتف طبقات النوايا حول نظام المعاملات التقليدية.
ما الذي يتغير للبنية التحتية
تحول طبقة البنية التحتية من سلاسل تتنافس على التطبيقات إلى شبكات موفرين تتنافس على تدفق الطلبات. [تصبح السلاسل طبقات تسوية بدلاً من بيئات التنفيذ](https://writings.flashbots.net/the-بيئة العمل التقليدية للتداول تقدم نتائج متوقعة؛ في حين تضيف أنظمة النوايا عدم اليقين حول كيفية وقوع التنفيذ من عدمه.
تحديات التوحيد تثقل هذه العقبات التقنية. بدون صيغ تعبير للنوايا شائعة، لا يمكن للنظم المختلفة أن تتعايش. لكن التوحيد المبكر قد يقيد بتصميمات غير مثالية. يجب أن يوازن النظام البيئي بين التحرك بسرعة وبناء أسس قوية.
الإرث والانتقال للعقود الذكية
يحتوي النظام البيئي الحالي لشبكة Web3 على مليارات من القيم المقيدة عبر العقود الذكية التي بُنيت على نماذج مبنية على المعاملات. لا يمكن إعادة كتابة هذه العقود في ليلة وضحاها. يجب أن توجد مسارات انتقالية لاعتماد تدريجي لتصميمات تركز على النوايا.
العمارة الهجينة حيث تغلف طبقات النوايا العقود القائمة تقدم حلاً، ولكنها تضيف تعقيدًا. يجب على المطورين تعلم نماذج جديدة مع الحفاظ على الأنظمة القديمة. يواجه المستخدمون ارتباكًا بشأن أي التطبيقات تدعم النماذج التفاعلية المختلفة. تخلق فترة الانتقال تجزئة بدلاً من الوحدة.
تعتبر تعليم المطورين تحديًا آخر. التحول الذهني من برمجة المعاملات الحتمية إلى التعبير عن النوايا التصريحية كبير. يمتلك المطورون الحاليون لسلسلة الكتل خبرة عميقة في لغات وأنماط محددة؛ يستغرق التدريب وقتًا. بدأت الجامعات ومعسكرات التدريب فقط في تعليم Solidity؛ يضيف تطوير النوايا تحديًا إضافيًا لفهمها.
المساءلة واللجوء
توفر الأنظمة المبنية على المعاملات مساءلة واضحة. إذا فشلت معاملتك أو تصرفت بشكل غير متوقع، يمكنك فحص التسلسل الدقيق للعمليات. تجرد أنظمة النوايا التنفيذ، مما يجعل من الصعب فهم الخطأ الذي حدث عندما لا تتوافق النتائج مع التوقعات.
من سيكون المسؤول عندما يوفر الحل تنفيذًا دون المستوى المطلوب؟ ما اللجوء الذي يمتلكه المستخدمون؟ كيف يمكنهم إثبات أن الحل تصرف بطريقة خبيثة بدلاً من ارتكاب خطأ صادق؟ هذه الأسئلة تفتقر إلى إجابات واضحة في العديد من التصميمات الحالية. يظل بناء أطر للمساءلة للنظم التي تركز على النوايا أمرًا حيويًا لحماية المستخدمين.
قائمة التحقق من إطلاق الرموز قبل المشاريع المبنية على النوايا
تواجه الفرق التي تستعد لإطلاق الرموز في الأنظمة المبنية على النوايا اعتبارات فريدة تتجاوز التحضيرات النموذجية لإطلاق الرموز. يجب أن تتماشى هذه المشاريع مع الديناميكيات الأساسية لشبكة الحلول وآليات مطابقة النوايا.
تحديد لغة وبروتوكولات واضحة للنوايا
تتطلب المشاريع المبنية على النوايا الناجحة معايير واضحة لتعبير النوايا. يجب على الفرق:
توثيق مخططات النوايا بشكل شامل: تحديد أنواع النوايا التي يدعمها النظام، وكيفية تعبير المستخدمين عن القيود، وما هي المعايير المطلوبة مقابل الاختيارية. يجب أن تكون لغات النوايا معبرة بما يكفي لالتقاط رغبات المستخدمين بينما تبقى قابلة للتفسير بواسطة شبكات الحلول.
توفير أدوات ومجموعات تطوير البرمجيات (SDKs) للمطورين: يتطلب بناء التطبيقات على الأنظمة المبنية على النوايا أدوات مختلفة عن تطوير المعاملات. من خلال توثيق واضح، أمثلة على الشيفرات، وإطارات الاختبار، يمكن تقليل العوائق أمام التبني.
النظر في القابلية للتوسع في المستقبل: يجب أن تدعم لغات النوايا التطور. ستظهر أنواع جديدة من النوايا؛ يجب أن يحتوى عليها المعيار بدون كسر التطبيقات الشائعة. النماذج الإصدارية وسياسات الإهمال تهم.
بناء أو الشراكة لتوفير البنية التحتية للحلول
تمثل شبكات الحلول العمود الفقري للتنفيذ في أنظمة النوايا. يجب أن تضمن المشاريع الرمز القوي لحل القدرة:
تحفيز المشاركة الأولية للحلول: يتطلب الإطلاق حلولًا كافية لتقديم تنفيذ تنافسي. قد تحتاج الفرق إلى تشغيل الحلول الأولية بأنفسها، أو تقديم دعم للمشاركين الأوائل، أو الشراكة مع مشغلي الحلول الحاليين من بروتوكولات أخرى.
تصميم آليات التحفيز للحلول بعناية: تحتاج الحلول لتعويض يغطي التكلفة بينما يحفز نتائج مستخدم مثالية. يجب أن تكافئ اقتصادات الرموز تصرفات الحل الجيدة – توفير فائض للمستخدمين – بينما تعاقب أو تستبعد الفاعلين السيئين.
تجنب الاحتكار الحلولي عبر التصميم: يمكن تعزيز اللامركزية الحلولية عبر استراتيجيات متنوعة. خفض حواجز الدخول عن طريق تقليل متطلبات رأس المال. تنفيذ أنظمة السمعة التي تسمح للحلول الجديدة ببناء مصداقية تدريجيًا. Consider delegated solving models where solvers specialize rather than requiring each to handle everything.
التخطيط لتنسيق حلول عبر السلسلة: إذا كان البروتوكول يتضمن نوايا عبر السلسلة، تحتاج الحلول لآليات للتعاون عبر المجالات. حدد كيفية التسوية، ومن يتحمل تكاليف الجسر، وكيف تحل النزاعات.
تدقيق منطق مطابقة النية-الحلول
يشكل جوهر أي نظام مبني على النوايا كيفية مطابقة النوايا مع القدرة التحق١١يفية للحلول. قبل إطلاق الرمز:
إجراء تدقيق أمني شامل: يجب أن يكون منطق مطابقة النوايا منيعًا. يمكن أن تتيح الأخطاء للحلول استخراج القيمة بشكل غير عادل أو ترك النوايا غير ملباة. تعامل مع شركات تدقيق متعددة ذات خبرة فالمحتوى: "المواد إلى هذا الموقع بحلول هذا التاريخ مع دليل على الأصالة."
قد تعتمد آليات التنسيق الاجتماعي على النوايا. يمكن أن تعبر DAOs عن الرغبات الجماعية – تمويل هذه السلع العامة، تحقيق هذه النتائج – ويمكن لشبكات الحلول تحديد تخصيصات الموارد المثلى. تمويل تربيعي، التمويل الرجعي للسلع العامة، وتصاميم آليات أخرى تصبح أكثر عملية عندما تتعامل طبقات النوايا مع تعقيد التنفيذ.
يمكن أن تصبح تحسينات العوائد عبر السلاسل مؤتمتة بالكامل. يعبر المستخدمون عن تحمل المخاطر وتوقعات العوائد؛ ويقوم الحلول بتعديل التوازن ديناميكيًا عبر البروتوكولات والسلاسل لتحقيق أقصى النتائج. يختفي العناء الذهني لإدارة مراكز DeFi بنشاط.
تحول في تصميم التبادل
قد تكون تصميمات التبادل اللامركزي الحالية خطوات وسيطة بدلاً من حالات نهائية. إذا أصبح مطابقة النوايا كفءًا بشكل كافٍ، قد تصبح واجهات التبادل المنفصلة غير ضرورية. يمكن أن تصبح المحافظ نفسها واجهات نوايا، مع حلول توفر السيولة عند الطلب بدلاً من خلال تجمعات السيولة الدائمة.
يمكن لهذا التحول أن يحسن كفاءة رأس المال بشكل كبير. بدلاً من مليارات مقفلة في تجمعات AMM ذات العوائد المنخفضة، يمكن لصانعي السوق المحترفين نشر رأس المال بشكل ديناميكي. يحصل المستخدمون على أسعار أفضل؛ ويحصل مقدمو السيولة على عوائد أعلى. الوسطاء الذين يقدمون القيمة – الحلول المتطورة – يستحوذون على التعويض المناسب بدلاً من أن يحصل رأس المال السلبي على معظم المكافآت.
قد تتطور المجمّعات إلى ميتا-حلون، تنسق بين شبكات الحلول المتخصصة. بدلاً من تجميع مصادر السيولة مباشرة من DEX، فإنها تجمع قدرات الحلول، وتوجيه النوايا إلى أي شبكة يمكنها تنفيذ الأفضل لأنواع النوايا المحددة.
تغييرات في القوة: من سلاسل إلى حلول
قد ينتقل مركز القيمة والتحكم من طبقة 1 من البلوكتشين إلى طبقات تنسيق النوايا. إذا تفاعل المستخدمون في المقام الأول عبر واجهات النوايا، يهم السلسلة الأساسية للتسوية أقل. الحلول تختار أماكن التنفيذ؛ يهم المستخدمون فقط النتائج.
هذا التحول قد يقلل من القبلية والتنافس بين السلاسل. إذا كانت Ethereum، Solana، وسلاسل أخرى تعمل أساساً كطبقات تسوية لشبكات النوايا، فإن الاختلاف بينها يصبح تقنيًا (السرعة، التكلفة، الأمان) بدلاً من أن يكون ثقافياً. التطبيقات تصبح حقاً غير مرتبطة بسلاسل.
ومع ذلك، يركز هذا أيضاً القوة في شبكات الحلول. إذا هيمن مشغلو الحلول القليل على السوق، فإنهم يتحكمون في السلاسل التي تُستخدم، والتطبيقات التي تنجح، وكيفية تدفق القيمة. قد يتم تقويض اللامركزية التي وعدت بها البلوكتشين بسبب بنية حلول مركزية. منع هذا النتيجة يتطلب انتباهاً يقظاً لتصميم شبكات الحلول.
تطور تطوير العقود الذكية
قد يتحول تركيز مطوري العقود الذكية من كتابة منطق التنفيذ إلى تعريف لغات النوايا وشروط الصلاحية. بدلاً من برمجة "إذا حدث X، قم بـ Y"، يتم برمجة "هذه النتائج صالحة، أي شيء آخر غير صالح."
هذا التحول يعكس تحولات أخرى في نماذج البرمجة. البرمجة التصريحية تهيمن بالفعل على العديد من المجالات – SQL لقواعد البيانات، CSS للتصميم، React لواجهات المستخدم. تطوير البلوكتشين القائم على النوايا يمدد النهج التصريحي إلى التنسيق على السلسلة.
قد تتغير المهارات المطلوبة في المطورين. المعرفة العميقة برموز VM المحددة تصبح أقل أهمية؛ يصبح فهم تصميم الآليات، نظرية الألعاب، وارتفاع القيود أكثر أهمية. الانتقال سيفضل المطورين الذين يفكرون في النتائج والحوافز على أولئك الذين يركزون على تفاصيل التنفيذ.
الآثار التنظيمية
قد تعقد الأنظمة القائمة على النوايا الرقابة التنظيمية. عندما يعبر المستخدمون عن النتائج وتتعامل الحلول مع التنفيذ، من المسؤول عن الامتثال؟ إذا سهل الحل انتهاكًا تنظيميًا غير مقصود أثناء تلبية نية صالحة تقنيًا، أين تقع المسؤولية؟
بالعكس، قد تُمكن بنى النوايا امتثالًا أفضل. يمكن أن تحتوي النوايا على قيود تنظيمية يجب على الحلول الوفاء بها. تحديد المواقع الجغرافية، متطلبات KYC، حدود المعاملات – كلها يمكن التعبير عنها كقيود نوايا. تفقد الحلول التي تخرق هذه القيود سمعتها وضماناتها، مما يخلق اندفاعًا للامتثال مدفوعاً بالسوق.
يعتمد النتيجة على كيفية هندسة المشروعات للمسؤولية. يمكن للأنظمة التي تجعل التحقق من الامتثال مباشراً مع الحفاظ على سرية المستخدم تلبية كلاًا من الاحتياجات التنظيمية وقيم الويب 3. سيواجه أولئك الذين يسمحون بالتغيير التنظيمي من خلال شبكات حلول غامضة على الأرجح إجراءات صارمة.
أفكار ختامية
يمثل التصميم القائم على النوايا إعادة تصور جذرية لكيفية تفاعل البشر مع أنظمة البلوكتشين. حيث مكنت العقود الذكية التسوية المبرمجة، تعد بنى النوايا المبرمجة النية – يُعرب المستخدمون عن ما يريدون بدلاً من كيفية تحقيقه.
الفوائد مغرية: تجربة مستخدم مبسطة بشكل كبير، حماية من استغلال MEV، تنسيق سلس عبر السلاسل، وزيادات في كفاءة رأس المال. تُظهر التطبيقات المبكرة مثل CoW Protocol أن هذه المزايا يمكن تحقيقها اليوم، وليس فقط في مستقبل افتراضي. مشاريع مثل Anoma وSUAVE تبني بنية تحتية يمكن أن تجعل التفاعل القائم على النوايا هو الافتراضي عبر جميع Web3.
لكن المخاطر تتطلب الانتباه الدقيق. يمكن أن تعيد مركزية الحلول إنشاء تركيز القوة الذي سعت البلوكتشين إلى القضاء عليه. تظل تحديات الخصوصية دون حلول. قد يحد تعقيد التنفيذ من التبني. ستكون الانتقال من الأنظمة المرتكزة على المعاملات تدريجيًا وفوضويًا.
بالنسبة للمستخدمين، فهم هذا التحول مهم لأنه سيشكل كيفية تفاعلك مع تطبيقات البلوكتشين في السنوات القادمة. من المحتمل أن تصبح الواجهات القائمة على النوايا هي القاعدة، لتجريد التعقيد ولكن أيضًا لإخفاء تفاصيل التنفيذ. اعرف ما تثق فيه عندما توقع النوايا بدلاً من المعاملات.
بالنسبة للمطورين، يقدم التصميم القائم على النوايا فرصة لبناء تطبيقات كانت غير عملية في السابق. ولكنه يتطلب تعلم نماذج جديدة وقبول أن كودك لن ينفذ مباشرة – ستفعل ذلك شبكات الحلول. اعتبر ما إذا كان هذا النموذج يناسب احتياجات تطبيقك.
بالنسبة لفرق الرمز الرمزي في هذا المجال، القائمة المرجعية المقدمة سابقًا تسلط الضوء على الاعتبارات التي تتجاوز الإطلاقات النموذجية للرمز الرمزي. الناجح أو الفاشل في البرتوكولات المستندة إلى النوايا يستند إلى صحة شبكة الحلول، صحة تصميم الآلية، وجودة تجربة المستخدم. احصل على هذه الأسس بشكل صحيح قبل التركيز على سعر الرمز.
لن يحدث التحول إلى البنى القائمة على النوايا بين عشية وضحاها ومن غير المحتمل أن يكون مطلقًا. ستسيطر الأنظمة الهجينة لسنوات. ولكن يبدو أن الاتجاه واضح: يحتاج Web3 إلى تجريد التعقيد إذا كان يأمل في الوصول إلى التبني السائد. يوفر التصميم القائم على النوايا طريقًا إلى الأمام، يقايض بعض الشفافية بتحسينات هائلة في الاستخدام.
ما إذا كان هذا التحول يفي في النهاية بوعوده يعتمد على كيفية إدارة النظام البيئي للمفاضلات بشكل جيد. هل يمكن أن تبقى شبكات الحلول لا مركزية؟ هل يمكن الحفاظ على الخصوصية مع تمكين التنفيذ الأمثل؟ هل يمكن أن تظهر المعايير التي تسمح بالتحويل دون قمع الابتكار؟
ستحدد الإجابات على هذه الأسئلة ما إذا كان التصميم القائم على النوايا سيصبح الهيكل السائد لـWeb3 أو يبقى نهجًا خاصًا لحالات استخدام محددة. ما هو مؤكد هو أن المحادثة قد انتقلت إلى ما بعد "ما إذا كان" إلى "كيف" – يجري بناء النموذج الآن، مع مليارات في رأس المال ومشاركة كبيرة من المطورين.
بالنسبة لأي شخص يشارك في Web3 – كمستخدم، مطور، مستثمر، أو باحث – أصبح فهم البنى القائمة على النوايا من الضروريات. هذه ليست مجرد احتمال مستقبلي بعيد ولكنها تحول نشط لأنظمة البلوكتشين الأساسية. العقود الذكية التي عرفت الفصل الأول من Web3 تتراجع لصالح طبقات النوايا التي قد تعرف الفصل التالي.
انتبه، جرب بحذر، وادرك أن ما يبدو كتطوير طفيف في تجربة المستخدم يمكن أن يكون بداية لأهم تطور معماري في البلوكتشين منذ أن قدمت Ethereum التسوية المبرمجة. يجري كتابة مستقبل Web3 الآن بلغات النوايا، شبكات الحلول، والاختيارات التصميمية التي ستحدد فيما إذا كان البلوكتشين سيصبح في متناول الجميع أخيرًا أو يبقى مجالاً للمتخصصين التقنيين.
الفرصة هائلة. وكذلك الرهانات."