الحماية من MEV باستخدام Jito DontFront

تشير القيمة القابلة للاستخراج القصوى (MEV) إلى القيمة التي يمكن التقاطها عن طريق إعادة ترتيب المعاملات أو تضمينها أو استبعادها داخل كتلة. لا تقتصر MEV على سلسلة بعينها؛ بل هي خاصية جوهرية لأي بلوك تشين يتحكم فيه منتجو الكتل في ترتيب المعاملات. بعض أشكال MEV، كالمراجحة، تساعد في إبقاء الأسواق فعّالة عبر تصحيح تفاوتات الأسعار بين منصات DEX. بينما تستخلص أشكال أخرى، كهجمات الساندويتش، القيمة مباشرةً من المستخدمين. بالنسبة للمطورين الذين يبنون تطبيقات DeFi، قد يعني ذلك تنفيذ صفقات بأسعار أسوأ وخسارة في الأرباح.

يركّز هذا الدليل على هجمات الساندويتش، وهي شكل شائع من أشكال MEV الضارة، وكيفية التخفيف منها باستخدام ميزة dontfront من Jito.

القراءة المسبقة الموصى بها: Jito Bundles

MEV على سولانا

تُقلّل بنية سولانا بالفعل من مساحة تأثير MEV مقارنةً بالسلاسل ذات مجمعات المعاملات المعلقة العامة. تُحال المعاملات مباشرةً إلى قائد الكتلة القادم bedel بدلاً من الانتظار في مجمع مشترك، وتنتهي صلاحية المعاملات غير المعالجة بعد نحو 150 كتلة (~دقيقة واحدة). مما يُضيّق بشكل ملحوظ النافذة الزمنية المتاحة للباحثين لرصد المعاملات المعلقة والتصرف حيالها.

ومع ذلك، لا تزال عمليات استخراج MEV تحدث. يستطيع الباحثون الذين يمتلكون بنية تحتية محسّنة واتصالات مباشرة بـ validator رصد تدفق المعاملات والاستجابة له. كثير من نشاط MEV على سولانا هو مراجحة ذرية: روبوتات تصحّح فوارق الأسعار bين منصات DEX في معاملة واحدة. هذا النوع من MEV مفيد بوجه عام، إذ يُحسّن اتساق الأسعار عبر الأسواق.

أما النوع الضار، وهو هجمات الساندويتش، فهو ما ينبغي على المطورين الحماية منه بفاعلية.

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

تحدث هجمة الساندويتش عندما يرصد باحث معاملة المبادلة المعلقة الخاصة بك ويستغل ترتيب المعاملات:

1. التقدم على المعاملة (Front-run): يشتري الباحث الرمز قبل صفقتك، مما يرفع السعر
2. تُنفَّذ صفقتك بسعر أسوأ مما هو متوقع
3. التأخر عن المعاملة (Back-run): يبيع الباحث الرمز بعد صفقتك، محققاً الفارق

على سولانا، يمكن أن يحدث هذا عبر Jito bundles. يُرسل الباحث حزمة معاملات مثل: [frontrun_tx, your_tx, backrun_tx]، وينفّذها محرك الكتل بشكل ذري بالترتيب. يحصل الضحية على سعر تنفيذ أسوأ بينما يجني الباحث الأرباح من الفارق.

كيف يعمل DontFront

DontFront هي ميزة في محرك كتل Jito تمنع الباحثين من وضع معاملاتهم قبل معاملتك في الحزمة.

آلية العمل: أضف أي مفتاح عام صالح لـ سولانا يبدأ بـ jitodontfront إلى أي تعليمة في معاملتك. يتعرف محرك الكتل على هذا البادئة ويفرض قاعدة: أي حزمة تحتوي على معاملتك يجب أن تضعها في الفهرس 0.

Without dontfront:  [frontrun_tx, your_tx, backrun_tx]  ← sandwich possible
With dontfront:     [your_tx, ...]                       ← your tx must be first

خطوة بخطوة

1. اختر عنواناً صالحاً يبدأ بـ jitodontfront (مثلاً، jitodontfront111111111111111111111111111111). لا يحتاج الحساب إلى الوجود على السلسلة؛ فهو لا يُقرأ أو يُكتب إليه أبداً. يمكنك التحقق من أن السلسلة النصية هي عنوان صالح باستخدام دالة assertIsAddress من @solana/kit، أو يمكنك إدخال العنوان في Solana Explorer للتحقق من صحته. إليك مثال على عنوان غير صالح.

2. أضفه كحساب للقراءة فقط وغير موقّع إلى أي تعليمة في معاملتك. ضع إشارة للقراءة فقط للحصول على أفضل سرعة إرساء. معظم البرامج (بما فيها System Program) تتجاهل الحسابات الإضافية التي تتخطى ما تتوقعه.

3. أرسل عبر محرك كتل Jito:

   • sendTransaction: https://mainnet.block-engine.jito.wtf/api/v1/transactions
   • sendBundle: https://mainnet.block-engine.jito.wtf/api/v1/bundles

   الوثائق: sendTransaction وsendBundle

4. يكتشف محرك الكتل البادئة jitodontfront ويفرض قواعد الترتيب.

ما الذي يحدث في محرك الكتل

عندما يرى محرك الكتل معاملة تحتوي على حساب jitodontfront:

• عبر sendTransaction: المعاملة محمية. لا يمكن لأي حزمة وضع معاملة أخرى قبلها
• عبر sendBundle: يجب أن تظهر المعاملة في الفهرس 0، وإلا تُرفض الحزمة بأكملها

المعاملات والحزم التي لا تحتوي على حساب jitodontfront لا تتأثر.

قواعد ترتيب الحزم

تُطبَّق هذه القواعد عندما تظهر معاملة jitodontfront في حزمة.

الأنماط المسموح بها

[tx_with_dontfront, tip]
[tx_with_dontfront, arbitrage, tip]
[tx_with_dontfront_signer1, tx_with_dontfront_signer1_and_signer2, tip]

معاملات DontFront متعددة في حزمة واحدة

يُسمح بوجود معاملات dontfront متعددة في حزمة واحدة عند استيفاء كلا الشرطين:

1. جميع معاملات dontfront متجاورة في مقدمة الحزمة
2. تشترك كل معاملة dontfront في موقّع واحد على الأقل مع معاملة dontfront الأولى

✅ [txA_df, txB_df, txC_df, arbitrage, tip]
   (contiguous at front, overlapping signers)

✅ [txA_df_signer1_signer2, txB_df_signer1_signer3, txC_df_signer2_signer4]
   (each shares a signer with txA)

الأنماط المرفوضة

❌ [tip, tx_with_dontfront]
   → dontfront tx is not at index 0

❌ [txA_df_signer1, txB_df_signer2]
   → no overlapping signer between txA and txB

❌ [trade, tx_with_dontfront, arbitrage, tip]
   → dontfront tx is not at the front

أمثلة التكامل

للاطلاع على وصفة كود سريعة، انظر مدخل MEV Protection في دليل الطهي.

TypeScript (@solana/kit)

الفكرة الأساسية هي دالة مساعدة تُلحق حساب dontfront بأي تعليمة:

import {
  address,
  AccountRole,
  type Instruction,
  type Address
} from "@solana/kit";

const DONT_FRONT: Address = address(
  "jitodontfront111111111111111111111111111111"
);

function withDontFront(ix: Instruction): Instruction {
  return {
    ...ix,
    accounts: [
      ...(ix.accounts ?? []),
      { address: DONT_FRONT, role: AccountRole.READONLY }
    ]
  };
}

ثم أرسل المعاملة الموقّعة إلى محرك كتل Jito بدلاً من عقدة RPC قياسية. استخدم دائماً ترميز base64. أصبح Base58 مهجوراً في واجهة برمجة تطبيقات Jito.

const response = await fetch(
  "https://mainnet.block-engine.jito.wtf/api/v1/transactions",
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      jsonrpc: "2.0",
      id: 1,
      method: "sendTransaction",
      params: [base64Tx, { encoding: "base64" }]
    })
  }
);

أفضل الممارسات

DontFront هو طبقة واحدة من طبقات الحماية. تجمع استراتيجية التخفيف القوية من MEV بين مناهج متعددة:

الحماية على مستوى المعاملة

• اضبط حدود الانزلاق بإحكام. أكثر دفاع فعّال ضد هجمات الساندويتش هو تقييد الانزلاق المقبول على عمليات المبادلة. نافذة الانزلاق الأضيق تُقلّل من هامش الربح المتاح للمهاجمين، مما يجعل معاملتك أقل جاذبية للاستهداف بهجمة الساندويتش.

• اضبط الإكراميات ورسوم الأولوية المناسبة. في أوقات الازدحام، تزيد الإكراميات ورسوم الأولوية الأعلى من احتمالية إرساء معاملتك/حزمتك بسرعة، مما يُقلّص النافذة الزمنية المتاحة للباحثين للتصرف. راجع وثائق Jito حول مبالغ الإكراميات لمزيد من التفاصيل حول كيفية ضبط الإكراميات المناسبة.

• حسّن استخدام وحدات الحوسبة. لكل كتلة عدد محدود من وحدات الحوسبة المتاحة (كما أن للحسابات عدداً محدوداً من وحدات الحوسبة المتاحة لكل كتلة). لضمان تعظيم احتمالية تضمين معاملتك/حزمتك في كتلة، ينبغي تحسين استخدامك لوحدات الحوسبة. راجع دليل كيفية تحسين استخدام الحوسبة على سولانا للتفاصيل.

خاص بـ DontFront

1. ضع إشارة للقراءة فقط على حساب dontfront. يعمل وضع علامة الكتابة لكن القراءة فقط تُحسّن سرعة الإرساء.

2. استخدم pubkey فريداً لـ dontfront لكل تطبيق. يعمل أي pubkey يبدأ بـ jitodontfront. استخدام متغيّر فريد (مثلاً، jitodontfront111111111111111111111111111123) يتيح لك تمييز الاستخدام لكل تطبيق عند فحص البيانات على السلسلة.

3. يدعم DontFront جداول بحث العناوين. يمكن تضمين حساب dontfront عبر ALT. لكن لا تستخدم ALTs لحسابات الإكراميات.

القيود

• محرك الكتل فقط. يُفرض DontFront من قِبل محرك كتل Jito. المعاملات المُرسلة مباشرةً إلى validators (متجاوزةً Jito) ليست محمية.

• ليس ضماناً. من وثائق Jito: "قد تساعد هذه الميزة في تقليل هجمات الساندويتش لكنها ليست مضمونة لتحقيق ذلك وليست حلاً لجميع أشكال تغيير ترتيب المعاملات، بما في ذلك أي ترتيب يجريه أطراف ثالثة."

• الشبكة الرئيسية/شبكة الاختبار فقط. هذه ميزة في محرك كتل Jito. لا تعمل على devnet أو localhost.

المراجع

• وثائق Jito: التخفيف من هجمات الساندويتش
• وثائق Jito: sendTransaction
• وثائق Jito: sendBundle
• وثائق Jito: حسابات الإكراميات
• وثائق Jito: مبالغ الإكراميات
• Tip Floor API
• @solana/kit على GitHub
• solana-sdk على crates.io