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

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

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

1. يوقّع المستخدم معاملة EVM (MetaMask / ethers.js)
                    ↓
2. يستقبل Rome Proxy عبر eth_sendRawTransaction
                    ↓
3. يحاكي الـ Proxy المعاملة خارج السلسلة (محاكي Mollusk SVM)
   → يقدّر الغاز، ويتحقق من الذرّية، ويحدّد الحسابات المطلوبة
                    ↓
4. يغلّف الـ Proxy معاملة 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. تنفّذ كل خطوة تقريبًا 500 من شفرات عمليات EVM

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

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

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

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

قفل الحساب:

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

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

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

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

المحاكاة

قبل إرسال معاملة إلى Solana، يحاكيها الـ Proxy خارج السلسلة باستخدام محاكي 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	الوصف
Legacy	—	معاملات Ethereum التقليدية
Access List	EIP-2930	أنماط محسّنة للوصول إلى الحالة
Dynamic Fee	EIP-1559	رسوم أساسية + رسوم أولوية
Deposit	Type 0x7E	معاملات إيداع L2 (مبادَر بها من قِبل المُسلسِل)

حالة مُدوَّنة بالسجل

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

• تُتبع جميع التغييرات (nonce، الرصيد، التخزين، الشيفرة) في سجل

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

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

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

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

ما التالي

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

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

• دورة حياة المعاملة — شرح تفصيلي خطوة بخطوة