ادفع مقابل الدومينات بمحفظة كريبتو: من غير ما تحتاج حساب

كل كلام من نوع «وكيل ذكاء اصطناعي يقدر يشتري لك دومين» بيصطدم في النهاية بنفس الحائط: إزاي الوكيل يدفع فعلًا؟ بطاقة الائتمان بتفترض وجود إنسان يكتب الأرقام في نموذج، ويعدّي فحص احتيال، ويؤكد رمزًا لمرة واحدة اتبعت للموبايل. وكيل الذكاء الاصطناعي ما عندوش أي من ده. إجابة Namefi هي مسار إتمام دفع لا يحتاج بطاقة، ولا وسيلة دفع محفوظة، ولا حتى حساب Namefi: كل المطلوب محفظة كريبتو توقّع الدفع في لحظته. المقال ده بيفصّل إزاي التدفق ده بيشتغل فعلًا، وإيه اللي مخطط التوقيع بيسمح للوكيل يعمله وما بيسمحلوش، وإمتى تستخدم فوترة مفتاح API بدلًا منه.

ليه الدفع هو أصعب جزء في تجارة الوكلاء

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

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

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

إجابة Namefi: إتمام دفع بتوقيع المحفظة، من غير إنشاء حساب

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

مسار توقيع المحفظة بيتخطى كل ده. وفقًا لوثائق Namefi المنشورة والقابلة للقراءة آليًا لمدفوعات المحافظ، محفظة الوكيل تقدر تدفع مباشرة بـ USDC من غير حساب Namefi أو مفتاح API محفوظ في أي مكان: محفظة المشتري توقّع تفويض دفع، ويُسوّى التسجيل أول ما يوصل التوقيع. مفيش حاجة تنشئها مقدمًا، ومفيش تفويض دائم ممكن يُساء استخدامه لاحقًا؛ المحفظة لا تتصرف إلا في لحظة توقيعها.

Namefi بتوثّق ثلاث طرق تنتج بها المحفظة التوقيع ده، ومشروحة خطوة بخطوة تحت: بروتوكول x402 (المسار الأساسي، واللي الدليل ده مركز عليه)، ونسخة تحدي-واستجابة من Machine Payable Protocol (MPP)، ومسار توقيع EIP-712 يدوي للمحافظ اللي لا تستخدم أيًا من الاختصارين.

تدفق x402، خطوة بخطوة

x402 معيار مفتوح تدعمه شركات منها Cloudflare وAWS وStripe، وبيعيد إحياء رمز الحالة HTTP 402 Payment Required اللي كان مهجورًا لفترة طويلة كطريقة منظّمة لطلب دفعة على السلسلة ضمن طلب عادي، بدل ما يحوّلك لصفحة دفع منفصلة. Namefi بتطبّقه على نقطة نهاية تسجيل الدومينات:

1. طلب من غير دفع. الوكيل يرسل طلب GET عاديًا إلى نقطة نهاية Namefi /x402/domain/{domainName} — من غير دفعة مرفقة، لأنه لسه ما يعرفش السعر.
2. HTTP 402 مع السعر. Namefi ترد بـ 402 Payment Required وتضمّن خيارات الدفع في نص الاستجابة: الشبكة، والأصل المقبول (USDC)، والمبلغ. ده الجزء من x402 اللي بيخلّيه مختلفًا عن خطأ عادي: حالة 402 تحمل كل ما يحتاجه العميل لبناء دفعة صالحة، بدل ما تكتفي بقول «لا».
3. المحفظة توقّع transferWithAuthorization وفق EIP-3009. بدل إرسال معاملة بلوكشين منفصلة وانتظار تأكيدها، المحفظة تنتج توقيعًا وفق EIP-3009، وهو معيار Ethereum مصمم تحديدًا لتحويلات التوكنات المفوّضة بالتوقيع. دالة transferWithAuthorization في EIP-3009 بتسمح لحامل توكن يوقّع رسالة تفوّض تحويل مبلغ محدد إلى مستلم محدد، صالحة فقط ضمن نافذة زمنية محددة (validAfter / validBefore)، ثم يقدر طرف ثالث يرسلها على السلسلة. وثائق Namefi واضحة إن الخطوة دي لا تحتاج حساب Namefi ولا توقيع EIP-712 مقدمًا: المحفظة توقّع تفويض تحويل USDC مستقلًا، وبس.
4. إعادة الطلب مع ترويسة دفع. الوكيل يعيد إرسال الطلب الأصلي، المرة دي مع ترويسة X-PAYMENT اللي تحمل التفويض الموقّع.
5. تحقق، تسوية، تسجيل. Namefi تتحقق من التوقيع، وتبدأ سير عمل تسجيل الدومين، وتسوّي الدفع — USDC ينتقل من محفظة المشتري، والتسجيل يكمل بنفس الطريقة اللي كان هيكمل بها عبر مسار مفتاح API، بما فيها تسجيل الدومين كـ NFT — أي دومين مُرمَّز — للمحفظة الدافعة نفسها افتراضيًا.

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

نسخة تحدي-واستجابة MPP

x402 هو المسار الأساسي، لكن Namefi بتوثّق كمان مسارًا ثانيًا للمحافظ أو أطر الوكلاء اللي بتتكلم بنمط دفع مختلف: Machine Payable Protocol (MPP). من ناحية البنية، هو صورة معكوسة من x402 — تحدي واستجابة بدل 402 مباشر:

1. أول طلب إلى نقطة النهاية المحمية يرجع مرة أخرى بـ 402 Payment Required، لكن المرة دي يحمل تحديًا موقّعًا بدل عرض سعر عادي.
2. العميل (غالبًا عبر أداة سطر الأوامر mppx من Namefi، المصممة تحديدًا للتعامل مع خطوة التوقيع) يوقّع التحدي ده بالمحفظة الدافعة.
3. العميل يعيد الطلب الأصلي مع التوقيع الناتج مرفقًا في ترويسة Authorization.

الأثر النهائي هو نفسه في x402 — دفعة موقّعة من المحفظة لكل طلب، من غير بيانات اعتماد محفوظة — لكن معبأة في مصافحة تحدٍ موقّع بدل استجابة سعر في 402 مباشرة. اختيار الوكيل لأيهما بيتحدد بأدوات الدفع اللي بيعرفها أصلًا؛ نقطة نهاية Namefi تفهم الاثنين.

مسار EIP-712 اليدوي

للمحافظ أو السكربتات اللي لا تستخدم أيًا من الاختصارين، Namefi بتوفّر مسار توقيع منخفض المستوى ويدوي بالكامل مبني على توقيع البيانات المُنمَّطة EIP-712، وهو نفس المعيار اللي EIP-3009 نفسه مبني عليه. الطلب الموقّع بالطريقة دي يحمل ثلاث ترويسات — x-namefi-signer (عنوان المحفظة الموقّعة)، وx-namefi-signature (التوقيع المشفّر سداسيًا)، وx-namefi-eip712-type (مخطط البيانات المُنمَّطة اللي أُنتج التوقيع بناءً عليه) — ويلفّ الحمولة في غلاف فيه payloadType، وpayload نفسها، وtimestamp، وnonce.

تفصيلان مهمان لأمان المسار اليدوي ده: التوقيعات تنتهي بعد 300 ثانية، وكل nonce يستخدم مرة واحدة. بعد مرور 300 ثانية، أو بمجرد قبول طلب استخدم الـ nonce، ما ينفعش إعادة استخدام توقيع تم التقاطه. وثائق Namefi كمان بتحدد إن تعريفات النوع EIP-712 الحية لازم تتجلب من نقاط النهاية /v-next/eip712/ وقت الطلب بدل ما يضمّنها التكامل ثابتةً في الكود، لأن المخطط الدقيق اللي لازم يطابقه التوقيع ممكن يتغير.

Namefi بتوثق كذلك توقيع محفظة العقود الذكية بهذه الطريقة: حساب خارجي مملوك (EOA) وموافق عليه يقدر يوقّع نيابة عن محفظة عقد بموجب ERC-1271، أو EIP-7702 الأحدث، بشرط إن العقد يطبق فحص approvedSigners(address) اللي تقدر API تتحقق منه.

نموذج الأمان: ما الذي يقدر الوكيل يعمله وما لا يقدرش يعمله

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

ما الذي يقيّده. كل مسار بيتطلب من المحفظة توقيع الطلب الحالي بدل ما تسلّم Namefi بيانات اعتماد دائمة. ضوابط منع إعادة الاستخدام تختلف حسب البروتوكول: توقيع المسار اليدوي EIP-712 تنتهي صلاحيته بعد 300 ثانية ويستهلك nonce للاستخدام مرة واحدة؛ وx402 يستخدم تفويض EIP-3009 مرتبطًا بمبلغ ومستلم محددين، ومحكومًا بـ validAfter/validBefore ومحميًا بـ nonce؛ وعميل MPP يوقّع التحدي الصادر من الخادم، وبالتالي شروط انتهاء الصلاحية ومنع إعادة الاستخدام هي الشروط اللي يحددها التحدي نفسه. المحفظة لا تعطي Namefi أبدًا سلطة دائمة لبدء خصومات مستقبلية من تلقاء نفسها. قارن ده ببطاقة محفوظة: أول ما تاجر يكون عنده رمز بطاقتك، مفيش حاجة في الرمز نفسه تحدد اللي يخصمه الشهر الجاي، أو تمنع نظامًا مخترقًا من إعادة استخدامه. المفتاح الخاص للمحفظة لا يغادر المحفظة في أي من التدفقات دي — الوكيل يطلب من المحفظة توقّع طلبًا واحدًا محددًا، وده كامل نطاق ما يحدث.

ما الذي لا يقيّده وحده. وثائق Namefi لا تصف سقفًا مدمجًا للإنفاق بالدولار لكل معاملة يطبقه البروتوكول نفسه — ضوابط انتهاء الصلاحية ومنع إعادة الاستخدام الخاصة بكل بروتوكول تحدد إمتى وإزاي يمكن إعادة استخدام التفويض، مش الحد الأقصى للمبلغ اللي يقدر طلب موقّع واحد يفوّضه. عمليًا، انضباط الإنفاق الفعلي للوكيل يأتي من خارج الآلية دي: مقدار USDC اللي بتموّل به المحفظة، وأي طبقة سياسة — مثل محفظة توقيع متعدد (Multi-sig) تتطلب موافقة ثانية، أو خطوة تأكيد بشري قبل ما يُسمح للوكيل يوقّع أصلًا — تحطها بين الوكيل والمفتاح الخاص للمحفظة. ما هو مسجّل الدومينات المولود لعصر الوكلاء؟ وإزاي تسجّل دومين بوكيل الذكاء الاصطناعي بتاعك على Namefi بيغطوا النقطة نفسها من جانب الضوابط: موّل المحفظة فقط بالمبلغ اللي مرتاح إن عملية بلا مراقبة تنفقه، وقرر مقدمًا أين يحتاج إنسان إلى الموافقة.

التركيبة دي — لا بيانات اعتماد دائمة، وتفويض محدود لكل معاملة، والتمويل هو حد الإنفاق العملي — تجعل شكل المخاطر مختلفًا فعلًا عن بطاقة محفوظة، وليس مجرد نسخة بنكهة كريبتو من نفس الشيء. رقم بطاقة مسرّب أو رمز فوترة مخترق ممكن يُخصم منه مرارًا لحد ما حد يلاحظ ويلغيه. تفويض الدفع اللي تم التقاطه يُرفض لما يتحقق شرط انتهاء الصلاحية أو منع إعادة الاستخدام الخاص ببروتوكوله: المسار اليدوي EIP-712 يرفضه بعد 300 ثانية أو بمجرد استهلاك الـ nonce؛ وتفويض EIP-3009 في x402 يُرفض خارج validAfter/validBefore أو بعد استخدام الـ nonce؛ وتفويض MPP يخضع لشروط انتهاء الصلاحية ومنع إعادة الاستخدام المضمّنة في التحدي الموقّع الخاص به.

إمتى تستخدم فوترة مفتاح API أو NFSC بدلًا منها

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

فوترة مفتاح API مقابل رصيد NFSC ممول، كما هو مفصّل في إزاي تسجّل دومين بوكيل الذكاء الاصطناعي بتاعك على Namefi، تكون أرجح لما الوكيل يسجل دومينات بشكل متكرر ويكون وجود رصيد دائم يمكن فحصه أفضل من توقيع دفعة جديدة كل مرة؛ أو لما يريد المشغّل رؤية موحدة للإنفاق في لوحة تحكم واحدة بدل إعادة بنائه من تحويلات على السلسلة؛ أو لما يكون لدى العميل طريقة نظيفة لحفظ قيمة ترويسة لكن لا توجد طريقة سهلة لحيازة مفتاح خاص والتوقيع به. المساران يقودان لعمليات التسجيل وDNS نفسها بعد تسوية الدفع — الاختيار عن كيفية عمل التفويض، مش عن اللي تقدر تسجله أو تديره بعدها.

الأسئلة الشائعة

هل أحتاج حساب Namefi كي أدفع بمحفظة كريبتو؟

لا. تدفقات x402 وMPP تسوّي تسجيل دومين من دفعة محفظة موقّعة من غير حساب Namefi ومن غير مفتاح API مُنشأ مقدمًا. مفتاح API مطلوب فقط لمسار الفوترة برصيد NFSC.

ما العملة المشفرة التي تقبلها Namefi في إتمام الدفع بالمحفظة؟

USDC. نقطة نهاية x402 في Namefi تسعّر وتسوّي الدفع بـ USDC تحديدًا، وده يتجنب تقلبات السعر اللي أصل متذبذب مثل ETH كان سيدخلها بين لحظة عرض السعر ولحظة تسوية الدفع.

هل توقيع دفعة من المحفظة هو نفسه إعطاء الوكيل مفتاحي الخاص؟

لا — التوقيع تنتجه المحفظة من غير ما تكشف المفتاح الخاص نفسه في أي وقت. الوكيل (أو الأداة اللي بيستدعيها) يطلب من المحفظة توقيع تفويض محدد ومحدود؛ والمفتاح يفضل داخل المحفظة طوال الوقت.

هل يمكن لشخص إعادة استخدام توقيع دفع أنشأته سابقًا؟

قد يظل التوقيع اللي تم التقاطه صالحًا للاستخدام لحد ما يرفضه شرط انتهاء الصلاحية أو منع إعادة الاستخدام الخاص به؛ والمسارات الثلاثة مش بتشارك قاعدة موحدة. في المسار اليدوي EIP-712، التوقيعات تنتهي بعد 300 ثانية وكل nonce يمكن استخدامه مرة واحدة فقط. تفويض EIP-3009 في تدفق x402 صالح فقط داخل نافذة validAfter/validBefore، والـ nonce الخاص به لا يمكن استخدامه مرتين. MPP يستخدم تحديًا موقّعًا، وبالتالي لازم تتراجع شروط انتهاء الصلاحية ومنع إعادة الاستخدام في التحدي نفسه بدل افتراض إنها مطابقة لأي من المسارين الآخرين.

هل يصبح الدومين مُرمَّزًا تلقائيًا عندما أدفع بهذه الطريقة؟

نعم افتراضيًا — يُصك الدومين المسجل باعتباره NFT للمحفظة نفسها التي دفعت، وهو نفس سلوك الترميز الذي يستخدمه مسار مفتاح API ما لم يتم تحديد محفظة استقبال أخرى. راجع Cloudflare مقابل Name.com مقابل Namefi: مسجّلون مولودون لعصر الوكلاء لمعرفة المقارنة بمسجّلين لا يقدمون إتمام دفع أصليًا للمحفظة أو ملكية مُرمَّزة على الإطلاق.

هل إتمام الدفع بالمحفظة أكثر أمانًا من الدفع ببطاقة محفوظة؟

هو يقيّد مجموعة مخاطر مختلفة بدل ما يلغي المخاطر تمامًا. لا توجد بيانات اعتماد دائمة يقدر نظام مخترق يعيد استخدامها إلى أجل غير محدد، وكل دفعة تتطلب توقيعًا جديدًا خاصًا بالطلب. ضوابط منع إعادة الاستخدام تختلف: المسار اليدوي EIP-712 يستخدم صلاحية مدتها 300 ثانية وnonce للاستخدام مرة واحدة؛ وتفويض EIP-3009 في x402 يستخدم validAfter/validBefore وnonce؛ وMPP يخضع لشروط التحدي الموقّع الخاص به. ولا واحد من الضوابط دي يضع سقفًا للمبلغ اللي يقدر طلب موقّع واحد يفوّضه، ولذلك الحد العملي لما يمكن للوكيل إنفاقه يظل نابعًا من مقدار تمويلك للمحفظة وأي سياسة موافقة إضافية (مثل توقيع متعدد) تضعها أمامه.

اشترِ دومينًا بمحفظة على Namefi

لو الهدف من استخدام وكيل هو ألا يقف حساب بشري بين الوكيل والشراء، فإتمام الدفع بتوقيع المحفظة في Namefi مصمم لهذا بالضبط: تسجيل دومين حقيقي معتمد من ICANN، مدفوع بتفويض USDC واحد موقّع، مع وصول الملكية المُرمَّزة إلى نفس المحفظة التي دفعت. راجع الآليات الكاملة في namefi.io/web3/llms.txt، أو ابدأ بالإعداد الأوسع في إزاي تسجّل دومين بوكيل الذكاء الاصطناعي بتاعك على Namefi.

ابحث عن دومين وسجّله على Namefi.

المصادر وقراءة إضافية

• Namefi — namefi.io/web3/llms.txt (المصدر الأساسي لتدفق x402، ونسخة تحدي-واستجابة MPP، ومسار التوقيع اليدوي EIP-712، وقواعد انتهاء التوقيع/nonce، وتوقيع محفظة العقود الذكية ERC-1271/EIP-7702)
• Namefi — namefi.io/llms.txt (مسار فوترة NFSC/مفتاح API، والإشارة إلى مرجع دفع المحفظة السابق)
• x402.org — x402: معيار دفع أصلي للإنترنت (بروتوكول الدفع المفتوح القائم على HTTP 402 الذي ينفّذه تدفق Namefi)
• Ethereum — EIP-3009: Transfer With Authorization (معيار التوقيع وراء خطوة transferWithAuthorization؛ تحديد الوقت بـ validAfter/validBefore، وnonces عشوائية أحادية الاستخدام)
• Ethereum — EIP-721: معيار التوكن غير القابل للاستبدال (معيار NFT الذي تُبنى عليه ملكية الدومينات المُرمَّزة)
• Namefi — إزاي تسجّل دومين بوكيل الذكاء الاصطناعي بتاعك على Namefi (مسار فوترة مفتاح API/NFSC، وإرشادات الضوابط الأوسع)
• Namefi — Cloudflare مقابل Name.com مقابل Namefi: مسجّلون مولودون لعصر الوكلاء (مقارنة إتمام الدفع الأصلي للمحفظة بين المسجّلين الثلاثة الموجهين للوكلاء)