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

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

الآن، بدأت بعض حلول Oracle الجديدة تقدم وضعية محرك مزدوج — حيث يوجد دفع نشط وسحب عند الطلب. هذا التصميم في الواقع ذكي جدًا، لأنه لا يتعلق بـ"هذا جيد وذاك سيء"، بل بـ"أيهم أكثر توافقًا".

خذ على سبيل المثال ZetaChain، فهم يشرحون نموذجين للخدمة بشكل مباشر جدًا. Data Push هو دفع البيانات إلى السلسلة بشكل دوري أو عند تجاوز حد معين، والمزايا هي سرعة الاستجابة، وقدرة التوسع، وهو مناسب للسيناريوهات التي تتطلب تحديثات مستمرة وتوقعات مستقرة. Data Pull هو طلب البيانات بشكل نشط من قبل التطبيق، مع تأخير منخفض وتكرار تحديث مرن، وهو مثالي لمنتجات DEX أو DeFi — حيث يحتاجون إلى الحصول على البيانات بسرعة ولكن لا يرغبون في تحمل تكاليف إضافية للتحديث المستمر.

كيف تحدد أيهما تختار؟ يمكنك أن تبدأ بتصنيف جوهر التطبيق. هل منتجك "مدفوع بالحالة" أم "مدفوع بالصفقة"؟

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