دليل بوت بوليماركت · الفصل 32 من 32
أخطاء حقيقية في بوت بوليماركت وتقارير ما بعد الحادث: التنفيذات الوهمية، وإزالة التكرار عند الفشل اللاصق، وحادثة whipsaw في lol-ctg-ccg، وخطأ NegRisk flag، والإطلاق المبكر - مع commits والتواريخ التي أصلحت كل مشكلة.
ما الذي يغطيه هذا الفصل
يومياتنا الإنتاجية الخاصة بالأخطاء التي كلّفتنا أموالًا حقيقية. النمط أهم من التفاصيل - فالفئات نفسها من الأخطاء تتكرر عبر البوتات، والعلاج غالبًا يكون مراقِبًا مفقودًا، لا استراتيجية أفضل. الهدف من هذا الفصل أن يوفر عليك الرسوم الدراسية.
- التنفيذات الوهمية (commits e68a087، 8bb7761)
- خطأ NegRisk flag (commit)
- إزالة التكرار عند الفشل اللاصق (commit)
- حادثة whipsaw: lol-ctg-ccg
- الإطلاق المبكر: محو 2025
- الاستغراق في النوم فوق خلل برمجي: مفتاح إيقاف عمل
- دروس قابلة للتعميم
التنفيذات الوهمية (commits e68a087، 8bb7761)
أول حادثة كبيرة للتنفيذات الوهمية في المتداول الخاص بنا، في مايو 2025. وضع بوت عدد 22 من أوامر الشراء من نوع FOK، وتمت مطابقتها كلها على CLOB. بعد ذلك مباشرة حاول بوت إرسال 22 أمر بيع من نوع GTC. تم رفض 8 منها برسالة "balance: 0 / sum of active orders: 0 / order amount: 10000000."
السبب الجذري: تأخر التسوية (الفصل 12). تمّت مطابقة CLOB خلال 100ms، وأرسل بوت أمر البيع بعد 200ms، لكن نقل Polygon ERC-1155 استغرق نحو ثانيتين. رفض CLOB أمر البيع لأن السلسلة ما زالت تُظهر رصيدًا صفريًا.
الإصلاح: إدخال انتظار حاجز لمدة 5 ثوانٍ بين أي شراء ناجح وأي متابعة من نوع GTC على الرمز نفسه. commits e68a087 و8bb7761. لا توجد أي حوادث للتنفيذات الوهمية منذ ذلك الحين.
الدرس: وقت API ووقت السلسلة ليسا نفس الجدول الزمني. الكود الذي يفترض أنهما متزامنان سيصطدم بنمط الفشل هذا تحديدًا.
خطأ NegRisk flag (commit)
كان هناك حدث متعدد النتائج من نوع NegRisk يضم 8 مرشحين، وظهرت فيه فرصة مراجحة لحظية بمقدار 1.8c (مجموع أسعار الطلب على YES = 0.982). أطلق بوت المراجحة لدينا جميع أوامر الشراء الثمانية من نوع FOK. تم تنفيذ 6 منها؛ بينما استقرّ 2 في عقد منصة تداول خاطئ.
السبب الجذري: كان بوت يستدعي createAndPostOrder دون تعيين negRisk: true داخل كائن flags. كان لدى اثنين من الأسواق تاريخ إنشاء مختلف ويتطلبان هذه الراية؛ أما الأسواق الستة الأخرى فلم تكن بحاجة إليه لأن العقد الأساسي لديها كان يمر عبر NegRisk افتراضيًا أصلًا.
الإصلاح: قراءة market.negRisk من Gamma لكل سوق، وتمريره إلى كل استدعاء أوامر. commit. أعدنا تشغيل المراجحة مع تعيين الراية؛ وتمت تسوية السوقين المتبقيين بشكل صحيح.
الدرس: لا تجعل خاصية السوق افتراضية أبدًا. اقرأها صراحةً من مصدر الحقيقة في كل مرة.
إزالة التكرار عند الفشل اللاصق (commit)
أعاد بوت محاولة شراء فاشلة 5 مرات خلال 12 ثانية. المحاولة الأولى نجحت فعليًا (انقطاع الشبكة المؤقت جعل بوت لا يرى الاستجابة)؛ أما المحاولات الأربع التالية فقد أنشأت 4 مراكز إضافية. المحصلة: 5 مراكز في السوق نفسه بينما كنا نريد مركزًا واحدًا.
السبب الجذري: عدم وجود client-order-id قابل للتكرار. كان منطق إعادة المحاولة لدى بوت يقول: "إذا فشلت، جرّب مرة أخرى مع salt جديد." لم يكن لدى CLOB أي طريقة للتعرف على المحاولات المتكررة باعتبارها نسخًا مكررة.
الإصلاح: توليد UUID حتمي لكل أمر مقصود قبل المحاولة الأولى. جميع محاولات الإعادة تستخدم client-order-id نفسه، ما يسمح لـ CLOB بإجراء dedup. commit.
الدرس: إعادة المحاولة دون idempotence تعني أوامر مكررة. كل أمر يحتاج إلى معرّف ثابت على جانب العميل.
حادثة التذبذب: lol-ctg-ccg
مباراة رياضات إلكترونية (CTG vs CCG) دفعت بوت إلى الدخول في شراء عند 0.45 عندما أصبح الاختلال إيجابيًا. خلال 30 ثانية، انقلب الاختلال إلى سلبي، وتم ضرب أمر البيع GTC عند 0.50 بواسطة أمر من طرف آخر. الأرباح والخسائر: +5c × 10 أسهم = +$0.50.
بعد 10 دقائق، انقلب الاختلال في السوق نفسه إلى إيجابي مرة أخرى. دخل بوت مرة أخرى عند 0.42. هذه المرة لم يتعافَ الاختلال أبدًا؛ وانجرف السعر الأوسط إلى 0.18، ثم سارت الصفقة إلى التسوية النهائية عند 0.
السبب الجذري: كانت الاستراتيجية تتعامل مع الاختلال كإشارة اتجاهية لكنها لم تتابع أن الاختلال كان يتأرجح - كانت الإشارتان كلتاهما ضجيجًا، لا معلومات. تعرّض بوت للتذبذب عبر إشارتين فاشلتين في السوق نفسه خلال 20 دقيقة.
الإصلاح: فترة تهدئة لكل سوق - بعد أي تنفيذ، لا توجد أي دخولات جديدة في السوق نفسه لمدة 30 دقيقة. سُمح بعدة دخولات عبر أسواق مختلفة، لكن ليس بشكل متتالٍ في السوق نفسه.
الدرس: الإشارة التي تتأرجح ليست إشارة. صفِّها من أجل الاستمرارية قبل التصرف.
الإطلاق المبكر: محو 2025
استراتيجية صناعة السوق جديدة اجتازت 12 صفقة ورقية. لم ينتظر الباني حتى 30، وقرر أن "الوضع يبدو جيدًا"، ثم نشرها مباشرة برأس مال قدره $500. خلال 18 ساعة أصبحت المحفظة عند $200.
السبب الجذري: 12 صفقة ليست عينة كافية للتمييز بين معدل فوز 60% ومعدل فوز 35%. كانت الاستراتيجية في الواقع عند معدل فوز 35%؛ وكانت نافذة الصفقات الورقية الـ 12 مجرد سلسلة غير ممثلة للواقع.
بوابة الـ 30 صفقة موجودة لسبب. التباين في عينة من 12 صفقة يجعلها غير قابلة للتمييز عن "الاستراتيجية لا تعمل".
الدرس: الانضباط يتفوق على الاقتناع. بوابة الـ 30 صفقة ليست قابلة للتفاوض.
النوم أثناء الخطأ: مفتاح الإيقاف عمل
كان لدى بوت خطأ off-by-one في فلتر وقت اليوم - كان من المفترض أن يتوقف عند 02:00 UTC، لكنه كان يتوقف فعليًا عند 03:00 UTC. خلال الساعة غير المتوقفة 02:00-03:00، كان Polygon RPC يفرض تقييدًا صارمًا للمعدل على طلباتنا؛ وكانت مسار القراءة لدى بوت يعيد بيانات قديمة.
واصل بوت التداول بناءً على أسعار قديمة. الأرباح والخسائر خلال الساعة: -$3.20 عبر 22 صفقة. تم تشغيل مفتاح الإيقاف الخاص بالخسارة اليومية عند -5%، وأوقف البوت، وأرسل تنبيه Telegram عند 03:08 UTC. استيقظ الباني على بوت متوقف عند 09:00، وكان إجمالي الضرر محدودًا بحدّ الإيقاف.
الدرس: كان خللًا حقيقيًا لكن مفتاح الإيقاف عمل. -$3.20 بدلًا من -$50.00. ضوابط المخاطر لا تمنع الأخطاء؛ إنها تحدّ من تكلفة الأخطاء التي لم تتوقعها.
دروس قابلة للتعميم
عبر جميع تقارير ما بعد الحوادث، تتكرر أربعة أنماط.
- وقت API ≠ وقت السلسلة. تأخر التسوية، وتأخر RPC، وتأخر WebSocket - كلها تُدخل فجوات يجب على كود بوت التعامل معها صراحةً.
- الإعادة تحتاج إلى idempotence. أي إعادة محاولة بدون client-order-id هو خطر أوامر مكررة. دائمًا.
- اقرأ كل خاصية للسوق بشكل صريح. راية NegRisk، وحجم tick، والانتهاء. لا تجعل شيئًا افتراضيًا أبدًا؛ اقرأ دائمًا من مصدر الحقيقة.
- مفتاح الإيقاف هو الحد الأدنى، وليس ميزة. ضوابط المخاطر تحدّ من الخسائر الناتجة عن الأخطاء. الاستراتيجيات لا تمنع الأخطاء؛ إنها تفترض أن بوت يعمل بشكل صحيح. ولن يعمل بوت بشكل صحيح دائمًا.
كل فصل في هذه السلسلة يحتوي في مكان ما على واحد من هذه الأنماط. إنها المبادئ الحاملة لبوت إنتاجي. تجاهلها وستجدها مرة أخرى في تقارير ما بعد الحوادث الخاصة بك.
