لماذا وصول حكم الذكاء الاصطناعي إلى Solana لا يعني اكتمال التسوية] @GenLayer لنفترض أن سوق وكلاء الذكاء الاصطناعي في Solana يُفوّض تقييم جودة المهام إلى GenLayer. حتى لو اتفق المدققون على النتائج، فإن تحديد أي حساب على Solana سيُسجل له المكافأة هو أمر منفصل تمامًا. يحتوي كود الجسر الذي نشرته مؤسسة GenLayer على هيكل لنقل الرسائل بين GenLayer وSolana عبر LayerZero V2 ومحور EVM. هنا، يتم فصل مكان تنفيذ الحكم الذكي الاصطناعي عن المكان الذي يُغيّر به حالة التطبيق بناءً على النتيجة. طريقة استقبال Solana للرسائل تعتمد على تكوين الحسابات: إذا كان الحساب المستقبل محددًا مسبقًا، يمكن تحديث حالة الاستلام المسجلة مباشرة عبر مسار DirectCpiReceiver. يجب تنفيذ استدعاءات البرامج الخارجية إضافيًا لتتناسب مع البرنامج المستقبل. أما إذا كان الحساب المستهدف يختلف حسب الطلب أو المستخدم، فيجب أولاً تخزين الرسالة عبر StoreAndClaim، ثم تحديد الحسابات المطلوبة عند استدعاء claim_message. يجب على Solana تحديد قائمة الحسابات التي سيتم استخدامها قبل تنفيذ المعاملة. لذلك، لا يمكن اعتبار التسوية مكتملة للمستخدم فقط لأن الرسالة وصلت عبر الجسر. يتم أيضًا التحقق من مصدر الرسالة بشكل منفصل عن الحكم. تم تصميم التنفيذ العام للتحقق من العقد الموثوق به وتجنب المعالجة المكررة للطلبات نفسها باستخدام معرف رسالة فريد. لكن منع التكرار أو تسليم الرسالة بشكل طبيعي لا يُعد دليلاً على صحة محتوى الحكم الذكي الاصطناعي نفسه. ما تناولته أثناء تطوير PolicyGuard في Studio كان مسألة تقييم ما إذا كانت القواعد الواردة في الوثيقة قد تغيرت فعليًا. من خلال كود الجسر هذا، يمكننا أن نرى أنه عند ربط نتيجة الحكم بخدمة على سلسلة أخرى، يجب تصميم معايير الحكم، فضلاً عن نقلها واستلامها وحالة التسوية، معًا. حاليًا، تحتوي المستودعات العامة على سجلات اختبار ثنائية الاتجاه بين Base Sepolia وSolana Devnet، لكن لا ينبغي اعتبار هذه السجلات إنجازًا تشغيليًا لخدمات Solana التجارية التي تستخدم أحكام الذكاء الاصطناعي من GenLayer. تنقسم الأدلة المطلوبة للنجاح في تطبيقات الذكاء الاصطناعي متعددة السلاسل إلى ثلاثة عناصر: التأكيد النهائي لحكم GenLayer، والرسالة القادمة من مصدر موثوق، وتغيير حقيقي في حالة الحساب الوجهة. الكود العام: https://t.co/N4zVSxjYG7 #GenLayer #GenLayerDOKDOPioneer