> 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 معاملات Ethereum على Solana — محاكاة الوكيل، والأوضاع الذرّية (VmAt) مقابل التكرارية (VmIt)، ودورة حياة المعاملة الكاملة.

يُشغِّل 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 واحدة.

**آلة الحالة:** `قفل → تهيئة → تنفيذ → تثبيت → تحويل الغاز → خروج`

**الخصائص:**

* تنفيذ بكل شيء أو لا شيء — إذا فشلت أي خطوة، فستُلغى المعاملة بأكملها
* \~1.4 مليون وحدة حساب متاحة لكل معاملة Solana
* مناسب للتحويلات، واستدعاءات العقود البسيطة، والمقايضات، ومعظم عمليات DeFi
* نهائية دون ثانية واحدة (وقت كتلة Solana)

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

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

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

**كيف يعمل:**

1. تُنفَّذ كل خطوة (معاملة Solana) **من تعليمات EVM البرمجية بقدر ما يتسع له ميزانيتها الحاسوبية** — حجم خطوة تكيفي، وليس عددًا ثابتًا
2. بعد كل خطوة، تُسلسل حالة VM (بتنسيق Borsh) إلى `StateHolder` حساب
3. تقوم الخطوة التالية بإلغاء تسلسل الحالة وتواصل التنفيذ
4. الحسابات المعنية مقفلة بمؤقت TTL لمدة **3-4 ثوانٍ** أثناء التنفيذ متعدد الخطوات؛ وتُحدَّد الجلسة بحد أقصى **160 خطوة**؛ وبعد ذلك، تطلق الخطوة التالية أقفال الجلسة وتنهيها دون تثبيت أي شيء

**آلة الحالة:** `من StateHolder → قفل → تهيئة → تنفيذ → تسلسل → التكرار التالي → ... → مكتمل`

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

* واحد **قفل حصري** لكل حساب مُدار (حسابات الرصيد والتخزين) — لا يمكن إلا لجلسة تكرارية واحدة امتلاك الحساب في وقت واحد؛ وتُرفض المعاملة الذرية التي تكتب حسابًا مقفلاً مع `AccountLocked` حتى ينقضي القفل، ثم يعيد العميل الإرسال
* **TTL:** 3 ثوانٍ، تُجدَّد مع كل خطوة (4 ثوانٍ عندما تلامس الجلسة أكثر من 28 حسابًا)
* **تُرفض عمليات CPI من المسار القديم** داخل معاملة تكرارية (`CpiProhibitedInIterativeTx`); تُجهَّز آثار المسار المخزَّن مؤقتًا وتُثبت في النهاية

**متى يُستخدم:** عمليات نشر العقود الكبيرة، ومكدسات الاستدعاء العميقة، وأي عملية تتجاوز \~1.4 مليون وحدة حساب. ولا تحتاج عملية التحقق من BN254 pairing وحدها إليه؛ راجع [ميزانية الحوسبة](/ar/almfahym-alasasyh/compute-budget.md).

## المحاكاة

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

1. يقدّر استهلاك الغاز
2. يحدد ما إذا كان الوضع الذري أو التكراري مطلوبًا
3. يحدد جميع حسابات Solana التي ستلمسها المعاملة
4. يتحقق من أن المعاملة لن تفشل على السلسلة

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

**Mollusk SVM** يمكن لـ 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 KB) |
| StateHolder | `[signer, "STATE_HOLDER_SEED", index, bump]` | حالة VM المُسلسلة بين التكرارات                |

## حسابات الحامل

يرسل Rome معاملات Solana **v1**، والتي تقتصر على 4 KB (4,096 بايت) و64 عنوانًا. يمكن أن تكون معاملات EVM — وخاصة عمليات نشر العقود — أكبر بكثير.

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

1. يقسم SDK المعاملة المشفرة بـ RLP إلى أجزاء
2. يُكتب كل جزء إلى `TxHolder` حساب عبر `TransmitTx` تعليمات
3. بمجرد تجهيز جميع الأجزاء، `DoTxHolder` تعليمات DoTxHolder تقوم بتجميع وتنفيذ المعاملة الكاملة
4. الحد الأقصى لحجم الحامل: **80 كيلوبايت** لكل TxHolder

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

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

| النوع               | EIP        | الوصف                                                                                                                                                                                     |
| ------------------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| قديم                | —          | معاملات Ethereum التقليدية                                                                                                                                                                |
| قائمة الوصول        | EIP-2930   | أنماط وصول محسّنة إلى الحالة                                                                                                                                                              |
| رسوم ديناميكية      | EIP-1559   | الرسوم الأساسية + رسوم الأولوية                                                                                                                                                           |
| EIP-1559 غير موقَّع | —          | تطبيق `0x02`-typed body بدون توقيع secp256k1، ومصرَّح به بدلًا من ذلك بتوقيع Ed25519 لمحفظة Solana (مسار Solana؛ راجع [استدعِ EVM من Solana](/ar/adlh-almtw-ryn/call-evm-from-solana.md)) |
| إيداع               | النوع 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.