الانتقال إلى المحتوى الرئيسي

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

هذه الصفحة مُترجَمة آليًا بواسطة الذكاء الاصطناعي. النسخة الإنجليزية هي المرجع المعتمد.عرض النسخة الإنجليزية →
MEV على Solana ليس متطابقًا مع MEV في Ethereum القائم على mempool. قادة الكتل يرون حزم المعاملات كما تصل، وليس كـ mempool مرتب؛ يحدث Front-running عبر إعادة ترتيب من جانب القائد أو المُحقِّقون الموجودون في نفس الموقع، وتنفذ هجمات الساندويتش من قبل برامج روبوت تراقب حالة Pool وتسابق معاملتك برسوم أعلى. وبناءً على ذلك، تختلف التخفيفات.

​
مقدمة التوجيه المقسّم

“التوجيه المقسّم” يعني تقسيم مبادلة منطقية واحدة عبر عدة Pools بحيث تتساوى الأسعار الهامشية — نفس المخرجات كما لو تاجرت كل شريحة بسعر Pool الخاص بها. يقلل من تأثير السعر الفعلي عندما يكون أي Pool واحد ضحلاً نسبةً إلى حجم التجارة. بيان المشكلة: بالنظر إلى Pools P_1, ..., P_n مع دوال f_i(x) التي تعيّن الإدخال x إلى المخرجات، أوجد التقسيم x_1 + ... + x_n = X الذي يعظّم Σ f_i(x_i). نظرًا لأن كل f_i مقعرة، فإن الأمثل يرضي f'_1(x_1) = f'_2(x_2) = ... = f'_n(x_n) (أسعار هامشية متساوية).

​
التطبيق الجشع

نهج بسيط يحصل على حوالي 1% من الأمثل في الممارسة: 
remaining = X
routes    = []
step      = X / 1000     // حجم الشريحة
while remaining > 0:
    best_pool = argmax over i of f'_i(current_x_i + step)
    x_i += step
    routes.append((best_pool, step))
    remaining -= step
خطوة أدق → أقرب إلى الأمثل، المزيد من التكرارات. في الممارسة، 100–500 شريحة هي نقطة توازن معقولة.

​
تطبيق التحسين المحدب

بالنسبة للمجمعات على مستوى الإنتاج، حل التحسين مباشرة. لكل Pool شكل مغلق f'_i(x):
  • Constant-product (CPMM / AMM v4): f'(x) = y * R_y / (R_x + x)^2 حيث R_x, R_y هي الاحتياطيات و y = R_x * R_y / (R_x + x) - R_y … (اشتقاق أبسط: السعر الهامشي هو R_y / (R_x + x)، لذا التقسيم لمساواة الأسعار الهامشية هو بحث أحادي البعد).
  • CLMM: سلس بشكل متعدد — ضمن tick واحد، f'(x) هي دالة عقلانية لـ sqrt_price؛ عبر tick، يتدرج بشكل منفصل. قسّم بحل الخطوة الصغيرة أو تعامل مع كل tick متجاور كـ “Pool” خاص به.
مخرجات التوجيه المقسّم هي متجه [(pool_1, x_1), (pool_2, x_2), ...] الذي تحوله خطوة تجميع المعاملة إلى سلسلة من تعليمات المبادلة.

​
متى يساعد التوجيه المقسّم

حجم التجارة مقابل TVLهل يساعد التقسيم؟
<0.1%لا — Pool واحد يهيمن
0.1–1%بشكل هامشي
1–5%نعم، تحسن 10–50 bps
>5%نعم، تحسن كبير
إذا كنت تشغل مبادلة في-الواجهة للمحفظة لمستخدم بيع يقوم بـ <$10k على Pool عميقة، فلا تزعج نفسك بالتقسيم — فالحمل الإضافي للغاز يتجاوز التحسن. بالنسبة لمجمع يقتبس تدفق مؤسسي، قسّم دائمًا.

​
المسارات متعددة القفزات

عندما لا يوجد Pool مباشر، أو أن تأثير سعر Pool المباشر ضخم، قفز عبر وسيط: 
tokenA → tokenHub → tokenB
Hubs الشائعة: USDC، SOL، RAY. لكل قفزة:
  • حد انزلاق خاص بها (أقل على القفزات المباشرة؛ لكل قفزة على متعدد القفزات).
  • رسم خاص بها.
  • تأثير سعر خاص بها.
التأثير الإجمالي يتراكم: (1 - impact_1) * (1 - impact_2). تأثير 1% قفزة مرتين هو 1.99% الإجمالي، وليس 2%. لا تقفز أبدًا عبر نفس Pool مرتين. الذهاب A → B → A → B عبر نفس CLMM يحرق فقط الرسوم والانزلاق. يجب على المجمعات تصفية هذه المسارات عند الإنشاء. (ملاحظة: هذا هو دورة نفس الزوج، وليس متعدد القفزات بشكل عام — التوجيه A → USDC → B عبر Pools مختلفة هو النمط القياسي والمفيد الموصى به أعلاه.) الحد الأدنى لكل قفزة مقابل الطرف إلى الطرف. مع تكوين CPI (integration-guides/cpi-integration)، يمكنك ضبط minimum_amount_out لكل قفزة على 0 وفرض حد أدنى واحد من الطرف إلى الطرف في وكيلك. بدون CPI، كل قفزة تفرض الحد الأدنى الخاص بها، مما يتطلب حساب حدود وسيطة معقولة — عادةً quote_i * (1 - slippage_bps/10000) لكل قفزة.

​
هجمات الساندويتش

​
الآلية

يراقب الروبوت تدفق gossip للمعاملات. عندما يرى مبادلتك:
  1. Front-run: يشتري الروبوت نفس الـ token قبلك، مما يدفع سعر Pool للأعلى.
  2. معاملة الضحية: تتبادل بسعر أسوأ.
  3. Back-run: يبيع الروبوت بالسعر المرتفع، ويلتقط الفرق.
يدفع الروبوت رسوم الأولوية لكلا المعاملتين؛ الربح هو فرق الساندويتش مطروحًا منه ضعف رسوم الأولوية. مربح فقط على Pools حيث تحرك تجارتك السعر بشكل ذي مغزى.

​
التخفيفات

انزلاق محكم. إذا كان الحد الأدنى الخاص بك 0.5% أقل من الاقتباس، فإن ساندويتش يحرك السعر أكثر من 0.5% يعود إليك، لكن pre-trade الروبوت تنفذ بسعرك القديم. يخسرون المال. تستهدف برامج الساندويتش انزلاق واسع (≥1–2%)؛ الانزلاق دون 0.3% محصّن إلى حد كبير. إرسال mempool خاص (Jito). أرسل معاملتك كجزء من Jito bundle. لا تظهر البلايندات على تدفق gossip العام؛ لا يمكن للروبوتات أن ترى التجارة أثناء التنقل وتقوم بـ front-run. المقايضة: تتطلب البلايندات tip من جانب المُحقِّق، وليس كل قائد مفعّل في Jito (على الرغم من أن معظمهم كذلك). أحجام تجارة أصغر. قسّم التجارة عبر معاملات متعددة بحيث لا توجد معاملة واحدة تحرك السعر بما يكفي لتكون هدف ساندويتش مربحًا. يزيد من إجمالي تكلفة الغاز. عشوائية الوقت. أرسل خلال فترات أقل حجمًا إن أمكن. غير متاح للمبادلات التفاعلية للمستخدم لكن قابل للتطبيق على تدفق البوت المجدول. عادةً ما ترى Pools CLMM في Raydium نشاطًا ساندويتش أقل من CPMM لأن هيكل السيولة أحادي-Tick يعني أن التجارات الصغيرة لا تحرك السعر على الإطلاق (تبقى ضمن Tick واحد). تعتبر Pools CLMM العميقة أفضل مكان مقاوم للساندويتش بشكل عضوي.

​
Jito bundles

Jito هو عميل Solana validator معدّل يقبل bundles — مجموعات مرتبة من المعاملات المهبوطة بشكل ذري. تستخدم الروبوتات Jito لاستخراج MEV؛ يستخدمها المستخدمون العاديون للحماية من نفس الروبوتات.

​
كيف تعمل البلايندات

  • الاتصال بـ Jito block engine endpoint (مثل https://mainnet.block-engine.jito.wtf).
  • أرسل bundle من 1–5 معاملات بالإضافة إلى tip لأحد حسابات Jito tip.
  • إذا كان قائد الحالة الحالي يشغل Jito، يتم النظر في bundle الخاص بك. يهبط الفائز بالمزاد لهذه الحالة (bundle بأعلى tip-per-CU)؛ يسقط الآخرون.

​
تحديد حجم Tip

أحجام Tip تتابع توزيع bundle الحديث. ينشر Jito النسب المئوية الفعلية: 
const tipRes = await fetch("https://worker.jito.wtf/api/v1/bundles/tip_floor");
const tips   = await tipRes.json();
// { ema_landed_tips_25th_percentile, 50th, 75th, 95th, 99th }

// مبادلة موجهة للمستخدم في يوم عادي — النسبة المئوية 50 جيدة.
const tipSol = tips.ema_landed_tips_50th_percentile_lamports / 1e9;

// تجارة روبوت حساسة للوقت أثناء الازدحام — النسبة المئوية 75–95.
النطاقات النموذجية: 0.0001–0.001 SOL لمبادلات المستخدم غير العاجلة؛ 0.01–0.1 SOL أثناء الازدحام للروبوتات عالية الأولوية.

​
بناء Bundle

import { SearcherClient } from "jito-ts";

const client = new SearcherClient("https://mainnet.block-engine.jito.wtf");

const tipIx = SystemProgram.transfer({
  fromPubkey: user.publicKey,
  toPubkey:   JITO_TIP_ACCOUNTS[Math.floor(Math.random() * 8)],  // 8 حسابات tip
  lamports:   tipLamports,
});

const tx1 = new VersionedTransaction(...);  // المبادلة
tx1.sign([user]);

const bundleUuid = await client.sendBundle([tx1], tipLamports);
// اختياريًا: await confirmation via client.getBundleStatuses([bundleUuid])
المزالق:
  • يجب أن يكون Tip داخل Bundle. قم بتضمين SystemProgram.transfer إلى حساب Jito tip كتعليمة داخل إحدى معاملات Bundle (عادةً الأخيرة). معاملة tip منفصلة ليست جزءًا من Bundle يتم تجاهلها.
  • القائد غير مفعّل في Jito. حوالي 75% من القادة يشغلون Jito؛ حوالي 25% لا. تُسقط Bundles المرسلة عندما يمسك قائد غير مفعّل في Jito بـ Slot. سيعاود المحاولة العميل تلقائيًا.
  • الانتهاء. تستخدم Bundles نفس نموذج blockhash-expiry مثل المعاملات العادية. اجمع وأرسل بسرعة؛ نافذة حوالي 60 ثانية.

​
Bundles مقابل رسوم الأولوية

رسوم الأولوية ترشي القائد لتضمين معاملتك أسرع. تجميع Jito بالإضافة إلى ذلك يخفي المعاملة عن mempool العام. استخدم رسوم الأولوية للاستعجالية؛ استخدم Bundles لحماية الساندويتش. الحزام والرافعات: استخدم كليهما على مبادلات المستخدم عالية القيمة. انظر integration-guides/priority-fee-tuning لتحديد حجم رسوم الأولوية.

​
MEV-share / RPC محمي من الرجوع

توفر بعض مزودي RPC نقاط نهاية “MEV-share” أو “محمي من الرجوع” التي توجه معاملتك بشكل داخلي عبر Jito bundles أو مسارات خاصة معادلة:
  • Helius — الاتصالات المراهنة مع دعم Bundle.
  • QuickNode — نقطة نهاية “Revert Protect”؛ تشكل البلايندات تلقائيًا حول المعاملات المقدمة.
  • Triton — طبقة تدفق خاصة.
استخدام أحد هذه هو أبسط مسار للمشاريع التي لا تريد إدارة منطق Bundle بأنفسهم. المقايضة: الداخل غير شفاف؛ تثق بـ bundle construction من المزود.

​
معالجة الازدحام

أثناء نوافذ الحجم العالي (إطلاقات mainnet، الإدراجات الرئيسية، الارتفاع المستدام)، تمتلئ قوائم انتظار حزم القائد. الأعراض:
  • تبقى المعاملات بدون تأكيد لمدة 60+ ثانية، ثم تنتهي بـ “blockhash not found”.
  • رسوم الأولوية التي نجحت بالأمس غير كافية اليوم.
  • محاكاة تنجح لكن التنفيذ أبدًا لا يهبط.
الاستراتيجيات:
  1. إعادة محاولة عدوانية على انتهاء الصلاحية. على TransactionExpiredBlockheightExceeded، أعد البناء مع blockhash طازج وأعد الإرسال. لا تعيد المحاولة على الرجوع — الرجوعات حتمية.
  2. بث متعدد RPC. أرسل نفس المعاملة إلى RPCs متعددة بالتوازي؛ أيها تصل إلى قائد أولاً يفوز.
  3. رسوم أولوية متصاعدة. ابدأ بالنسبة المئوية 50؛ إذا انتهت المحاولة الأولى، أعد المحاولة على 75، ثم 95.
  4. Jito bundles كخطة بديلة. قادة Jito يميلون إلى أن يكونوا أقل ازدحامًا لأن محرك الكتل يفرز Bundles حسب tip-per-CU؛ تحصل Bundles عالية Tip على الأولوية.
  5. محاكاة أقل. تحت الازدحام، محاكاة مرة واحدة في البداية؛ لا تعيد المحاكاة على المحاولات الجديدة منذ أن تحول حالة Pool على أي حال. إعادة المحاكاة أثناء الازدحام غالبًا ما تفشل بشكل غريب.

​
اعتبارات MEV لكل منتج

CPMM. ساندويتشة للغاية على Pools منخفضة TVL. يضخّم منحنى الثابت-منتج حتى pre-trades البوت الصغيرة. أوصي بـ Jito bundles لأي تجارة CPMM >0.5% من TVL Pool. CLMM. ساندويتش أقل على Pools العميقة لأن التجارات داخل-tick لا تحرك السعر. لكن التجارات عبر-tick بالتأكيد تفعل؛ الساندويتشات التي تستهدف عبور Ticks هي نمط معروف. الانزلاق المحكم (<0.3%) هو أفضل دفاع. AMM v4 + OpenBook. يتم ملء OrderBook OpenBook عبر نفس tx، لذلك برامج الروبوت للساندويتش التي لا تعرف حالة OrderBook low-estimate تأثير السعر وغالبًا ما تفشل. مكان عضوي منخفض-MEV لهذا السبب. LaunchLab. خلال مرحلة bonding-curve المبكرة، يكون Front-running منتشرًا على الإطلاقات المشهورة. تتحرك المنحنيات بسرعة والانزلاق واسع. يوصى بـ Jito bundles بقوة. بعد التخرج، تتبع CPMM الناتجة ديناميكيات CPMM العادية. Farms. عمليات الحصاد والرهان ليست مبادلات وليست ساندويتش. لا حاجة لمعالجة خاصة.

​
قائمة المراجعة

بالنسبة لمجمع إنتاج / محفظة swap UI:
  • تقصر الانزلاق إلى ≤0.5% على الأزواج العادية؛ يمكن للمستخدم تجاوزه.
  • تقديم Jito bundle مفعّل بشكل افتراضي للمبادلات >$1k قيمة USD.
  • رسوم الأولوية مصدرها من تقدير مباشر (وليس مشفرة بشكل ثابت).
  • منطق إعادة المحاولة يميز الرجوع (لا تعيد المحاولة) من انتهاء الصلاحية (أعد المحاولة مع blockhash جديد).
  • مسارات متعددة القفزات ضبط minimums لكل قفزة، وليس طرف إلى طرف.
  • تقسيم التوجيه نشط للتجارات >1% من TVL أي Pool واحد.
  • انتعاش Pool: إعادة جلب الحالة مباشرة قبل الإرسال؛ إعادة الاقتباس إذا كانت قديمة.
  • مقاوم للساندويتش على Pools الضحلة: إما Jito فقط، أو رفض إذا كان الانزلاق >1%.

​
مؤشرات

المصادر: