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

ينفّذ 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 تكفل الصحة)

## ما التالي

* [ميزانية الحوسبة](/ar/almfahym-alasasyh/compute-budget.md) — تكاليف CU واستراتيجيات التحسين
* [القيود](/ar/almfahym-alasasyh/constraints.md) — الحدود والقيود المهمة
* [دورة حياة المعاملة](https://github.com/rome-protocol/docs/blob/main/core-concepts/transaction-lifecycle.md) — شرح تفصيلي خطوة بخطوة


---

# Agent Instructions: 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:

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

The question should be specific, self-contained, and written in natural language.
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.