> 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/rome-zk-evm/run-a-rollup.md).

# شغّل rollup

سجّل وشغّل سلسلة Rome ZK EVM الخاصة بك على Solana devnet باستخدام مشغّل rollup v0.3.0.

الـ `./rollup` يبدأ المشغّل سلسلة واحدة مقابل برامج devnet المشتركة لـ Solana التابعة لروما. أنت تشغّل عقدتها وتدفع تكاليف Solana الخاصة بها. لا تقوم بنشر برامج التسوية بنفسك. التسجيل غير مقيّد بإذن، لكن الجذور المُثبتة تحتاج إلى مفتاح تحقق خاص بالسلسلة تُسجّله روما.

تستخدم هذه الصفحة **v0.3.0**. [دليل devnet الكامل](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/docs/RUN-ON-DEVNET.md) يغطي كل إعداد وخطوة فشل واستعادة.

## قبل أن تبدأ

استخدم جهاز Linux x86-64 مع bash 4 أو أحدث، وGit، وDocker Engine 28 أو أحدث مع Compose، وcurl وjq وopenssl وSolana CLI وPython 3.11 أو أحدث. ستحتاج إلى نقطة نهاية RPC لـ Solana devnet، ومفتاح دفع Solana ممول، وهو أيضًا سلطة السلسلة لديك، ومفتاح توقيع للمُسلسِل. احتفظ بكلا الملفين خاصين وقابلين للقراءة من قبل مستخدم الحاوية 999. يشرح الدليل كيفية إنشائهما.

خصّص حوالي **7 SOL على devnet** للمُدفع. يجمّد التسجيل 5 SOL؛ `./rollup check` ويتوقع بقاء ما لا يقل عن 1 SOL للإرسال والإيجار. يصبح الإيداع قابلاً للاسترداد بعد أول جذر نهائي أو عشرة جذور منشورة. إذا استُعيدت السلسلة قبل ذلك، يذهب الإيداع إلى الخزانة. وتحتاج السلسلة أيضًا إلى عنوان مستلم رسوم EVM تتحكم فيه.

لتسوية الجذور، تحتاج إلى مضيف مُثبت مزود ببطاقة NVIDIA GPU واحدة بذاكرة تزيد عن 30 GB. بطاقة بسعة 24 GB صغيرة جدًا لخطوة الإثبات النهائية. [مضيف المُثبت](/ar/rome-zk-evm/prover-host.md) يوفر ميزانية الذاكرة RAM والقرص. يمكن للعقدة أن تعمل وتنشر الدُفعات قبل أن يصبح المُثبت جاهزًا، لكن لن يكون أي من جذورها نهائيًا.

## ابدأ العقدة

انسخ الإصدار واشتغل من دليل rollup الخاص به:

```sh
git clone --branch v0.3.0 https://github.com/rome-protocol/solana-zk-evm.git
cd solana-zk-evm/deploy/rollup
cp .env.example .env
cp chain.toml.example chain.toml
```

اضبط Solana RPC ومواقع الموقّع و `ROME_ZK_TAG=v0.3.0` في `.env`، واحتفظ بـ `PROGRAMS_JSON=programs.devnet.json`. اضبط `ROME_ZK_GUEST_TAG=v0.3.0` و `ZISK_RELEASE=1.3.1-alpha` لبناء الضيف لاحقًا. أبقِ RPC مربوطًا بـ loopback للتشغيل المحلي الأول. اترك `PROVER` غير مُعيّن حتى يصبح الضيف ومفتاحه جاهزين.

اضبط `genesis.fee_recipient` في `chain.toml` إلى عنوان EVM الخاص بك. لا تختر معرّف سلسلة. تستنتج التسوية معرّفًا من المُدفِع وعدد مرات تسجيله؛ `init` يقرأه قبل إرسال أي شيء. نحو نصف جميع المعرّفات كبيرة جدًا على MetaMask. إذا كان معرّفك من هذا النوع، `init` يتوقف مع `ChainIdNotWalletSafe`؛ أنشئ مفتاح مُدفِع جديدًا، ووجّه `PAYER_KEYPAIR_PATH` إليه ثم شغّل `init` مرة أخرى.

تبدأ السلسلة الجديدة بأرصدة صفرية. إذا أعلنت رصيدًا مدعومًا واحدًا للحصول على الغاز قبل فتح الإيداعات، فقم بتجميد المبلغ نفسه من SOL المغلف في خزنة السلسلة قبل طلب مفتاح التحقق.

```sh
./rollup init
./rollup register --dry-run
./rollup register --confirm
./rollup up
./rollup check
```

`init` يعرض إعدادات genesis وإعدادات الخدمة. `register --confirm` يجمد إيداع 5 SOL وينشئ مؤشر الدُفعات. `up` يبدأ عقدة المُسلسِل، ومُجمّع الدُفعات، وderive، وعقدة التحقق. `تحقّق` يذكر أي خدمة مفقودة، ثم يقارن معرّف السلسلة والرؤوس وتقدم مُجمّع الدُفعات وصندوق الوارد والجذور. شغّله مرة أخرى بعد أن تتاح للدُفعات فرصة الإغلاق؛ ففحص تقدم أول دفعة يسجل عينة فقط.

من دون مُثبت، يقدّم المُسلسِل خدمة RPC، وينشر مُجمّع الدُفعات بيانات المعاملات إلى صندوق الوارد، وderive يعيد بناء السلسلة. دفعة صندوق الوارد ليست جذر تسوية نهائيًا. حتى جذر genesis ينتظر إثباتًا.

## الانتقال من الدُفعات إلى الجذور النهائية

ابنِ الضيف لـ genesis الخاصة بسلسلتك:

```sh
./rollup guest-build
```

يستخدم البناء ضيف v0.3.0 وZisK 1.3.1-alpha. وينتج برنامج الضيف الخاص بالسلسلة وبيانات تعريف مفتاح التحقق. يتطلب حساب `programVK` مفاتيح إثبات ZisK وحوالي 36 GB من RAM. لا يؤدي تسجيل السلسلة إلى تسجيل مفتاح تحقق. أرسل [طلب مفتاح التحقق](/ar/rome-zk-evm/verification-key.md) بعد البناء. تتحقق روما من genesis والضيف لديك، ثم تسجل المفتاح مع فتحة تفعيل.

على مضيف المُثبت، اضبط `PROVER=on` والضيف، وبيانات التحقق الوصفية وإعدادات ZisK الموضحة في دليل التشغيل الكامل. بعد تفعيل المفتاح:

```sh
./rollup init
./rollup up
./rollup check
```

تحقق من أن `خدمة المُثبت` و `مفتاح التحقق` تجتاز العناصر الفحص. يعمل المُثبت على دفعات صندوق الوارد بالترتيب. كل إثبات صالح ينشر جذرًا يصبح نهائيًا بمجرد هبوط معاملة Solana الخاصة به.

## أنشئ الكتلة الأولى

من دون رصيد genesis مدعوم، لا تملك السلسلة غازًا لأي معاملة حتى تُفتح الإيداعات. تتطلب الإيداعات أول جذر مُثبت. الإعداد الافتراضي `empty_block_interval_secs = 0` يترك سلسلة خاملة من دون كتل، لذا اضبطه على `60` أقل من `[profile]` في `chain.toml` بعد أن يصبح المفتاح نشطًا ويكون المُثبت قيد التشغيل. اعرض وأعد التشغيل:

```sh
./rollup init
./rollup up
./rollup check
```

بمجرد أن يصبح الجذر الأول نهائيًا، أعد ضبط الفاصل إلى `0` وأعد تشغيل `init` و `up` إلا إذا كنت تريد كتلًا فارغة منتظمة. تشغيلها أثناء انتظار روما لتسجيل المفتاح يخلق تراكمًا. يجب إثبات كل دفعة بالترتيب.

مع فاصل للكتل الفارغة قدره 60 ثانية وإغلاق للدفعة كل 60 ثانية، تُنتج السلسلة نحو دفعة واحدة في الدقيقة، أو نحو 1,440 يوميًا. على devnet، كل جذر مُثبت كلّف المُدفِع حوالي **0.003 SOL**: حوالي 0.002 SOL في إيجار الحسابات المعلّقة، ورسوم تسوية مقدارها 0.001 SOL، إضافة إلى رسوم معاملة. هذا المعدل يقارب 4.4 SOL يوميًا قبل تكاليف نشر صندوق الوارد. يظل إيجار الحسابات المعلّقة مُجمّدًا بالإعدادات الافتراضية. مع إيقاف الكتل الفارغة، لا تُغلق السلسلة الخاملة أي دفعات ولا تدفع أي تكاليف نشر.

لقبول الإيداعات، أنشئ أولًا الخزنة، ثم فعّل إعدادات الخروج بعد تأخيرها، وافتح قائمة انتظار للإيداع. تلك الأوامر وعمليات التحقق موجودة في [الودائع والسحوبات](/ar/rome-zk-evm/deposits-and-withdrawals.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/rome-zk-evm/run-a-rollup.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.