نقاش البروتوكول: خمس رؤى لـ OrcaRail غير احتجازية بالكامل
20 أبريل 2026 — تصف خارطة الطريق غير الاحتجازية التي نشرناها الأسبوع الماضي مسارًا واحدًا: عقود ذكية على كل شبكة، وkeeper تشغّله OrcaRail، ومفهرس تشغّله OrcaRail، وAPI تشغّلها OrcaRail. يزيل هذا المسار الحفظ، لكنه يُبقينا في منتصف كل شيء آخر تقريبًا.
سأل عدد من القرّاء، وهم محقون: إذا كان الهدف أن نصبح بروتوكولًا، فلماذا نتوقف عند إزالة الحفظ؟ كيف ستبدو البنية لو اختفت OrcaRail غدًا واستمرت المدفوعات في التدفق؟
هذا المقال نقاش. خمسة مواقف تدافع عن خمس بنى مختلفة. ومحاور يختبر كل واحد منها. لا أحد يفوز فوزًا كاملًا، لكننا في النهاية نصبح أوضح بشأن المفاضلات التي نختارها فعلًا.
ماذا يعني «بروتوكول غير احتجازي بالكامل» بالضبط
قبل بدء النقاش نحتاج إلى تعريف مشترك. يكون النظام بروتوكولًا غير احتجازي بالكامل إذا تحققت كل الشروط التالية:
- الحفظ: لا يحتفظ أي طرف بأموال المستخدمين أثناء انتقالها، ولا حتى لكتلة واحدة.
- الاستمرارية: لا يُشترط وجود أي طرف منفرد لحدوث دفعة أو خصم اشتراك مشروع.
- مقاومة الرقابة: لا يستطيع أي طرف منفرد رفض معاملة سليمة البنية ومدفوعة.
- التحكم في الترقيات / التغييرات: تتطلب الترقيات موافقة عدة أطراف، لا نشرًا من شركة واحدة.
- الشفافية: القواعد التي يثق بها المستخدم مقروءة بالكامل على السلسلة أو تحت تجزئة قابلة للتحقق.
الخطة الحالية تحقق (1). وتحقق جزئيًا (3) و(4) و(5). ولا تحقق (2)؛ فما زال الـ keeper والـ API من OrcaRail مطلوبين لتشغيل المسار الطبيعي بشكل موثوق. يدور النقاش أدناه حول ما إذا كان علينا دفع المعايير الأربعة المتبقية حتى النهاية، وبأي تكلفة.
المواقف
يدخل خمسة معماريين. لنستمع إليهم.
- البراغماتي — عقود ذكية + API من OrcaRail (خارطة الطريق الحالية).
- المتشدد — بروتوكول على السلسلة بالكامل + واجهة أمامية لامركزية («نموذج Uniswap»).
- السيادي — OrcaRail كطبقة ثالثة / سلسلة تطبيقات مع precompiles مخصصة للمدفوعات.
- المؤمن بالـ intents — يعبّر الدافعون عن intents؛ وتسوّيها شبكة solvers دون إذن.
- المدافع عن المعايير — EIP مفتوح لروابط الدفع والاشتراكات؛ يطبّقه أي أحد.
الجولة 1: البيانات الافتتاحية
البراغماتي: «أطلِق شيئًا حقيقيًا، ثم اجعل الأجزاء المؤلمة لامركزية.»
خارطة الطريق تزيل أصلًا المشكلة الصعبة (الحفظ). يمكن أن يكون الـ keeper أي طرف؛ فمُجدوِل NestJS لدينا مستدعٍ واحد بين عدة مستدعين، ويمكن تسجيل Chainlink وGelato غدًا. المفهرس عام: يمكن لأي شخص الاشتراك في أحداث Paid وCharged نفسها وإعادة بناء الحالة. «API الخاصة بـ OrcaRail» ليست طبقة التسوية، بل طبقة راحة فوق عقود عامة. التجار الذين يريدون المسار البروتوكولي الكامل يمكنهم أصلًا تجاوزنا واستدعاء المصنع مباشرةً.
الادعاء: نحن بروتوكول بنسبة 80%. الـ 20% المتبقية أدوات (محافظ، لوحات تحكم، بريد إلكتروني)، لا ثقة. ويجب أن تبقى الأدوات قابلة للتطوير المستمر.
المتشدد: «لا API. أحداث، عقود، subgraph. هذا كل شيء.»
Uniswap موجود. 1inch موجود. يُصل إليهما عبر واجهات أمامية تستضيفها شركاتهما، لكن أيًّا من هذه الواجهات قد يختفي ويستمر البروتوكول في العمل. هذا هو معنى «البروتوكول».
بالنسبة لـ OrcaRail، يبدو ذلك هكذا:
- مصانع ومراكز وموزّعات على كل شبكات EVM/سولانا.
- subgraph مرجعي (أو مفهرس سولانا) يمكن لأي شخص الاستعلام منه.
- واجهة أمامية لامركزية مثبّتة على IPFS/Arweave، يُوصل إليها عبر ENS (
orcarail.eth). لوحة تحكم التاجر وتطبيق الدفع حِزم ثابتة؛ وكل إصدار معنون بالمحتوى. - لا REST API من OrcaRail في المسار الحرج. تستدعي الـ SDK الـ subgraph مباشرةً. وتُشتق الـ webhooks من الأحداث على السلسلة عبر مفهرسات كخدمة (Alchemy، QuickNode، أو مستضافة ذاتيًا).
الادعاء: أي شيء يحتاج إلى api.orcarail.com لكي تعمل الدفعة هو بروتوكول ناقص.
السيادي: «اجعل المدفوعات precompile على سلسلتنا الخاصة.»
المدفوعات حساسة لزمن الاستجابة ومتكررة. ندفع الغاز نفسه للتقسيم نفسه في كل مرة. لماذا نستأجر أمان L1/L2 لحالة استخدام يمكن تخصيصها؟
لنطلق سلسلة OrcaRail كـ rollup على OP Stack (أو سلسلة تطبيقات Cosmos، أو سلسلة Arbitrum Orbit). عندها:
- تصبح دلالة روابط الدفع precompile، لا عقد Solidity من 80 سطرًا. تنخفض الرسوم من سنتات إلى ما يقارب الصفر.
- يُدمج منطق الـ keeper في إنتاج الكتل: يطلق الـ sequencer استدعاءات
charge()كجزء من الكتلة، مع قابلية المعاقبة بأمان السلسلة نفسها. - يستخدم الجسر إلى الشبكات «الحقيقية» (Ethereum، Arbitrum، سولانا) الجسر المرجعي الحالي + Relay؛ سلسلة OrcaRail طبقة تنسيق، لا طبقة قيمة.
- تصبح الاشتراكات مواطنًا من الدرجة الأولى؛ «الاشتراك» نوع معاملة، مثل «التحويل» في بيتكوين.
الادعاء: أرخص طريقة لجعل بروتوكول يعمل بموثوقية على نطاق واسع هي ألا يتقاسم مساحة الكتل مع عمليات سك NFT عشوائية.
المؤمن بالـ intents: «يعبّر الدافعون عن نيتهم. ويتنافس الـ solvers على التسوية.»
يقول الدافع: «أريد أن أدفع للتاجر X مبلغ 50 دولارًا بـ USDC من أي من محافظي، خلال الساعة القادمة، مع تحسين الرسوم». هذا intent: موقّع، لكنه ليس معاملة بعد.
ترى شبكة solvers دون إذن (على نمط CoW أو SUAVE أو Anoma أو مرحّلات شبيهة بـ Across) الـ intent، وتجد أرخص مسار (بما في ذلك الجسور والعمليات عبر الشبكات، من أي رمز يملكه الدافع) وتسوّيه. ويحصل الـ solvers على مكافأة مضمّنة في الـ intent.
للاشتراكات: يوقّع الدافع intent متكررًا («اسحب 20 دولارًا شهريًا بـ USDC من محفظتي إلى PDA هذا التاجر، لمدة 12 شهرًا، قابلًا للإلغاء في أي وقت»). يتنافس الـ solvers على استدعاء charge() عند الاستحقاق، مقابل رسوم صغيرة. هذا ما يصبح عليه «AVS للـ keepers» في المرحلة 6 إن دققت النظر، لكن مع سوق حقيقية بدلًا من نظام معاقبة.
الادعاء: الـ keepers ليسوا مشكلة موثوقية فعلًا، بل مشكلة تصميم سوق. لنبنِ السوق.
المدافع عن المعايير: «اكتب EIP. الجميع يربح، ونحن منهم.»
روابط الدفع والاشتراكات في OrcaRail مكوّن أساسي عام. تبني Shopify وCoinbase Commerce وغيرها من منظومات الدفع بالكريبتو المستضافة وعشرات الشركات الناشئة الشيء نفسه. يجب أن نكتب EIP لروابط الدفع غير الاحتجازية وEIP مرافقًا لاشتراكات سحب الـ allowance، مع تطبيق مرجعي.
عندها:
- يمكن لأي محفظة عرض رابط دفع بواجهة قياسية («أنت تدفع للتاجر X، 50 دولارًا، USDC، غير احتجازي»).
- يدعم أي مفهرس (The Graph أو Goldsky أو Envio) الأحداث القياسية مباشرةً.
- يمكن لأي معالج، بما في ذلك منافس مستقبلي لـ OrcaRail، استضافة البروتوكول نفسه.
- يصبح منتج OrcaRail أفضل تطبيق لمعيار مفتوح، لا منظومة مغلقة.
الادعاء: أكبر ميزة تنافسية في المدفوعات هي الثقة في المكوّن الأساسي، لا في منظومة شركة واحدة. لنجعل المكوّن الأساسي عامًا.
الجولة 2: المحاور يستجوب
إلى البراغماتي: «كن صريحًا؛ إذا توقفت OrcaRail عن دفع فاتورة الـ paymaster، هل يستمر خصم اشتراك Alice؟»
البراغماتي: في خارطة الطريق الحالية، بعد المرحلة 3، نعم؛ يواصل Chainlink Automation تنفيذ charge(). فاتورة الـ paymaster مخصصة لغاز الـ keeper، ويستخدم Chainlink عملة LINK للمهمة نفسها. لكن التجار الذين يحتاجون لوحة تحكم OrcaRail للمطابقة سيتأثرون: فرسائل البريد وإعادة المحاولات ورموز الأخطاء المقروءة كلها في API الخاصة بنا. تستمر العقود في العمل؛ أما المنتج فلا.
المحاور: هل «العقود تعمل لكن البشر لا يعرفون» استمرارية حقًا؟
البراغماتي: إنها استمرارية التسوية دون استمرارية تجربة الاستخدام. هذا تمييز حقيقي، ويجب أن نعترف به لا أن نخفيه. كما أن إصلاحه رخيص مع الوقت: ننشر قوالب البريد، ونفتح مصدر المفهرس، وندع غيرنا يستضيف لوحة التحكم. لا يلزمنا فعل كل ذلك في المرحلة 1.
إلى المتشدد: «لوحات التحكم على IPFS المثبّتة عبر ENS رائعة، إلى أن ترسل إلينا جهة تنظيمية خطابًا بشأن تاجر.»
المتشدد: عندها تتوقف OrcaRail عن استضافة ذلك التاجر في لوحة تحكمها. ويستمر البروتوكول في خدمته عبر واجهة أمامية أخرى، أو واجهته الخاصة. هذه ميزة لا خلل؛ قارن بالتمويل التقليدي، حيث «جمّد المعالج حسابي» دراما متكررة لا علاج لها على مستوى البروتوكول.
المحاور: التجار الذين يطردهم معالج بطاقات يُطردون عادةً من شبكة Visa أيضًا. في المدفوعات، كثيرًا ما تكون البنية والمعالج الرقيب نفسه.
المتشدد: صحيح، وهذه بالضبط المشكلة التي يحلها البروتوكول. لا تستطيع Visa فرض رقابة على Ethereum. ولا تستطيع OrcaRail، ببنية بروتوكولية، فرض رقابة على التجار على مستوى البنية، بل على مستوى الواجهة الأمامية فقط. الواجهات قابلة للاستبدال؛ أما البنية فلا.
إلى السيادي: «كيف يسحب التجار إلى USDC على Ethereum إذا كانت التسوية على سلسلة OrcaRail؟»
السيادي: بالطريقة نفسها التي يغادر بها أي أحد أي L2: عبر الجسر المرجعي. سندمج Relay بشكل أصيل لتكون مغادرة العملات المستقرة فورية. حجم السحب اليومي ضئيل مقارنةً بالحجم داخل السلسلة.
المحاور: أنت تطلب منا تشغيل سلسلة. كل سلسلة مهمة لها أنماط أعطال: توقف الـ sequencer، وتأخر نشر state root، والخروج عبر الجسور. وهذه الأعطال علنية وظاهرة. عنوان «توقف sequencer الخاص بـ OrcaRail لمدة 3 ساعات، وتوقفت المدفوعات عالميًا» أسوأ من «تعطلت API الخاصة بـ OrcaRail لمدة 3 ساعات».
السيادي: هو عنوان أسوأ فقط إلى أن تجعل الـ sequencer لامركزيًا. براهين الاحتيال في OP Stack والتسلسل المشترك (Espresso، Astria) تجعل هذا تدريجيًا أقل اعتمادًا على طرف واحد. أنت محق في أننا لن نبدأ من هناك. ومحق أيضًا في أنه لا ينبغي أن نشغّل سلسلة وحدنا؛ سنطلقها عبر شريك rollup-as-a-service مع مسار موثوق نحو التسلسل المشترك.
المحاور: هذه تبعيات كثيرة.
السيادي: نعم. والمقابل: نتوقف عن دفع الغاز إلى الأبد، ونتوقف عن التنافس على مساحة كتل الشبكة الرئيسية، ونتمكن من إطلاق مكوّنات مخصصة. إذا كان حجم المدفوعات كبيرًا بما يكفي لتبرير أي من ذلك، فهو مبرَّر. وإن لم يكن، فأنا مخطئ.
إلى المؤمن بالـ intents: «لأسواق الـ solvers مشكلة MEV. من يحمي الدافع من solver يقتطع لنفسه؟»
المؤمن بالـ intents: يُوقَّع الـ intent بقيود صارمة. لا يمكن أن يتجاوز المبلغ المدفوع ما أذن به الدافع. ما يمكن أن يتغير هو المسار (أي جسر، وأي DEX إن لزم swap) والتوقيت. لا يستطيع الـ solver الخبيث تحويل الأموال إلى وجهة أخرى؛ وفي أسوأ الأحوال يكون بطيئًا. والمنافسة تقضي على ذلك.
المحاور: المنافسة تخفّض الرسوم على المسارات عالية الحجم. فماذا عن دفعة صغيرة بقيمة 5 دولارات من USDC إلى USDC عبر الشبكات لا يحصل أحد على ما يكفي لتسويتها؟
المؤمن بالـ intents: هذه فجوة حقيقية. والإجابة هي solvers احتياطيون: تشغّل OrcaRail واحدًا بسعر التكلفة. السوق تغطي الـ 95% العليا؛ ونحن نغطي الذيل الطويل. ومع الوقت، تسد الشبكات الأرخص والجسور الأفضل هذه الفجوة.
المحاور: إذن أنت أيضًا تشغّل keeper، لكنك تسميه solver.
المؤمن بالـ intents: keeper هو واحد من عدة، يتنافس على intent عام، ومعه احتياطي؛ نعم. هذا هو الفرق بين «الخادم الخلفي لـ OrcaRail هو الـ keeper» و«OrcaRail مشارك في سوق مفتوحة».
إلى المدافع عن المعايير: «الـ EIPs تستغرق سنوات. ماذا نفعل حتى ذلك الحين؟»
المدافع عن المعايير: تطلق التطبيق المرجعي أولًا وفق خطتك الحالية. ثم تصوغ الـ EIP حول ما أطلقته، لا مسبقًا. هكذا كُتبت ERC-4337 وERC-721 وERC-20. خارطة الطريق الحالية متوافقة مع ذلك؛ يمكن أن تكون واجهة SubscriptionHub هي واجهة الـ ERC مع تعديلات طفيفة في الأسماء.
المحاور: هل هناك خطر في نشر «ميزتك التنافسية» كمعيار؟
المدافع عن المعايير: الميزة ليست العقد. الميزة هي التكاملات واتفاقيات مستوى الخدمة وعمل الامتثال ولوحات التحكم وقابلية توصيل البريد وثقة التجار. لا شيء من ذلك يستطيع منافس نسخه بقراءة EIP. فتح واجهة العقود ينقل المنافسة إلى المواضع التي نحن أقوياء فيها.
الجولة 3: أين يفوز كل موقف فعلًا
بعد الاستجواب، يتفوق كل موقف في أبعاد محددة. بطاقة نتائج صريحة:
| البُعد | البراغماتي | المتشدد | السيادي | الـ intents | المعايير |
|---|---|---|---|---|---|
| زمن إطلاق المرحلة 1 | سريع | بطيء | بطيء جدًا | بطيء | سريع |
| إزالة الحفظ | نعم | نعم | نعم | نعم | نعم |
| الاستمرارية دون OrcaRail | جزئية | قوية | متوسطة | قوية | قوية |
| مقاومة الرقابة | جزئية | قوية | متوسطة | قوية | قوية |
| تجربة العمليات عبر الشبكات | جيدة | جيدة | ضعيفة | الأفضل | جيدة |
| الوضوح التنظيمي | متوسط | متوسط | ضعيف | ضعيف | عالٍ |
| الاعتماد على بنية OrcaRail | عالٍ | منخفض | عالٍ جدًا (سلسلة) | منخفض | منخفض |
| تميّز OrcaRail | عالٍ | منخفض | عالٍ | متوسط | عالٍ |
| تسجيل التجار غير المتمرسين في الكريبتو | الأفضل | الأصعب | متوسط | متوسط | متوسط |
| التكلفة الهندسية | منخفضة | متوسطة | عالية جدًا | عالية | متوسطة |
| أعطال ظاهرة للمستخدمين الحاليين | لا شيء | كبيرة | جسيمة | متوسطة | صغيرة |
لا يوجد صف مهيمن. ولهذا السبب هذا نقاش وليس خطة إطلاق.
الجولة 4: خلاصة المحاور
هكذا سأقرأ النقاش فعلًا، بصفتي الشخص الذي عليه أن يختار.
البراغماتي يفوز اليوم لأن المنتج يجب أن يستمر في الإطلاق، ولا نملك ترف التوقف 18 شهرًا لإعادة كتابة البنية. خارطة الطريق الحالية نسخة أفضل تمامًا من النسخة الاحتجازية التي نشغّلها اليوم، مع تحسينات تدريجية متوافقة.
المتشدد يفوز من حيث المبدأ ويلتقط قيدًا حقيقيًا: اليوم الذي تكون فيه API الخاصة بنا سبب عدم حصول تاجر على أمواله هو اليوم الذي نتوقف فيه عن كوننا بروتوكولًا. هذا هو الضغط الذي يجب أن يوجّه كل قرار هندسي في المراحل 1 إلى 7: انشر المفهرس، وانشر الـ subgraph، وثبّت لوحة التحكم على IPFS تحت ENS، ووثّق كيفية الاستضافة الذاتية. خارطة طريق البراغماتي تجعل ذلك ممكنًا، لكنها لا تفرضه. يجب أن نفرضه.
السيادي يفوز إذا برّر الحجم ذلك. تحت عتبة حجم معينة، يكون تشغيل سلسلة عبئًا. وفوقها، يصبح استئجار مساحة كتل Ethereum لتقسيم 3 دولارات على ستة أطراف في كل مرة أمرًا عبثيًا. سنعرف أننا تجاوزنا تلك العتبة عندما يكون الجزء الغالب من حجمنا مسارات من الدافع إلى التاجر على الشبكة نفسها، ويصبح تحسين الغاز وفرًا قابلًا للقياس في القوائم المالية. ليس بعد.
المؤمن بالـ intents يفوز في العمليات عبر الشبكات. المدفوعات بطبيعتها متعددة الأصول ومتعددة الشبكات. تدفق دافع قائم على الـ intents («ادفع للتاجر X، لا يهمني كيف») هو أفضل تجربة ممكنة لدافع كريبتو. يجب أن نعتمد الـ intents في طبقة SDK الدافع قبل اعتمادها في طبقة التسوية. هذا يجعل الـ solvers الحاليين (Across وdeBridge وRelay) ملائمين بشكل طبيعي دون الحاجة إلى بناء سوق جديدة.
المدافع عن المعايير يفوز حيثما يفوز المتشدد، بمخاطر أقل. كتابة EIP حول ما نطلقه في المرحلتين 1 و2 مجانية، ومفيدة للمنظومة، ولا تبطئنا. كما تمنحنا رواية موثوقة بأننا «نبني بنية، لا فخًا» للتجار الذين يقيّمون بنى الكريبتو لأول مرة.
الإجابة المدمجة
الخلاصة المملة لكن الصحيحة: أطلِق مسار البراغماتي، وافرض ضغط المتشدد، واعتمد الـ intents لتجربة الدافع، واكتب EIP على الطريق، وأبقِ السيادي خيارًا للمرحلة 8 وما بعدها مشروطًا بالحجم.
بشكل ملموس، هذه هي الالتزامات التدريجية فوق خارطة الطريق الحالية:
- M1: subgraph عام من المرحلة 1. كل أحداث
PaidوChargedفي subgraph مرجعي يمكن لأي شخص الاستعلام منه. دون تعطيل الـ API. - M2: تطبيق دفع مثبّت على IPFS من المرحلة 2. كل إصدار معنون بالمحتوى، و
pay.orcarail.ethقابل للوصول عبر ENS. - M3: حزمة استضافة ذاتية من المرحلة 3. Docker Compose + توثيق يتيحان لأي شخص تشغيل لوحة تحكم متوافقة مع OrcaRail من العقود نفسها.
- M4: SDK للـ intents من المرحلة 3. توجّه
orcarail.pay(intent)على العميل المدفوعات عبر الشبكات من خلال شبكات الـ solvers القائمة (Across/Relay). مع solver احتياطي تشغّله OrcaRail للذيل الطويل. - M5: مسودة EIP من المرحلة 2. المشاركة في كتابة EIP روابط الدفع مع معالج آخر أو فريق محفظة، على أساس
SubscriptionHubلدينا. - M6: تقييم ربع سنوي لخيار السيادي إلى جانب تقييم EigenLayer. المحفزات: حجم المدفوعات حسب الشبكة، وتكلفة الغاز لكل دفعة كنسبة من قيمتها، وطلب التجار على تسوية بأقل من سنت.
تنقل هذه الإضافات الخمس خارطة الطريق الحالية من «غير احتجازية» إلى «غير احتجازية، بشكل بروتوكولي، ومحايدة بشكل موثوق». ولا تبطئ المراحل 1 إلى 7. وتُتابَع كمسارات عمل حيّة ومستقلة.
وقد صيغت رسميًا كـ المسار P في الورقة البيضاء للبروتوكول، التي تحوّل M1-M5 إلى المراحل P1-P5 وتُبقي M6 (السلسلة الخاصة) كمرحلة P6 اختيارية.
ما لا نفعله صراحةً بعد
- سلسلة خاصة. ليس خلال الـ 18 شهرًا القادمة. نعيد التقييم كل ربع سنة.
- رمز OrcaRail عند الإطلاق. لا رمز الآن. رمز الحوكمة المستقبلي محجوز كخيار لما بعد اللامركزية (راجع الورقة البيضاء للبروتوكول للموقف الكامل). لا بيع مسبق، ولا تخصيصات، ولا نقاط.
- مسار المتشدد على السلسلة بالكامل دون أي API. يحتاج المنتج إلى واجهات مقروءة للبشر، ويحتاج التجار إلى جهة يتصلون بها عند حدوث مشكلة. سنتيح الاستخدام دون API، لكننا لن نفرضه.
- شبكة solvers خاصة بنا. نستخدم الشبكات القائمة. قد نشغّل solver احتياطيًا بسعر التكلفة للمسارات الطويلة التي يتجاهلها الـ solvers الحاليون، لكننا لن نطلق شبكة منافسة جديدة.
أين نقف
هذا المقال مرافق لـ خارطة الطريق غير الاحتجازية، لا بديل عنها. ما زالت خارطة الطريق تتابع المراحل 0-7. ويضيف هذا النقاش محورًا سادسًا، هو الشكل البروتوكولي، يجب تقييم كل مرحلة على أساسه.
إن كنت في هذا النقاش، فأرسل إلينا موقفك. سننشر الحجج المضادة القوية.
قراءات ذات صلة
- خارطة طريق OrcaRail نحو نموذج غير احتجازي — خارطة الطريق المرجعية
- لماذا يتفوق سحب الـ allowance على الضمان ومفاتيح الجلسة — نقاش نموذج الاشتراك، بالصيغة نفسها
- تقييم EigenLayer — سجل قرارات مرافق للـ keepers اللامركزية
- البنية — ما يبنيه مسار البراغماتي فعلًا