طوّر على BTX سير عمل آمن للوكلاء

ابنِ واجهات API يجب على الوكلاء أن يثبتوا أنفسهم أمامها.

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

دليل الدمج واجهات RPC للتحديات
مسار الطلب
  1. طلب وكيل موقّع
  2. إصدار غلاف التحدي
  3. حل عمل جديد محلياً
  4. استرداد الإثبات والسماح
الهوية مواد محفظة ما بعد الكم
القبول إثبات عمل جديد
التحقق تحقق رخيص مقارنة بكلفة الحل
السطح RPC + تدفقات البوابة
حالات الاستخدام CAPTCHA للوكلاء الذكيين تدفق التحدي الأنماط الملفات الجاهزية الملاءمة مع البوابة الهوية حزمة البدء المعايير FAQ
لماذا يهم هذا

تحتاج المنتجات الأصلية للذكاء الاصطناعي إلى تحكم في القبول أفضل من صندوق CAPTCHA.

تدفقات التحدي المخصصة للبشر فقط لا تناسب الأنظمة المؤتمتة أو عملاء API أو أدوات المشغل. تتيح لك تحديات خدمة BTX طلب حوسبة جديدة: مكلفة للأتمتة على نطاق واسع، ورخيصة في التحقق، ومرتبطة بظروف السلسلة الحالية.

بوابة للواجهات العامة

اطلب عملاً جديداً قبل أن تسمح النقاط الطرفية المكلفة أو المعرضة للإساءة بمرور الحركة. وهذا أنسب لحركة المرور المجهولة أو المجانية من فرض رسوم مقدماً على كل مستدعٍ.

قبول استدلال الذكاء الاصطناعي

ضع سعراً لضغط الروبوتات وإساءة استخدام الاستدلال عبر صعوبة التحدي بدلاً من الاعتماد فقط على الحصص أو CAPTCHA أو حدود المعدل العمياء.

التحقق من الوكيل إلى الأداة

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

مقاومة الرسائل المزعجة والتسجيلات المسيئة

استخدم تحديات خدمة BTX للتعليقات وإنشاء الحسابات والنماذج العامة حيث تكون تدفقات CAPTCHA المخصصة للبشر فقط تجربة سيئة أو سهلة التعهيد.

CAPTCHA للوكلاء الذكيين

نمط بوابة مصمم للجهات المستدعية المؤتمتة.

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

علّم المسار على أنه قابل للتحدي

عند البوابة، حدِّد مسارات الاستدلال أو التسجيل أو البحث أو الأدوات التي يبرر ملف تكلفتها وإساءتها تسعير عمل جديد قبل التنفيذ.

أصدر غلاف تحدٍ مرتبطاً بالسلسلة

أعد عملاً من BTX مرتبطاً بالغرض والمورد والموضوع بدلاً من إدخال الجهة المستدعية في تدفق CAPTCHA مخصص للبشر فقط.

اطلب الإثبات مع الطلب

يحل العميل أو الوكيل محلياً ثم يرسل الإثبات إلى جانب استدعاء API الأصلي وأي مواد هوية موقعة تطلبها.

استرد قبل بدء الفعل المكلف

يتحقق الخادم من الحداثة وحالة إعادة التشغيل وسياق الصعوبة قبل أن يبدأ تشغيل النموذج أو خطوة سير العمل أو استدعاء الأداة المميّزة.

تدفق التحدي

حلقة عملية للمطورين، لا قصة مستقبلية غامضة.

1

أصدر التحدي

استخدم getmatmulservicechallenge لربط عمل جديد بغرض ومورد وموضوع وهدف زمن للحل.

افتح الوثيقة ذات الصلة
2

دع العميل يحل محلياً

يحسب الطالب إثبات MatMul مرتبطاً بحالة السلسلة الحالية، لذلك تبقى نوافذ ما قبل الحساب محدودة.

افتح الوثيقة ذات الصلة
3

استرد واختبر

اقبل الطلب فقط عندما يؤكد redeemmatmulserviceproof أن الإثبات صالح وحديث ولم يُستهلك من قبل.

افتح الوثيقة ذات الصلة
4

أضف طبقة الهوية

أضف هوية مدعومة بمحفظة BTX ومعايير الطلبات الموقعة عندما يحتاج وكيل أو خدمة إلى هوية تشفيرية دائمة.

افتح الوثيقة ذات الصلة 
# Issue a challenge envelope
curl --silent --user "$BTX_RPC_USER:$BTX_RPC_PASSWORD" \
  --data-binary '{
    "jsonrpc":"1.0",
    "id":"issue",
    "method":"getmatmulservicechallenge",
    "params":["ai_inference_gate","model:gpt-x|route:/v1/generate|tier:free","tenant:abc123",2,300,0.25,0.75]
  }' \
  -H 'content-type: text/plain;' \
  http://127.0.0.1:19334/

# Redeem the returned proof
btx-cli redeemmatmulserviceproof CHALLENGE NONCE DIGEST
مقارنة مكدس القبول

BTX هو طبقة العمل والهوية، وليس كامل مكدس المصادقة.

الخيار العملي ليس بين "استخدم BTX" أو "استخدم المصادقة". بل هو كيف تجمع بين المصادقة العادية وطريقة أصلية للآلة لتسعير الإساءة في المسارات المهمة.

مفاتيح API فقط

الأفضل في: بسيطة للمستخدمين المدفوعين المعروفين ولعملاء الخادم إلى الخادم المستقرين.

الضعف في: ضعيفة أمام الاعتمادات المنسوخة أو الوصول المعاد بيعه أو الإساءة المجهولة على المسارات المكلفة.

ما الذي يقدمه فعلاً: هوية من دون تسعير عمل على مستوى المسار.

CAPTCHA بشري

الأفضل في: مفيد عندما يكون المستدعي بالتأكيد إنساناً داخل متصفح.

الضعف في: سيئ الملاءمة للوكلاء والأدوات والعملاء المؤتمتين والتدفقات التي يمكن تعهيدها إلى مزارع CAPTCHA.

ما الذي يقدمه فعلاً: احتكاك بشري، وليس قبولاً أصيلاً للآلة.

تحدي BTX + هوية موقعة

الأفضل في: يسمح للمستدعي بإثبات الحداثة ودفع كلفة إساءة على شكل حوسبة وإرفاق مواد توقيع أقوى.

الضعف في: لا يزال يحتاج إلى مصادقة عادية وقرارات سياسة حول الحساب والنطاق وقواعد العمل.

ما الذي يقدمه فعلاً: عمل جديد مع هوية آلة دائمة.

أنماط النشر

أين يناسب BTX داخل مكدسات الذكاء الاصطناعي والبوابات الحقيقية.

الأنظمة الشبيهة بالبوابة تميز بالفعل بين هوية الجهاز وسياسة المسار والتفويض. يضيف BTX طبقة عمل جديدة فوق ذلك عندما يكون المسار مكلفاً أو معرضاً للرسائل المزعجة أو يستحق الحماية من الإساءة المؤتمتة.

بوابة استدلال للذكاء الاصطناعي

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

وصول الوكلاء إلى الأدوات

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

التحكم في التسجيلات والرسائل المزعجة

يمكن للتعليقات والتسجيلات والنماذج العامة أن تسعّر الإساءة عبر الحوسبة بدلاً من الاعتماد على مزارع CAPTCHA أو جدران SMS أو أرصدة مدفوعة دائماً.

مستويات التحكم التشغيلية

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

هندسات مرجعية

ابدأ من شكل المسار الذي يطابق منتجك.

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

واجهة الاستدلال

واجهة عامة لاستدلال الذكاء الاصطناعي

الربط الموصى به
  • purpose: ai_inference_gate
  • resource: model:gpt-x|route:/v1/generate|tier:free
  • subject: tenant:abc123 أو api_key:key-42
سياسة التحدي
  • target_solve_time_s: من 2 إلى 4 ثوانٍ للحركة المجانية أو المجهولة
  • expires_in_s: من 60 إلى 180 ثانية حتى تفقد الأظرف القديمة قيمتها سريعاً
  • redeem path: استخدم redeemmatmulserviceproofs عندما تدخل الطلبات في طوابير أو تتوزع على عمال مشتركين
افتح الوثائق: ملف استدلال الذكاء الاصطناعي افتح الوثائق: RPC إصدار التحدي افتح الوثائق: RPC الاسترداد الدفعي
بوابة الوكلاء

بوابة الوكلاء أو الأدوات

الربط الموصى به
  • purpose: api_gate
  • resource: tool:calendar.write|route:/mcp/tools/calendar.write
  • subject: wallet:agent-42 أو device:devtok_abc123
سياسة التحدي
  • target_solve_time_s: من 1 إلى 2 ثانية للمكالمات التفاعلية، وأعلى للمسارات المميّزة
  • expires_in_s: من 30 إلى 120 ثانية لربط الطلبات الموقعة والعمل بشكل محكم
  • redeem path: استخدم redeemmatmulserviceproof للقبول طلباً بطلب على حافة البوابة
افتح الوثائق: ملف بوابة الوكلاء افتح الوثائق: عقد المسار المحمي افتح الوثائق: RPC الاسترداد
إرسال عام

إرسال عام مجهول

الربط الموصى به
  • purpose: rate_limit
  • resource: signup:/v1/messages أو comment:/v1/posts/:id
  • subject: ip:203.0.113.0/24 أو user:[email protected]
سياسة التحدي
  • target_solve_time_s: من 1 إلى 3 ثوانٍ حتى يكمل المستخدمون الصادقون بينما ترتفع كلفة الرسائل المزعجة
  • expires_in_s: من 60 إلى 300 ثانية، والاسترداد عند الإرسال النهائي فقط
  • redeem path: استخدم redeemmatmulserviceproof ما لم تكن تجمع أعمال المراجعة المؤجلة
افتح الوثائق: ملف الإرسال العام افتح الوثائق: دليل التدفق الأساسي افتح الوثائق: RPC الاسترداد
جاهزية الإنتاج

أظهر للفرق ما هو آمن الآن، وما الذي يحتاج إلى انضباط في التوجيه، وأين تقف حدود BTX.

تعامل مع تحديات خدمة BTX كطبقة حقيقية للتحكم في القبول: ابدأ بعقدة واحدة، واستخدم redeem عند نقطة القرار الفعلي، وكن واضحا بشأن ما الذي يثبته الدليل وما الذي لا يثبته.

المتاح الآن: مسارات محمية بعقدة واحدة

المسار الإنتاجي الموثق هو أن تقوم عقدة BTX واحدة بعمليتي issue و redeem على سجل التحديات نفسه. وهذا يغطي كثيراً من مسارات الاستدلال والتسجيل والبوابات من دون إضافة طبقة تنسيق أخرى أولاً.

نشر عقدة واحدة عقد المسار المحمي RPC الاسترداد

تنبيه التوسع: العقد المتعددة تحتاج إلى ثبات توجيه أو حالة مشتركة

إذا كان issue و redeem قد يصلان إلى عقد BTX مختلفة، يصبح سجل التحديات اعتماداً تشغيلياً. أضف sticky routing أو ملف تحديات مشترك قبل أن تعتبر المسار آمناً أفقياً.

نشر متعدد العقد دلالات الفشل مراقبة البوابة

قاعدة القبول: redeem للإنتاج و verify للتشخيص

يعطيك verify فقط ما إذا كان البرهان يطابق التحدي. أما redeem فهو حدث القبول الآمن ضد إعادة التشغيل، إذ يستهلك البرهان مرة واحدة ويعطي البوابة نتيجة موثوقة بالقبول أو الرفض.

Verify مقابل redeem RPC التحقق RPC الاسترداد

حدّ الثقة: BTX يثبت العمل، لا نموذج التفويض كله

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

ما الذي يثبته BTX إنشاء محفظة صيغة العنوان ما بعد الكمي

ملاحظة تنفيذية: BTX هي طبقة العمل الطازج وليست كل طبقة السياسات. النشر متعدد العقد ما زال يحتاج إلى sticky routing أو حالة تحديات مشتركة، وتفويض الأعمال يبقى خارج الدليل.

نمط البوابات ذات النطاقات

يناسب BTX البوابات التي تستخدم بالفعل الدور والنطاق وثقة الجهاز.

وثائق OpenClaw المنشورة مثال على ذلك: يعلن العملاء الدور والنطاقات وقت المصافحة، ويوقعون على nonce تحدٍ يقدمه الخادم، ويتلقون رموز أجهزة مرتبطة بالدور والنطاقات. يناسب BTX هذا المكدس كمتطلب عمل على مستوى المسار للإجراءات المكلفة أو المعرضة للإساءة.

حالة المصافحة موجودة مسبقاً في البوابات ذات النطاقات

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

يمكن أن تبقى هوية الجهاز ورموزه كما هي

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

nonce الخادم مع تحدي BTX يشكلان مكدساً نظيفاً

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

والنتيجة سياسة تبدو طبيعية للوكلاء

يمكن تقييم الأدوار والنطاقات وثقة الجهاز والعمل الجديد كلها معاً من دون العودة إلى CAPTCHA بشري أو نموذج رصيد مدفوع مسبقاً بشكل دائم.

# Pseudocode: gateway route protected by BTX work
POST /v1/generate
Authorization: Signature keyId="btx-wallet:agent-42",...
X-Device-Token: devtok_...
X-BTX-Challenge-Id: chal_...
X-BTX-Proof-Nonce: ...
X-BTX-Proof-Digest: ...

# Server sequence
1. validate role + scope + device token
2. verify request signature
3. redeem BTX proof for this route
4. only then run the expensive action
عقد المسار المحمي بروتوكول بوابة OpenClaw تفويض MCP
طبقة الهوية

هوية مدعومة بالمحفظة تبدأ من ما بعد الكم.

تصميم محفظة ما بعد الكم افتراضياً

تعتمد محافظ BTX على الواصفات ومصممة حول ML-DSA وSLH-DSA منذ البداية. وهذا يقلل احتمال التعامل مع مواد الهوية الأساسية كمشروع ترحيل لاحق.

استكشف المصدر

تدفق التحدي مرتبط بالصعوبة الحية

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

استكشف المصدر

مبني لخدمات تنسيق الوكلاء

تضع وثائق البروتوكول BTX بالفعل فوق قاعدة تسوية ضيقة للجسور والخدمات وطبقات تنسيق الوكلاء بدلاً من بيئة تشغيل مشتركة واحدة.

استكشف المصدر
حزمة بدء المطور

ابنِ المسار ثم شدد تشغيله.

ترتب هذه الحزم الوثائق بحسب ترتيب عمل فرق API عادةً: نمذجة مسار التحدي، وربط الهوية، وتوصيل مستوى التحكم، ومراقبة الظروف الحية.

الهوية

ربط هوية المستدعي بمواد المحفظة

أضف عمل BTX فوق هوية مستدعٍ صريحة كي يتطور التحكم في القبول وافتراضات التوقيع الأقوى معاً.

إنشاء محفظة صيغة عنوان PQ
الصحة

مراقبة الصعوبة وظروف التحدي

اعرض تكلفة التحدي وصحة الشبكة مثل أي اعتماد إنتاجي آخر حتى يتمكن المشغلون من ضبط الحماية بلا تخمين.

مواصفة الصعوبة دليل المراقبة
المعايير والنظام البيئي

بقية المكدس تتحرك بالفعل نحو هوية أقوى للوكلاء وتدفقات تحدي أقوى.

2024-08-13

NIST تعتمد أول معايير PQC النهائية

ينطلق BTX من الاتجاه الذي يتحرك إليه عالم المعايير بالفعل: تواقيع ما بعد الكم وضغط الترحيل الآن، لا لاحقاً.

 RFC 9421 / 9449

معايير الطلبات الموقعة ناضجة بما يكفي للبناء عليها

توفر HTTP Message Signatures وDPoP إطاراً قوياً قريباً من المعايير لحركة API موثقة وبأسلوب إثبات الحيازة.

 2025-03-26

يدفع MCP قضايا auth والأمان الحقيقية إلى أدوات الوكلاء

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

 OpenClaw

أنظمة الوكلاء بأسلوب البوابة تستخدم بالفعل مواد أجهزة موقعة

تُظهر وثائق بوابة OpenClaw رموز أجهزة موقعة وأدواراً واعية بالنطاق. ويمكن لـ BTX أن يكمل ذلك بمتطلبات عمل جديدة على المسارات عالية الخطورة.

 2025-09-18

NIST تقول إن على المؤسسات أن تبدأ التخطيط الآن لهجرة PQC

يؤطر مشروع CSWP 48 الصادر عن NCCoE انتقال PQC على أنه مسألة حوكمة ومواءمة للضوابط يجب التعامل معها الآن، لا مهمة تؤجل إلى مراحل لاحقة.
الأسئلة الشائعة للمطورين

أسئلة تطرحها الفرق عندما تبني نماذج أولية لتدفقات التحدي في BTX.

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

هل يستبدل BTX مفاتيح API أو OAuth أو سياسة البوابة؟

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

افتح الوثيقة ذات الصلة
أين يوضع التحدي داخل سير عمل الذكاء الاصطناعي أو الوكلاء؟

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

افتح الوثيقة ذات الصلة
لماذا ندخل هوية ما بعد الكم المدعومة بالمحفظة في هذا التدفق؟

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

افتح الوثيقة ذات الصلة
هل يمكن أن ينسجم هذا مع بروتوكولات بوابة مثل OpenClaw أو مكدسات شبيهة بـ MCP؟

نعم على المستوى المعماري: احتفظ بنموذج الدور والنطاق وثقة الجهاز القائم، ثم أضف BTX كمتطلب عمل على مستوى المسار. هذا هو التوافق المقصود الموصوف في هذه الصفحة، وليس ادعاءً بأن BTX يقدم تكاملاً أصلياً مع OpenClaw اليوم.

افتح الوثيقة ذات الصلة
الخطوة التالية

إذا كان منتجك يعاني من مشكلة إساءة استخدام أو طبقة مجانية أو طبقة وكلاء، فينبغي أن يكون BTX جزءاً من مراجعة التصميم.

ابدأ بدليل تحديات الخدمة، واقرأ نموذج المحفظة، واصنع نموذجاً أولياً لمسار آمن للوكلاء يتطلب الهوية والعمل معاً.

ابنِ التدفق عرض btx-node