> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/ar/almfahym-alasasyh/execution-model.md).

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

ينفذ 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 نفسها الصحة)

## ما التالي

* [ميزانية الحساب](/ar/almfahym-alasasyh/compute-budget.md) — تكاليف CU واستراتيجيات التحسين
* [القيود](/ar/almfahym-alasasyh/constraints.md) — الحدود والقيود المهمة


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rome.builders/ar/almfahym-alasasyh/execution-model.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.