نموذج التنفيذ

كيف يعالج Rome EVM معاملات Ethereum على Solana — محاكاة عبر وكيل، وأوضاع ذرّية (VmAt) مقابل تكرارية (VmIt)، ودورة حياة المعاملة كاملة.

ينفذ Rome EVM بايتكود Solidity داخل برنامج على السلسلة في Solana. تشرح هذه الصفحة كيف تتم معالجة معاملات EVM.

دورة حياة المعاملة

1. يوقّع المستخدم معاملة EVM (MetaMask / ethers.js)
                    ↓
2. يستقبل Rome Proxy عبر eth_sendRawTransaction
                    ↓
3. يحاكي الوكيل المعاملة خارج السلسلة (محاكي Mollusk SVM)
   → يقدّر الغاز، ويتحقق من الذرّية، ويحدد الحسابات المطلوبة
                    ↓
4. يغلّف الوكيل معاملة EVM كتعليمة/تعليمات Solana
   → إذا كانت المعاملة تناسب معاملة Solana واحدة → ذرّية (VmAt)
   → إذا تجاوزت المعاملة ميزانية CU → تكرارية (VmIt)
                    ↓
5. ينفذ مدقق Solana التعليمة/التعليمات
   → يفسّر برنامج Rome EVM بايتكود EVM
   → استدعاءات CPI إلى برامج Solana الأخرى (إن وجدت)
                    ↓
6. تُثبَّت تغييرات الحالة في حسابات Solana
                    ↓
7. يفهرس Hercules الحدث → وينتج كتلة EVM

التنفيذ الذرّي (VmAt)

الوضع الافتراضي. تُنفَّذ معاملة EVM كاملة داخل معاملة Solana واحدة.

آلة الحالة: Lock → Init → Execute → Commit → GasTransfer → Exit

الخصائص:

• تنفيذ كل شيء أو لا شيء — إذا فشلت أي خطوة، تُرجَع المعاملة كاملة

• حوالي 1.4 مليون وحدة حوسبة متاحة لكل معاملة Solana

• مناسب للتحويلات، واستدعاءات العقود البسيطة، والمقايضات، ومعظم عمليات DeFi

• نهائية في أقل من ثانية (زمن كتلة Solana)

متى يُستخدم: يُختار تلقائيًا عندما يحدد المحاكي أن المعاملة تناسب ضمن ميزانية الحوسبة لمعاملة Solana واحدة.

التنفيذ التكراري (VmIt)

للعمليات كثيفة الحوسبة التي تتجاوز ميزانية معاملة واحدة. يُقسَّم تنفيذ EVM عبر عدة معاملات Solana.

كيف يعمل:

1. تنفذ كل خطوة (معاملة Solana) أكبر عدد ممكن من أوامر EVM opcode مما تسمح به ميزانية الحوسبة الخاصة بها — حجم خطوة متكيف، وليس عددًا ثابتًا

2. بعد كل خطوة، تُسلسل حالة VM (بتنسيق Borsh) إلى StateHolder حساب

3. تقوم الخطوة التالية بإلغاء تسلسل الحالة وتتابع التنفيذ

4. تُقفل الحسابات المعنية لمدة TTL 3-4 ثوانٍ أثناء التنفيذ متعدد الخطوات

آلة الحالة: FromStateHolder → Lock → Init → Execute → Serialize → NextIteration → ... → Completed

قفل الحسابات:

• RoLock (قراءة مشتركة فقط) — يمكن لعدة معاملات تكرارية أن تحتفظ به في الوقت نفسه

• RwLock (كتابة حصرية) — لا يمكن إلا لمعاملة واحدة تعديل الحساب في كل مرة

• TTL: 3 ثوانٍ (قياسي)، 4 ثوانٍ (عند استخدام جداول البحث عن العناوين)

متى يُستخدم: التحقق من الاقتران BN254، ونشر العقود الكبيرة، وسلاسل الاستدعاء العميقة، وأي عملية تتجاوز حوالي 1.4 مليون CU.

المحاكاة

قبل إرسال المعاملة إلى Solana، يحاكيها الوكيل خارج السلسلة باستخدام محاكي Mollusk SVM. هذا:

1. يقدّر استهلاك الغاز

2. يحدد ما إذا كان الوضع الذري أو التكراري مطلوبًا

3. يحدد جميع حسابات Solana التي ستلمسها المعاملة

4. يتحقق من أن المعاملة لن تفشل على السلسلة

ينفذ المحاكي منطق EVM نفسه مثل البرنامج على السلسلة — و entrypoint! تضمن الماكرو جداول توزيع متطابقة في كل من البرنامج وقواعد كود المحاكي.

يمكن أيضًا لـ Mollusk SVM تنفيذ برامج Solana BPF عشوائية أثناء المحاكاة، مما يعني أن eth_call و eth_estimateGas يتعامل بشكل صحيح مع استدعاءات CPI إلى SPL Token وJupiter وKamino وغيرها.

تعيين الحسابات

كل عنوان Ethereum يُعيَّن إلى PDA في Solana:

عنوان Ethereum (H160، 20 بايت)
    ↓
PDA = findProgramAddress(
    [chain_id, "ACCOUN_SEED", H160, bump],
    ROME_EVM_PROGRAM_ID
)
    ↓
حساب Solana (Pubkey، 32 بايت)

أنواع الحسابات المخزنة على السلسلة:

النوع	البذور	الغرض
الرصيد	[chain, "ACCOUN_SEED", H160, bump]	الـ nonce، الرصيد، كود العقد
التخزين	[chain, "STORAGE", H160, slot_index, bump]	تخزين العقد (256 خانة لكل حساب)
TxHolder	[signer, "TX_HOLDER_SEED", index, bump]	بيانات معاملة مرحَّلة (الحد الأقصى 80 كيلوبايت)
StateHolder	[signer, "STATE_HOLDER_SEED", index, bump]	حالة VM مُسلسلة بين التكرارات

حسابات الحفظ

تُقيَّد معاملات Solana بحجم 1,232 بايت. يمكن أن تكون معاملات EVM — خاصة نشر العقود — أكبر بكثير.

آلية التقسيم:

1. يقسّم SDK المعاملة المشفّرة بـ RLP إلى أجزاء

2. يُكتب كل جزء إلى TxHolder حساب عبر TransmitTx تعليمات

3. بمجرد تخزين جميع الأجزاء، فإن DoTxHolder تعليمة تُجمّع وتنفذ المعاملة كاملة

4. الحد الأقصى لحجم الحفظ: 80 كيلوبايت لكل TxHolder

هذا شفاف تمامًا للمطوّر — إذ يتولى Rome SDK التقسيم وإعادة التجميع تلقائيًا.

أنواع المعاملات المدعومة

النوع	EIP	الوصف
القديم	—	معاملات Ethereum التقليدية
قائمة الوصول	EIP-2930	أنماط الوصول إلى الحالة المحسّنة
رسوم ديناميكية	EIP-1559	الرسوم الأساسية + رسوم الأولوية
إيداع	النوع 0x7E	معاملات الإيداع، مثل تسوية الواردات من الجسر

حالة مُسجَّلة في سجل

يستخدم Rome EVM نموذج حالة مُسجَّلًا لإدارة تغييرات الحالة أثناء التنفيذ:

• تُتتبَّع جميع التغييرات (nonce، الرصيد، التخزين، الكود) في السجل

• تدفع عمليات CALL/CREATE المتداخلة إطارات لقطة

• عند الرجوع: تُعاد إدخالات السجل إلى اللقطة

• عند النجاح: تُثبَّت التغييرات في حسابات Solana

• تُنفَّذ تعليمات CPI غير الخاصة بـ EVM فورًا (تضمن ذرّية Solana نفسها الصحة)

ما التالي

• ميزانية الحساب — تكاليف CU واستراتيجيات التحسين

• القيود — الحدود والقيود المهمة