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

**استقرار الاتصال** هو أول مشكلة كبيرة. عند جمع البيانات التاريخية أو البيانات اللحظية، غالبًا ما يتوقف WS عن العمل فجأة أو يرسل بيانات غير مكتملة، مما يؤدي مباشرة إلى فجوات في بيانات دفتر الأوامر. لقد تعرضت لهذا الأمر على خادم في طوكيو — حيث كان البوت يعتمد على دفتر أوامر غير مكتمل، مما زاد من المخاطر بشكل كبير. لاحقًا، فكرت في استخدام استعلام REST API كخطة احتياطية، وتمكنت أخيرًا من السيطرة على المشكلة. بالطبع، هذا يتطلب تصميم جيد للخادم والبرمجيات، وليس مجرد مشكلة من جانب الشركة الرسمية.

**آلة الحالة + التحقق من مصادر متعددة** هو المبدأ الذي أدركته أخيرًا. أثناء تشغيل الاستراتيجية، إذا حدثت مشكلة في API، فإن الأمر قد ينفجر بسهولة. لذلك، من الضروري استخدام آلة الحالة لمراقبة الطلبات طوال الوقت (إرسال الطلب → التأكيد → المطابقة → التسوية على السلسلة)، مع وضع عدة طبقات من التحذيرات: مثل توقف الطلب عند تجاوز مدة الانتظار المحددة، أو تغير مفاجئ في دفتر الأوامر، أو تجاوز الانزلاق السعري للحد المسموح، وعند حدوث أي من هذه الحالات، يتوقف عن إصدار أوامر جديدة ويغلق المراكز المفتوحة لتقليل المخاطر. بالإضافة إلى ذلك، يتم التحقق من البيانات عبر WS وAPI، مع التحقق المتقاطع من أحداث السلسلة واستعلامات The Graph، لضمان الثقة.

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

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