المعاملات بدون رسوم على سولانا: الدليل الكامل

تسمح المعاملات بدون رسوم على سولانا للراعي بدفع رسوم الشبكة للمستخدم. فهي لا تزيل الرسوم، أو تجعل كل معاملة مجانية، أو تضمن أن التوقيع على معاملة مدعومة لا يمكنه نقل أصول المستخدم.

آخر تحديث: يناير 2025

المعاملات بدون رسوم على سولانا هي معاملات على البلوكتشين لا يدفع فيها المستخدم النهائي أي رسوم شبكة لأن طرف ثالث معين، يسمى راعي الرسوم، يغطي التكلفة نيابة عنه. تم استعارة كلمة "بدون رسوم" (gasless) من مصطلحات الرسوم في إيثيريوم، حيث تسمى الرسوم "غاز". تستخدم سولانا نفسها "رسوم المعاملات"، وليس الغاز. لكن بشكل عام، أصبح مصطلح "بدون رسوم" يعني نفس الشيء عبر السلاسل: المستخدم لا يدفع شيئاً، وشخص آخر يدفع الفاتورة.

سولانا ليست بدون رسوم افتراضياً. كل معاملة على الشبكة تتطلب رسماً مدفوعاً بالـ SOL. تقوم العديد من التطبيقات اللامركزية (التطبيقات اللامركزية) برعاية هذه الرسوم نيابة عنك، مما يتيح لك البدء دون امتلاك أي SOL. ما إذا كنت بحاجة إلى SOL يعتمد على التطبيق اللامركزي المحدد: التطبيقات اللامركزية التي تدعم المعاملات بدون رسوم تغطي الرسوم لك، بينما تتطلب منك التطبيقات الأخرى دفعها بنفسك. يغطي هذا الدليل بنية دافع الرسوم، ومن يدفع ولماذا، وحالات الاستخدام الواقعية، ومسارات التنفيذ، وتحليل التكلفة، واعتبارات الأمان.

جدول المحتويات

1. المفهوم الأساسي: كيف تعمل بنية دافع الرسوم في سولانا
2. بدون رسوم مقابل مجاني: توضيح المفاهيم الخاطئة الأكثر شيوعاً
3. سولانا مقابل إيثيريوم: كيف تختلف المعاملات بدون رسوم عن تجريد الحساب
4. كيفية تنفيذ المعاملات بدون رسوم على سولانا
5. حالات الاستخدام الواقعية: أين تم نشر المعاملات بدون رسوم بالفعل على سولانا
6. تكلفة رعاية المعاملات: ما هي التكلفة الفعلية للمعاملات بدون رسوم على المطورين؟
7. اعتبارات أمنية: ما الذي يحتاج المطورون إلى معرفته حول مخاطر المرحّلين
8. اختيار النهج الصحيح: التنفيذ الأصلي مقابل الخدمة المُدارة
9. أسئلة متكررة حول المعاملات بدون رسوم على سولانا
10. ملخص: ما تحتاج إلى معرفته حول المعاملات بدون رسوم على سولانا

المفهوم الأساسي: كيف تعمل بنية دافع الرسوم في سولانا

تتضمن كل معاملة على سولانا حقلاً feePayer يحدد الحساب الذي يتم خصم رصيده من SOL لتغطية رسوم الشبكة، ولا يجب أن يكون هذا الحساب هو نفس الشخص الذي يبدأ المعاملة.

نموذج رسوم المعاملات في سولانا

تفرض سولانا رسماً أساسياً لكل توقيع وقد تفرض أيضاً رسوماً إضافية للأولوية. يجب التحقق من معلمة الرسوم الأساسية ومبلغها المقوّم بـ SOL مقابل الوثائق الحالية؛ يمكن أن تختلف التكلفة الإجمالية للمعاملة مع التوقيعات، وإعدادات الحوسبة، ورسوم الأولوية، وظروف الشبكة. يقوم المدققون، وهي عقد الشبكة التي تعالج وتتحقق من صحة المعاملات، بجمع هذه الرسوم كـ عمولة لعملهم الحسابي. إثبات التاريخ هو مكون لتحديد الوقت يُستخدم مع إثبات الحصة وبرج BFT. الرقم الذي غالباً ما يُستشهد به وهو 65,000 معاملة في الثانية هو معيار نظري بدلاً من إنتاجية تطبيق مضمونة.

للاطلاع على هيكل الرسوم الكامل، راجع وثائق رسوم معاملات سولانا.)

ما هو دافع الرسوم على سولانا؟

دافع الرسوم على سولانا هو الحساب المُعيَّن لدفع رسوم المعاملة. في معاملة قياسية، يكون دافع الرسوم وموقّع المعاملة هما نفس الحساب (محفظة المستخدم). في معاملة بدون رسوم، يكونان حسابين مختلفين عن قصد. يجب على كلا الحسابين توقيع المعاملة، ولكن يتم خصم الرسوم من رصيد SOL الخاص بدافع الرسوم فقط.

هذا الفصل مدمج في هيكل المعاملات الأساسي لسولانا عبر حقل feePayer. إنه ليس حلاً بديلاً، أو برنامجاً منفصلاً داخل الكتلة، أو إضافة على مستوى التطبيق. يمكن لأي معاملة على سولانا تحديد دافع رسوم مختلف عن طريق تعيين هذا الحقل. للمواصفات الفنية، راجع وثائق دافع الرسوم في سولانا.

كيف تتدفق معاملة بدون رسوم عبر الشبكة، خطوة بخطوة:

1. يبدأ المستخدم إجراءً في تطبيق لامركزي (تعدين NFT، مبادلة عملات، أو أي إجراء آخر داخل الكتلة).
2. يقوم التطبيق اللامركزي بإنشاء كائن معاملة ويحدد حقل feePayer لحساب راعٍ منفصل، وليس محفظة المستخدم.
3. يقوم المستخدم بتوقيع المعاملة عبر محفظته، مصرحاً بالتعليمات (الإجراء). توقيعه لا يخصم من رصيده.
4. يتم إرسال المعاملة الموقعة جزئياً إلى خادم المرحّل، الذي يحتفظ بمفتاح الراعي.
5. يقوم المرحّل بالتحقق من محتويات المعاملة للتأكد من أنها تتطابق مع البرنامج المطلوب وبيانات التعليمات.
6. يضيف المرحّل توقيع دافع الرسوم باستخدام مفتاح الراعي.
7. يرسل المرحّل المعاملة الموقعة بالكامل إلى شبكة سولانا، والتي تخصم الرسوم من رصيد دافع الرسوم، وليس من رصيد المستخدم.

فكر في الأمر وكأنه فاتورة مطعم. يطلب المستخدم (يوقع التعليمات)، لكن التطبيق يدفع الفاتورة (يدفع الرسوم).

ما هو مرحّل المعاملات؟

مرحّل المعاملات هو الخدمة الخلفية التي تجعل المعاملات بدون رسوم قابلة للتشغيل. يستلم المرحّل معاملة موقعة جزئياً من المستخدم (الذي قام بالتوقيع للسماح بالتعليمات ولكنه لم يدفع الرسوم)، ويضيف توقيع دافع الرسوم، ويرسل المعاملة الموقعة بالكامل إلى شبكة سولانا. يوجد نموذجان: مرحّل مستضاف ذاتياً، حيث يقوم مطور التطبيق اللامركزي بتشغيل خادمه الخاص، وخدمة مرحّل مُدارة، حيث يتولى طرف ثالث مثل Helius إدارة البنية التحتية.

في معاملة قياسية، تؤدي محفظتك وظيفتين: فهي تسمح بالإجراء وتدفع الرسوم. في معاملة بدون رسوم، تقوم محفظتك بالوظيفة الأولى فقط. عند استخدام تطبيق لامركزي يدعم المعاملات بدون رسوم، تطلب منك محفظة Phantom الخاصة بك (أو Solflare، أو Backpack، أو أي محفظة سولانا أخرى) التوقيع على المعاملة كالمعتاد. أنت توافق عليها. يخول التوقيع التعليمات: تعدين هذا الـ NFT، تنفيذ هذه المبادلة، تحديث هذا السجل. لن يتغير رصيد SOL الخاص بمحفظتك بعد هذا التأكيد. يتم دفع الرسوم بواسطة حساب دافع الرسوم الخاص بالتطبيق اللامركزي، والذي يتحكم فيه المرحّل. يجب ألا تكشف المحفظة المتوافقة عن مفتاحها السري، ويدفع الراعي رسوم الشبكة. ومع ذلك، لا تزال التعليمات التي يوقعها المستخدم يمكن أن تسمح بتحويلات العملات أو تغييرات أخرى في الحالة، لذا يجب مراجعة المعاملة بالكامل.

للتنفيذ الفني الكامل لكل نهج من نهج المرحّلين، راجع دليل التنفيذ.

مصطلحات أساسية

• دافع الرسوم: الحساب الذي يغطي رصيده من SOL رسوم المعاملة. في تدفق المعاملات بدون رسوم، يتحكم التطبيق اللامركزي في هذا، وليس المستخدم.
• مرحّل المعاملات: خدمة خلفية تستقبل معاملة موقعة جزئياً، وتضيف توقيع دافع الرسوم، وترسلها إلى الشبكة.
• راعي الرسوم: الكيان (مطور التطبيق اللامركزي، البروتوكول، أو الخدمة المُدارة) الذي يمول حساب دافع الرسوم ويمتص تكلفة المعاملة.

[رسم بياني: مخطط تدفق ثلاثي العُقَد يوضح "محفظة المستخدم توقّع التعليمات" مع سهم مُسمى "معاملة موقعة جزئيًا" يشير إلى "المُرحّل / دافع الرسوم يوقّع + يدفع الرسوم" مع سهم مُسمى "معاملة موقعة بالكامل" يشير إلى "شبكة Solana تؤكد" وسهم نهائي إلى "اكتمال الإجراء في محفظة المستخدم". فريق التصميم: العُقَد من اليسار إلى اليمين مع أسهم اتجاهية مُسماة.]

المعاملات بدون رسوم غاز (Gasless) مقابل المجانية: توضيح سوء الفهم الأكثر شيوعًا

مصطلح "Gasless" هو اختصار لرسوم مُرعاة (مُمولة): رسوم الشبكة موجودة وتُدفع دائمًا، لكن المستخدم النهائي ليس هو الطرف الذي يدفعها.

توجد ثلاثة سيناريوهات للرسوم على Solana، وواحد منها فقط هو حقًا بدون رسوم غاز:

• المعاملة القياسية: يدفع المستخدم الرسوم من رصيد SOL الخاص به. الرسوم هي 0.000005 SOL لكل توقيع.
• المعاملة بدون غاز (مُمولة): يقوم التطبيق اللامركزي (dApp) أو البروتوكول أو خدمة المُرحّل المدارة بدفع الرسوم نيابة عن المستخدم. يبقى رصيد SOL الخاص بالمستخدم دون مساس.
• المعاملة منخفضة الرسوم: يدفع المستخدم رسومًا ضئيلة جدًا لدرجة أنه بالكاد يلاحظها. هذه ليست معاملة بدون غاز؛ فالمستخدم لا يزال بحاجة إلى SOL.

رعاية المعاملات هو المصطلح الموجه للأعمال لما يجعل المعاملات بدون غاز تعمل. من منظور المنتج، تُعد تغطية رسوم المعاملات تكلفة لاكتساب المستخدمين، على غرار تقديم تجربة مجانية أو الدفع مقابل ظهور الإعلانات.

يتبع ذلك سؤال منطقي: إذا كنت لا أدفع، فما هو المقابل؟ الإجابة شفافة. التكلفة التي يتحملها الراعي ضئيلة للغاية عند مستويات رسوم Solana. تكلف رعاية 100,000 معاملة 0.5 SOL في الرسوم الأساسية. المنصَّة التي تدير عملية سك NFT بدون غاز تسترد هذه التكلفة أضعافًا مضاعفة من خلال رسوم السوق، أو إيرادات المبيعات الأولية، أو الاحتفاظ بالمستخدمين. تسترد بعض المنصات التكاليف من خلال فئات الاشتراك أو اقتصاديات الرموز (tokenomics) للبروتوكول.

الرسوم تذهب دائمًا إلى مكان ما. تذهب إلى مدققي Solana. السؤال هو فقط من الذي يرسلها.

للحصول على مناقشة كاملة للمخاطر التي تأتي مع رعاية الرسوم، راجع قسم اعتبارات الأمان.

Solana مقابل Ethereum: كيف تختلف المعاملات بدون غاز عن تجريد الحساب (Account Abstraction)

نموذج الغاز في Ethereum هو أصل مفهوم "Gasless"، وتُظهر مقارنة بنية دافع الرسوم الأصلية في Solana مع تجريد الحساب EIP-4337 في Ethereum سبب تحقيق النهجين لتجارب مستخدم متشابهة من خلال وسائل تقنية مختلفة.

تفرض Ethereum "رسوم غاز" مقابل الحوسبة. رسوم الغاز متغيرة، وتخضع للسوق، وتُدفع بعملة ETH (مقومة بـ gwei). خلال فترات ذروة الازدحام في الشبكة، وصلت رسوم معاملات Ethereum تاريخيًا إلى 50 دولارًا أو أكثر لكل معاملة. هذا التقلب هو بالضبط السبب في أن تجربة المستخدم بدون غاز أصبحت هدفًا تصميميًا ذا معنى في المقام الأول. عند مقارنة رسوم Solana برسوم غاز Ethereum، فإن فجوة الرسوم الأساسية تفسر سبب كون رعاية الرسوم تافهة اقتصاديًا على Solana ومكلفة حقًا على Ethereum. تمثل رسوم غاز Ethereum مقارنة برسوم معاملات Solana فرقًا يصل إلى عدة مراتب من حيث التكلفة المعتادة.

حل Ethereum لتجربة المستخدم بدون غاز هو EIP-4337، وهو معيار لطبقة التطبيقات (ليس تغييرًا على مستوى البروتوكول) يقدم دافعي الرسوم (Paymasters). دافعو الرسوم هم عقود ذكية ترعى رسوم الغاز نيابة عن المستخدمين. يتطلب نشر دافع رسوم وجود مجمع UserOperation، وعقد EntryPoint، وعقد دافع الرسوم نفسه. هذا استثمار كبير في البنية التحتية قبل أن يتمكن أي مستخدم من الاستفادة. للحصول على المواصفات الكاملة، راجع مواصفات EIP-4337.).

قبل EIP-4337، كانت Ethereum تستخدم المعاملات الوصفية (الموحدة تحت ERC-2771) كحل بديل. حيث يوقع المستخدم على رسالة تعبر عن نيته، ويقوم المُرحّل بتغليف تلك الرسالة في معاملة كاملة ويدفع رسوم الغاز. نهج Solana أنظف من الناحية الهيكلية لأن فصل دافع الرسوم هو ميزة بروتوكول من الدرجة الأولى بدلاً من نمط تغليف الرسائل في طبقة التطبيقات.

كلمة "Gasless" المطبقة على Solana هي مصطلح مستعار. تستخدم وثائق Solana "رسوم المعاملات"، وليس "الغاز". يعكس الاعتماد العام لمصطلح "Gasless" كيف شكلت Ethereum مفردات نمط تجربة المستخدم هذا عبر سلاسل الكتل.

لقد خفضت حلول طبقة 2 في Ethereum تكاليف الغاز في المينيت، وهذا التنويه ينطبق على أي مقارنة. يعكس الجدول أعلاه النطاقات التاريخية لمينيت Ethereum. يظل الاختلاف الهيكلي قائمًا: دافع الرسوم في Solana هو ميزة بروتوكول لا تتطلب نشر عقد إضافي، بينما EIP-4337 هو معيار لطبقة التطبيقات يتطلب نشر مجموعة من عقود دافع الرسوم.

كيفية تنفيذ المعاملات بدون غاز على Solana

توجد ثلاثة مناهج تنفيذ لإضافة رعاية الرسوم إلى تطبيق Solana. يعتمد الاختيار الصحيح على حجم المعاملات، وموارد التطوير، ومتطلبات الأمان، والقدرة على تحمل التبعيات لطرف ثالث. تستخدم جميع المناهج الثلاثة حقل feePayer الأصلي في Solana كآلية بروتوكول أساسية.

النهج 1: تعيين دافع الرسوم في حزمة أدوات تطوير البرمجيات (SDK) مدعومة

يقوم النهج الأصلي بتعيين حقل دافع الرسوم في كائن المعاملة ويستخدم حساب راعٍ مُدار بشكل آمن وممول بـ SOL. يجب على الفرق استخدام SDK يتم صيانته ويناسب بيئتهم الهندسية المعتمدة والتحقق من السلوك مقابل مواصفات معاملات Solana الحالية.

المتطلبات المسبقة: حساب راعٍ ممول محفوظ في نظام إدارة أسرار أو توقيع معتمد، واتصال RPC، وقواعد التحقق من المعاملات، والمراقبة، ومكتبة عميل يتم صيانتها.

الخطوات:

1. إنشاء كائن Transaction جديد.
2. إضافة التعليمات ذات الصلة (سك، أو مبادلة، أو تحويل، أو استدعاء برنامج آخر).
3. تعيين transaction.feePayer = sponsorKeypair.publicKey لتحديد حساب الراعي.
4. جلب recentBlockhash وتخصيصه للمعاملة. تنتهي صلاحية هاش الكتلة (blockhash) بعد حوالي 150 فتحة (حوالي 60 إلى 90 ثانية)؛ لذا قم بالإرسال على الفور أو قم بتنفيذ قيم عشوائية متينة (durable nonces) للتدفقات ذات التأخيرات التي لا يمكن تجنبها. راجع وثائق Solana حول الـ nonce المتين) لهذا النمط.
5. اطلب من محفظة المستخدم توقيع تعليمات المعاملة. يدفع الراعي رسوم الشبكة، ولكن لا يزال بإمكان التعليمات نقل أصول المستخدم أو إجراء تغييرات أخرى في الحالة.
6. إرسال المعاملة المتسلسلة الموقعة جزئيًا إلى نقطة نهاية خادم المُرحّل.
7. يقوم المُرحّل بالتحقق من محتويات المعاملة، ويضيف توقيع زوج مفاتيح الراعي، ويرسل المعاملة الموقعة بالكامل عبر RPC.

تتغير واجهات برمجة تطبيقات SDK وأنواع المعاملات بمرور الوقت. يجب أن يبني التنفيذ التعليمات المقصودة، ويعين الراعي كدافع للرسوم، ويحصل على هاش كتلة حالي أو nonce مدعوم، ويجمع التواقيع المطلوبة دون تعديل المحتوى الموقع، ويتحقق من صحة المعاملة المتسلسلة على المُرحّل، ويرسلها من خلال مزود RPC معتمد. تحقق من كل خطوة مقابل وثائق SDK والبروتوكول الحالية.

يجب الاحتفاظ بزوج مفاتيح الكفيل في جانب الخادم في جميع الأوقات. إن الكشف عنه في جانب العميل يتيح لأي مستخدم استنزاف رصيد SOL الخاص بالكفيل. للحصول على تحليل المخاطر الكامل، راجع المناقشة الأمنية الكاملة.

للحصول على مواصفات الحقل الرسمية، راجع وثائق دافع الرسوم في Solana.

النهج الثاني: استخدام خدمة مرحل مدارة (Managed Relayer Service)

تتولى خدمات المرحل المدارة إدارة بنية دافع الرسوم التحتية نيابة عن المطور، مما يسمح بدمج رعاية الرسوم عبر استدعاء API دون بناء أو صيانة خادم مرحل.

قد تشمل عروض المزودين المدارة ميزات المعاملات المدعومة أو المرحل. Helius وQuickNode وAlchemy هي أمثلة مذكورة في المصدر؛ ويجب التحقق من دعم Solana الحالي وشروط المنتج مباشرة. نمط التكامل النموذجي هو:

1. الحصول على أوراق الاعتماد من المزود المختار باستخدام عملية إدارة أسرار معتمدة.
2. بناء المعاملة في جانب العميل، مع إضافة التعليمات وتعيين transaction.feePayer إلى المفتاح العمومي المعين للمزود.
3. جعل محفظة المستخدم توقع المعاملة جزئيًا.
4. تسلسل المعاملة وإرسالها إلى نقطة نهاية المزود الخالية من الغاز عبر HTTP POST.
5. يقوم المزود بالتحقق من الصحة، والتوقيع المشترك كدافع للرسوم، وإرسال المعاملة إلى شبكة Solana.

يمكن للخدمة المدارة تقليل العمل التشغيلي المباشر، ولكنها تقدم تبعيات تتعلق بالمورد، وأوراق الاعتماد، والتوافر، والسياسة، والخصوصية، والتسعير. تعتمد مسؤوليات حضانة المفاتيح على بنية وعقد المزود. وثائق المزود هي نقطة انطلاق وليست بديلًا للمراجعة الأمنية.

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

تقدم كل من QuickNode وAlchemy بنية تحتية لـ Solana مع ميزات رعاية الرسوم أو ميزات قريبة من المرحل. تحقق من التوافر الحالي للميزات في وثائق كل مزود، حيث تتطور عروض الخدمات المدارة.

النهج الثالث: بناء مرحل معاملات مخصص

يكون مرحل المعاملات المخصص مناسبًا عندما يتطلب التطبيق منطقًا مخصصًا لأهلية الرعاية، أو يعمل على نطاق واسع مع متطلبات صارمة لإقامة البيانات، أو يحتاج إلى تحكم كامل في زوج مفاتيح دافع الرسوم.

تتكون بنية المرحل المخصص من خمسة مكونات:

1. نقطة نهاية API: تقبل المعاملات المتسلسلة الموقعة جزئيًا من الواجهة الأمامية لـ dApp عبر HTTP.
2. طبقة التحقق: تلغي تسلسل المعاملة وتتحقق من معرفات البرامج وبيانات التعليمات وقوائم الحسابات مقابل قائمة مسموح بها. هذا هو المكون الأكثر حساسية للأمن. يوقع المرحل على كل ما يتلقاه؛ لذا يجب عليه التحقق مما يتلقاه قبل التوقيع.
3. توقيع دافع الرسوم: يستخدم زوج مفاتيح مخزنًا في متغير بيئة أو مدير أسرار. لا تقم أبدًا بتخزين زوج المفاتيح في كود المصدر أو إرساله إلى مستودع.
4. إرسال RPC: يرسل المعاملة الموقعة بالكامل إلى Solana عبر RPC، مع منطق إعادة المحاولة لإخفاقات التأكيد والتعامل مع استجابات حدود المعدل.
5. مراقبة الرصيد: يجب أن تحافظ محفظة الكفيل على رصيد كافٍ من SOL لحجم المعاملات المتوقع. قم بتنفيذ تنبيهات آلية وآليات تعبئة لمنع توقف المرحل الناتج عن استنفاد الرصيد.

بالنسبة لبيئة هندسية تعتمد على Python فقط، استخدم عميل Solana Python مصانًا فقط بعد التأكد من أنه يدعم تنسيق المعاملة وتدفق التوقيع المطلوبين. لا يزال المرحل المخصص يتطلب المراقبة، والتعامل مع حدود المعدل، وقوائم انتظار إعادة المحاولة، وضوابط الرصيد، والاختبار، والاستجابة للحوادث.

حالات الاستخدام في العالم الحقيقي: أين يتم نشر المعاملات الخالية من الغاز بالفعل على Solana

المعاملات الخالية من الغاز قيد الإنتاج عبر فئات عديدة من تطبيقات Solana اللامركزية (dApps)، ولكل منها مبرر تجاري متميز لتحمل تكلفة رسوم معاملات المستخدم.

منصات صك NFT هي إحدى حالات الاستخدام الخالية من الغاز. عندما ترعى المنصَّة رسوم الشبكة، يمكن لمحفظة متوافقة توقيع معاملة الصك دون دفع تلك الرسوم بعملة SOL. قد يظل الصك الخالي من الغاز يتضمن سعر صك، أو سياسة رسوم أولوية، أو رسوم منصَّة، أو حقوق ملكية، أو تكلفة لاحقة متعلقة بالحساب، لذا يجب على المستخدمين فحص المعاملة والسعر بالكامل.

تواجه بروتوكولات DeFi مشكلة هيكلية في الانضمام يحلها رعاية الرسوم مباشرة. لا يمكن للمستخدمين الذين يصلون ومعهم USDC أو رمز مميز آخر غير SOL بدء أي تبادل أو تخزين أو إيداع دون الحصول أولًا على SOL لدفع رسوم المعاملة. يؤدي هذا إلى تبعية دائرية: أنت بحاجة إلى SOL للتفاعل مع بروتوكول يمكن أن يمنحك SOL، ولكن لا يمكنك التفاعل دون امتلاك SOL أولًا. إن رعاية أول معاملة إلى ثلاث معاملات للمستخدمين الجدد يزيل هذا العائق. تطبق جميع البورصات اللامركزية (DEXes) وتدفقات الوصول إلى الجسور عبر السلاسل ومنصات الإقراض هذا النمط. بعد فترة الرعاية، يمكن للمستخدمين الذين تلقوا SOL من خلال التبادل دفع رسومهم الخاصة في المعاملات اللاحقة.

تولد ألعاب الويب 3 (Web3 gaming) وتيرة معاملات عالية، مما يجعل رعاية الرسوم جذابة اقتصاديًا للاستوديوهات. كل إجراء داخل اللعبة يلمس السلسلة (شراء عنصر، صك إنجاز، تحديث لوحة الصدارة) سيعرض مطالبة محفظة وخصم رسوم بدون رعاية. عند الرسوم الأساسية لـ Solana، تبلغ تكلفة رعاية 1000 معاملة داخل اللعبة حوالي 0.005 SOL. يستوعب استوديو الألعاب هذا كلفة تشغيلية، مماثلة للبنية التحتية للخادم، والنتيجة هي تجربة لاعب تتصرف مثل لعبة Web2 قياسية بدلاً من تطبيق بلوكتشين.

يمتد انضمام تطبيقات dApp للمستهلكين بهذا النموذج إلى أي تطبيق. يمكن لتطبيق Solana dApp رعاية أول N معاملة للمستخدم لخفض حاجز الإجراء الأول داخل الكتلة، ثم نقل المستخدمين إلى الدفع الذاتي بعد حصولهم على SOL. يوفر Solana Pay (بروتوكول الدفع المفتوح من Solana) نموذجًا ذا صلة لسياقات التجار: يمكن للتاجر التصرف كدافع للرسوم، مما يسمح للعملاء ببدء المدفوعات دون امتلاك SOL للرسوم.

هل أحتاج إلى SOL لاستخدام هذه التطبيقات؟ لا، طالما أن المنصَّة ترعى رسوم المعاملات بنشاط. إن تجربة "خالية من الغاز" هي قرار منتج من قبل كل تطبيق dApp، وليست ضمانًا من الشبكة. تحقق دائمًا من سياسة الرسوم الحالية للمنصة قبل افتراض أن الرسوم مدعومة. قد تكون برامج الرعاية محدودة الوقت، أو محددة الحجم، أو مقتصرة على إجراءات معينة.

يعد السلوك الخالي من الغاز ميزة أساسية لتطبيق dApp والمرحل، ولكن توافق المحفظة ودعم تنسيق المعاملات لا يزالان يتطلبان الاختبار. Phantom وSolflare وBackpack هي أمثلة من المصدر وليست تزكيات. يوقع المستخدم على تعليمات المعاملة، بينما يصرح الكفيل بدفع الرسوم.

تكلفة رعاية المعاملات: ما هي التكلفة الفعلية للمعاملات الخالية من الغاز على المطورين؟

ينمذج المصدر رسومًا أساسية قدرها 5000 لامبورت (lamport) لكل توقيع باستخدام وثائق رسوم معاملات Solana. تعامل مع هذا كمدخل للتحقق منه، وليس كسعر دائم. تعتمد التكلفة الإجمالية للرعاية أيضًا على عدد التوقيعات، ورسوم الأولوية، وإعادات المحاولة، وإنشاء الحساب، ورسوم المزود، والبنية التحتية، وسعر SOL.

تقديرات التكلفة أدناه هي للتوضيح وتستند إلى بيانات الرسوم المتاحة للجمهور. لا يشكل هذا المحتوى نصيحة مالية. سعر SOL متقلب؛ وستختلف تكاليف الدولار الأمريكي الفعلية.

واحد SOL يساوي 1,000,000,000 لامبورت. الرسوم الأساسية البالغة 5000 لامبورت لكل توقيع هي الحد الأدنى للشبكة. رسوم الأولوية اختيارية ويتحكم فيها الكفيل.

رسوم الأولوية هي تعليمات اختيارية computeUnitPrice تنقل المعاملة إلى مقدمة قائمة الانتظار خلال فترات ضغط الشبكة. إضافة رسوم الأولوية تزيد من تكلفة المعاملة الواحدة وتدخل التباين. ضع ميزانية مع هامش احتياطي إذا كان تطبيقك يدعم المعاملات خلال فترات الازدحام.

تكاليف الخدمة المُدارة تضيف طبقة فوق رسوم شبكة Solana. عند استخدام Helius أو مُرحّل مُدار آخر، يدفع المطور كلاً من رسوم Solana الأساسية ورسوم اشتراك API أو رسوم خدمة لكل معاملة الخاصة بالمزود. استشر وثائق التسعير الحالية لكل مزود لمعرفة التفاصيل.

الجدول هو توضيح باستخدام الرسوم الأساسية المفترضة وسعر SOL المصدر. تعتمد التكلفة الفعلية على التواقيع، ورسوم الأولوية، والمعاملات الفاشلة أو المعاد محاولتها، وإنشاء الحسابات، وتسعير المزود، والبنية التحتية، و سعر العملة الرقمية. يجب على الفرق إجراء قياسات لأحمال العمل الخاصة بهم بدلاً من استقراء تكلفة مضمونة من الجدول.

لاختيار بين الخدمات المُدارة والمُرحّلات المخصصة بناءً على التكلفة والعوامل التشغيلية، راجع قسم النهج الصحيح.

اعتبارات الأمان: ما يحتاج المطورون لمعرفته حول مخاطر المُرحّلات

تُدخل المعاملات عديمة الغاز مسؤوليات أمنية على المطورين ومشغلي البنية التحتية والمستخدمين. يخول توقيع المستخدم تعليمات المعاملة التي يقدمها المحفظة؛ رعاية الرسوم لا تجعل التعليمات الضارة أو المضللة آمنة.

سلامة المستخدم: يجب ألا يتطلب تدفق رعاية الرسوم المشروع مشاركة مفتاح سري، ولكن لا يزال المستخدمون بحاجة إلى التحقق من النطاق، ومطالبة المحفظة، ومعرفات البرنامج، وموافقات الرموز، والحسابات، والمبالغ. يمكن لتطبيق خبيث أن يطلب من المستخدم توقيع تعليمات ضارة حتى عندما يقوم حساب آخر بدفع رسوم الشبكة.

تؤثر المخاطر أدناه على المطورين والمشغلين، بينما تؤثر مخاطر توقيع المعاملات، والتصيد الاحتيالي، والمحافظ، وتفويض الأصول أيضًا على المستخدمين النهائيين.

المخاطر 1: التلاعب بمحتوى المعاملة. يمكن للعميل الخبيث صياغة معاملة تحتوي على تعليمات ضارة وتقديمها إلى المُرحّل، على أمل أن يقوم المُرحّل بالتوقيع دون فحص المحتويات. التخفيف: يجب على المُرحّل فك تسلسل والتحقق من صحة المعاملة قبل التوقيع. تحقق من معرفات البرنامج، وبيانات التعليمات، وقوائم الحسابات مقابل قائمة مسموح بها بالقيم المتوقعة. وقّع فقط المعاملات التي تطابق البنية المتوقعة لتطبيقك.

المخاطر 2: هجمات إعادة التشغيل. آلية recentBlockhash الخاصة بـ Solana تمنع هجمات إعادة التشغيل بشكل أصلي. تنتهي صلاحية هاش الكتلة بعد حوالي 150 فتحة (حوالي 60 إلى 90 ثانية)، ويتم رفض أي معاملة يتم تقديمها بعد انتهاء صلاحية الهاش الخاص بها من قبل الشبكة. لا ينبغي للمُرحّلات إعادة توقيع المعاملات ذات الهاشات منتهية الصلاحية. بالنسبة للتدفقات التي لا يمكن فيها تجنب تأخيرات الإرسال، قم بتنفيذ Nonces دائمة باستخدام ميزة nonceAccount الخاصة بـ Solana؛ راجع وثائق Nonce الدائمة لـ Solana.

المخاطر 3: رفض الخدمة من المُرحّل. إذا واجه مُرحّل مُدار طرف ثالث تعطلاً، فلا يمكن للمستخدمين تقديم المعاملات المدعومة حتى لو كانوا على استعداد لدفع الرسوم بأنفسهم. التخفيف: قم بتنفيذ مسار احتياطي في الواجهة الأمامية يقوم بإنشاء معاملة قياسية (يدفعها المستخدم) عندما يكون نقطة نهاية المُرحّل غير متاحة. هذا يحافظ على الوظائف أثناء الانقطاعات.

المخاطر 4: استنزاف محفظة الراعي. بدون تحديد معدل، يمكن للمهاجم إنشاء كميات كبيرة من المعاملات التي تبدو صالحة لاستنزاف الرصيد الخاص بالراعي من SOL. التخفيف: فرض حدود للمعدل لكل عنوان محفظة، ولكل عنوان IP، ولكل نافذة زمنية. قم بتعيين حد إنفاق يومي. قم بتنفيذ قاطع دائرة يقوم بإيقاف الرعاية تلقائيًا عند تجاوز الحجم لحد معين. مراقبة الرصيد الخاص بمحفظة الراعي مع تنبيهات آلية ومشغلات إعادة التعبئة.

المخاطر 5: الاستباق (Front-running) و MEV. يقوم المُرحّل ببث المعاملة وله رؤية لمحتوياتها قبل التأكيد داخل الكتلة. بالنسبة لتطبيقات DeFi التي تتضمن مبادلات أو المراجحة، يمكن للمُرحّل الخبيث القيام بالاستباق للمعاملة. التخفيف: استخدم مُرحّلاً مُشغّلاً ذاتيًا لتطبيقات DeFi التي تعالج المعاملات المالية الحساسة. قم بتقييم سمعة وشفافية تشغيل أي مزود طرف ثالث قبل دمجه في منتج DeFi.

للسياق التنظيمي: في ولايات قضائية معينة، قد يكون لرعاية معاملات المستخدم آثار على الوضع التنظيمي لتطبيق لامركزي، لا سيما إذا تم تصنيف الرسوم المدعومة على أنها تحويل قيمة. هذه ليست نصيحة قانونية؛ استشر المستشار لتحليل خاص بالولاية القضائية.

طبقة التحقق في دليل التنفيذ تصف المكان الذي يتم فيه تطبيق هذه التخفيفات في بنية المُرحّل.

قائمة تدقيق الأمان لتنفيذ المُرحّل

• التحقق من محتويات المعاملة وفك تسلسلها قبل التوقيع
• لا تعيد أبدًا توقيع المعاملات ذات الهاشات منتهية الصلاحية
• قم بتنفيذ مسار احتياطي يدفعها المستخدم في حالة تعطل المُرحّل
• فرض حدود للمعدل لكل محفظة، ولكل IP، ولكل نافذة زمنية مع حد إنفاق يومي
• استخدم مُرحّلاً مُشغّلاً ذاتيًا أو موثوقًا به لتطبيقات DeFi التي تتعامل مع معاملات حساسة

اختيار النهج الصحيح: التنفيذ الأصلي مقابل الخدمة المُدارة

يعتمد الاختيار بين التنفيذ الأصلي feePayer، وخدمة المُرحّل المُدارة، والمُرحّل المبني خصيصًا على أربعة عوامل: الجدول الزمني للتطوير، وحجم المعاملات، ومتطلبات الأمان، والميزانية للنفقات التشغيلية المستمرة.

لا يوجد حد عالمي لحجم المعاملات لاختيار خدمة مُدارة. قارن بين استبقاء المفاتيح، وضوابط التحقق، والتوافر، والخصوصية، والامتثال، وإقامة البيانات، والتسعير، وقابلية النقل، والاستجابة للحوادث قبل اختيار نهج.

قم ببناء مُرحّل مخصص عندما يتطلب تطبيقك منطق أهلية مخصص (على سبيل المثال، رعاية أول خمس معاملات فقط لكل مستخدم، أو تقييد الرعاية لأنواع تعليمات محددة)، عندما يبرر حجم المعاملات ومتطلبات الأمان الاستثمار التشغيلي، أو عندما تمنع متطلبات إقامة البيانات استخدام مزود طرف ثالث.

نهج feePayer الأصلي بدون خادم مُرحّل مخصص يناسب التطبيقات البسيطة ذات الواجهة الخلفية الموثوقة وحجم المعاملات المتوقع المنخفض.

يجب على الفرق التي تستخدم خدمة مُدارة الحفاظ على القدرة على الهجرة إلى مُرحّل مُشغّل ذاتيًا إذا قام المزود بتغيير التسعير أو إيقاف الخدمة. وثّق نقاط التكامل بحيث تكون الهجرة تغييرًا في التكوين، وليس إعادة كتابة.

لنمذجة تكلفة كل خيار، راجع قسم تحليل التكلفة.

أسئلة متكررة حول المعاملات عديمة الغاز على Solana

ما هي المعاملات عديمة الغاز في العملات الرقمية؟

المعاملات بدون غاز في العملات الرقمية هي معاملات بلوكتشين لا يدفع فيها المستخدم النهائي أي رسوم شبكة. يقوم طرف ثالث، مثل مطور تطبيق لامركزي dApp أو بروتوكول أو خدمة مُرحّل، بتغطية الرسوم نيابة عن المستخدم. نشأ المصطلح في نظام Ethereum البيئي، حيث تسمى رسوم المعاملات "gas"، وانتشر منذ ذلك الحين عبر الشبكات بما في ذلك Solana كمصطلح عام لتجارب المستخدم التي ترعاها الرسوم.

هل تفرض Solana رسوم غاز؟

تستخدم Solana رسوم معاملات بدلاً من مصطلح "gas". ويشير المصدر إلى الرسوم الأساسية البالغة 5,000 لامبورت (lamport) لكل توقيع، ولكن يجب التحقق من المعلمات الحالية، كما يمكن أن تشمل التكلفة الإجمالية توقيعات متعددة ورسوم أولوية اختيارية. تعني عبارة "بدون غاز" (Gasless) أن حساباً آخر يدفع رسوم الشبكة المعمول بها.

كيف يعمل دافع الرسوم على Solana؟

دافع الرسوم على Solana هو الحساب المخصص لدفع رسوم المعاملة. تحتوي كل معاملة على حقل feePayer في كائن المعاملة. في المعاملة القياسية، يكون دافع الرسوم وموقع المعاملة هما نفس الحساب. أما في المعاملة بدون غاز، فهما حسابان مختلفان: توقع محفظة المستخدم لتفويض التعليمات، ويقوم حساب دافع رسوم منفصل (يتحكم فيه التطبيق اللامركزي dApp) بالتوقيع لتفويض ودفع الرسوم. يتم خصم الرصيد من SOL الخاص بـ دافع الرسوم فقط.

من يدفع مقابل المعاملات بدون غاز على Solana؟

يدفع مطور التطبيق اللامركزي dApp، أو خزينة البروتوكول، أو خدمة مُرحّل (relayer) مدارة مقابل المعاملات بدون غاز على Solana. تقوم هذه الكيانات بتمويل حساب دافع الرسوم بعملة SOL وتشغيل مُرحّل يوقع المعاملات نيابة عن المستخدمين. من منظور تجاري، يُعد هذا رعاية للمعاملات: يعامل التطبيق اللامركزي الرسوم كتكلفة لاكتساب المستخدمين. راجع جدول "من يدفع" في قسم المفاهيم الخاطئة للحصول على تفصيل دقيق.

لا يمكن إجراء أي معاملة على Solana دون دفع رسوم للمصادقين. الرسوم هي متطلب بروتوكول. ما هو ممكن هو أن يقوم طرف آخر غير المرسل بدفع الرسوم. المعاملة بدون غاز لا تزال تتضمن رسوماً؛ ولكن المستخدم ببساطة ليس هو من يدفعها. التشبيه: يمكن للمطعم أن يقدم لك وجبة مجانية، ولكن الطعام لا يزال له تكلفة.

ما هي رعاية رسوم المعاملات؟

رعاية رسوم المعاملات هي ممارسة يقوم بها مطور تطبيق لامركزي dApp أو بروتوكول أو خدمة لتغطية رسوم معاملات الشبكة نيابة عن المستخدم النهائي، مما يتيح للمستخدم التفاعل مع Solana دون حيازة SOL لدفع الرسوم. إنها الآلية التي تجعل تجارب المستخدم بدون غاز ممكنة. من منظور المنتج، عادةً ما تُعامل رعاية الرسوم كتكلفة اكتساب مستخدم، على غرار عرض "فريميوم" (freemium) أو التنازل عن رسوم التسجيل.

كيف أقوم ببناء تطبيق لامركزي dApp بدون غاز على Solana؟

لبناء تطبيق لامركزي بدون غاز على Solana: (1) قم بإنشاء زوج مفاتيح لدافع الرسوم يتم الاحتفاظ به من جانب الخادم، وممول بعملة SOL؛ (2) قم بإنشاء معاملات مع تعيين transaction.feePayer إلى المفتاح العمومي لدافع الرسوم؛ (3) اجعل المستخدمين يوقعون المعاملات عبر محافظهم؛ (4) أرسل المعاملة الموقعة جزئياً إلى خادم المُرحّل الخاص بك؛ (5) اجعل المُرحّل يتحقق من محتويات المعاملة، ويضيف توقيع دافع الرسوم، ويرسلها إلى الشبكة. راجع دليل التنفيذ للحصول على التفاصيل الفنية الكاملة عبر مناهج التنفيذ الثلاثة.

ما الفرق بين رسوم Solana و غاز Ethereum؟

تستخدم Ethereum وSolana هياكل رسوم ورعاية مختلفة. توفر Solana حقلاً أصلياً لدافع الرسوم وقد تستخدم أيضاً رسوم الأولوية؛ بينما تدعم Ethereum تصميمات تجريد الحساب والمعاملات الوصفية (meta-transactions) بمكونات مختلفة. قارن بين أعباء العمل المتكافئة، وسياسات التأكيد، وتكاليف المزود، وضوابط الأمان بدلاً من الاعتماد على رقم رسوم ثابت واحد.

هل يمكنني صك NFT على Solana مجاناً؟

نعم، تقوم العديد من منصات NFT على Solana برعاية رسوم معاملات الصك، مما يعني أن المستخدمين لا يدفعون شيئاً مقابل رسوم الشبكة. ومع ذلك، فإن "الصك المجاني" و"الصك بدون غاز" ليسا متطابقين. الصك المجاني يعني عدم وجود رسوم معاملات ولا سعر صك. أما الصك بدون غاز فيعني أن رسوم المعاملة ترعاها جهة ما، ولكن قد يظل سعر الصك سارياً. يشير وصف "بدون غاز" تحديداً إلى رعاية رسوم الشبكة، وليس إلى ما إذا كان للـ NFT نفسه سعر شراء.

ما هي المحافظ التي تدعم المعاملات بدون غاز على Solana؟

يتم تنفيذ السلوك الخالي من الغاز بشكل أساسي من قبل التطبيق اللامركزي dApp والمُرحّل، ولكن لا يزال توافق المحفظة ودعم تنسيق المعاملات بحاجة إلى اختبار. قد يغطي الراعي رسوم الشبكة حتى وإن كانت التعليمات الموقعة يمكن أن تنقل أصول المستخدم أو تسبب تكاليف أخرى.

هل المعاملات بدون غاز على Solana آمنة؟

يمكن تنفيذها بأمان، لكن الرعاية ليست ضماناً للأمان. يجب على المستخدمين التحقق من التطبيق اللامركزي والتعليمات الموقعة، بينما يجب على المطورين التحقق من المعاملات، وحماية مفاتيح الراعي، والحد من سوء الاستخدام، ومراقبة المُرحّلين، وتوفير معالجة للأعطال. يجب ألا تطلب أي خدمة مشروعة أبداً المفتاح السري للمستخدم.

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

أدلة اقتصاديات شبكة Solana ذات الصلة

• كيف تحقق Solana الإيرادات
• نمو سوق العملات الرقمية المستقرة على Solana

استكشف SOL على Bybit

يمكن للقراء مراجعة معلومات سوق SOL الحالية أو سوق التداول الفوري SOL/USDT.. التوفر لا يعني المصادقة على بروتوكول أو عملة رقمية مُستقرَّة أو مُرحّل أو برنامج إعادة شراء أو أطروحة استثمارية.

ملخص: ما تحتاج لمعرفته حول المعاملات بدون غاز على Solana

تمنح المعاملات بدون غاز على Solana المستخدمين النهائيين تجربة خالية من الرسوم عن طريق نقل دفع الرسوم إلى حساب دافع رسوم مخصص، وهو حقل أساسي في نموذج المعاملات الأصلي لـ Solana.

النقاط الرئيسية:

• حقل feePayer مدمج في هيكل معاملات Solana الأساسي. لا يلزم وجود برامج أو عقود إضافية لرعاية الرسوم.
• الرسوم موجودة دائماً وتذهب دائماً إلى المصادقين. مصطلح "بدون غاز" يعني أن المستخدم ليس هو من يدفعها، وليس عدم وجود رسوم.
• تمت مناقشة ثلاثة مسارات للتنفيذ: تدفق دافع الرسوم الأصلي باستخدام SDK معتمد، وخدمة مُرحّل مدارة، ومُرحّل مبني خصيصاً. لكل منها مقايضات مختلفة فيما يخص الأمان والتوفر والتكلفة والتحكم.
• مسؤولية الأمان مشتركة: يراجع المستخدمون ما يوقعون عليه، بينما يتحقق المطورون من محتويات المعاملة، ويحمون مفاتيح الراعي، ويحدون من سوء الاستخدام، ويراقبون توفر المُرحّل.
• يشير توضيح الرسوم الأساسية للمصدر إلى أن الرعاية يمكن أن تكون غير مكلفة، ولكن اقتصاديات الإنتاج تتطلب مراعاة الرسوم الحالية، وإعدادات الأولوية، ومعدلات الفشل، ورسوم المزود، واختبار أعباء العمل المتكافئة.

الخطوات التالية حسب الجمهور:

للمستخدمين: ابحث عن تأكيد صريح بأن التطبيق اللامركزي dApp يرعى الرسوم قبل افتراض أن الرصيد الخاص بك من SOL لن يُمَس. يمكنك المشاركة دون شراء SOL أولاً عندما تكون الرعاية نشطة، ولكن تحقق دائماً من السياسة الحالية لكل منصَّة.

للمطورين: قارن بين نموذج دافع الرسوم الأصلي، والعديد من المزودين المدارين، والمُرحّل الذي يتم تشغيله ذاتياً. تحقق من الوثائق الحالية، وافتراضات الأمان، وشروط الخدمة، والتكاليف قبل اختيار طريقة التنفيذ.

لمخططي المنتجات: قم بنمذجة تكلفة الرعاية الخاصة بك باستخدام الصيغة الموجودة في قسم تحليل التكلفة وقم بتقييم مناهج التنفيذ باستخدام جدول القرار في قسم المنهج الصحيح.

مع نضج التطبيقات اللامركزية الموجهة للمستهلكين على Solana، أصبحت رعاية الرسوم نمطاً قياسياً لتهيئة المستخدمين الجدد. كانت البنية التحتية لدعم ذلك جزءاً من بروتوكول Solana منذ اليوم الأول.