> 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/alttbyqat-ala-rome/bloom/lanes.md).

# المساران

نشر رمز واحد، وعالما محافظ اثنان. ينفّذ كلا المسارين **العقود نفسها** مع **نفس بوابة الامتثال** — يختلفان فقط فيمن يوقّع وكيف تصل المعاملة إلى السلسلة.

## مسار EVM

أدوات Ethereum القياسية، دون تغيير: يوقّع المحفظة معاملة EVM، ويقبلها نهائي JSON-RPC الخاص بالسلسلة، ويفرض عقد الرمز قائمة السماح. لا يوجد شيء خاص بـ Bloom لدمجه — التكلفة المقاسة لتحويل مقيّد هي نحو 3.1M غاز (غاز Rome مُقوَّم بـ USDC؛ والتحويل الأصلي البسيط هو نحو 1.48M للمقارنة).

## مسار Solana

تُشغّل محفظة Solana العقود نفسها الخاصة بـ EVM **أصليًا — لا يوجد مفتاح EVM في أي مكان**:

1. **الهوية.** عنوان المستخدم على جانب EVM هو *اصطناعي*: مشتق حتميًا كـ `keccak256(solana_pubkey)[12..32]`. يستخرجه برنامج Rome EVM على السلسلة من الموقّع الفعلي للمعاملة — لا يمكن انتحالُه، ولا يوجد له مفتاح خاص secp256k1، لذا **توقيع Solana هو الشيء الوحيد القادر على تشغيل هذا العنوان**.
2. **الاكتشاف.** يطلب العميل من RPC الخاص بالسلسلة (`rome_emulateCallAccounts`) معرفة حسابات Solana التي ستلمسها استدعاءة EVM؛ كما يحدد المحاكاة أيضًا أيّها قابل للكتابة ( `القيمة` الخاصّة بالاستدعاء يجب تضمينها — وتعتمد قابلية كتابة حساب رصيد المستلم عليها).
3. **الإرسال.** يبني العميل `DoTxUnsigned` تعليمة — *غير موقعة* حمولة EIP-1559 مخوّلة بواسطة توقيع Solana — بالإضافة إلى تعليمات ميزانية الحوسبة (heap بحجم 250KB، و1.35M CU) وحساب اكتشاف مجمع الرسوم الذي يهمله. توقّع المحفظة معاملة Solana واحدة؛ وانتهى.

   **الحجم، مقاسًا على هذا النشر في 2026-07-30:** تُحلّ عملية شراء من واجهة المتجر إلى **22 حسابًا** وتُسلسل إلى **1,061 بايت** مقابل حد legacy البالغ 1232 بايت — هامش 171 بايت، أي نحو خمسة حسابات إضافية. لذلك فهي لا تحتاج اليوم إلى جدول بحث. أما الحالة التي تلمس أكثر — حساب رمز مميّز مرتبط ما زال لم يُنشأ، أو حامل لأول مرة — فقد تتجاوز ذلك، وبعد 1232 بايت يعود العميل إلى معاملة v0 عبر جدول بحث عن العناوين ينشئه لهذا الغرض.

   **هذا التراجع الاحتياطي مكلف للمحفظة:** كل جزء من تمديد ALT وإعادة إرسال v0 هو `signTransaction`منفصلة، لذا تصبح عملية شراء واحدة ثلاث أو أربع مطالبات. لدى Hadrian بالفعل جدول dApp دائم يحتفظ بحسابات هذه العقود — والرجوع إليه هو الحل، وهو ما لا يستطيع عميل المسار فعله بعد.
4. **التأكيد.** تُؤكَّد المعاملة على Solana؛ وتلحق بها رؤية EVM بعد لحظة (تقوم الأدوات باستطلاع nonce قبل إرسال الاستدعاء التالي).

### فقط Atomic — الحد الفاصل الصارم للمسار

`DoTxUnsigned` هو **معاملة EVM واحدة تُنفَّذ داخل معاملة Solana واحدة** بواسطة VM الذرّي الخاص بـ Rome. الـ VM التكراري — الذي يوزّع تنفيذ EVM واحدًا عبر عدة معاملات Solana — لا يمكن الوصول إليه عبر هذا المسار بعد، لذا **أي استدعاء لن يَسَعُه التنفيذ الذرّي لا يمكنه سلوك هذا المسار إطلاقًا.** لا يوجد تراجع احتياطي يمكن اللجوء إليه، ولا ينبغي إضافة واحد؛ فحل استدعاء لا يناسب هو استدعاء أصغر.

غالبًا ما يُخلَط بين شيئين وهذا ليس أيًّا منهما:

* **التراجع الاحتياطي v0 + جدول البحث** هو *غلافًا*أكبر، لا تنفيذًا مختلفًا: التعليمة نفسها الواحدة، محمولة داخل صيغة معاملة فيها مجال لمفاتيح حسابات أكثر بكثير. المقاس اليوم يبيّن أن عملية شراء واجهة المتجر لا تحتاجه (1,061 من 1232 بايت)، وأي استدعاء يحتاجه سيظل ذرّيًا.
* **رحلة متعددة الخطوات ليست تنفيذًا متعدد المقاطع.** Bloom's `Run` تسمّي خطواتها *مقاطع* — الموافقة ثم الشراء — وكل واحدة منها **معاملة كاملة، موقّعة بشكل منفصل، وذرّية بحد ذاتها**. تسمي Rome أيضًا المقاطع في تنفيذ واحد مُجزّأ بالمقاطع. هذا التطبيق يملك الأول ولا ينبغي أن يطلب الثاني أبدًا. الكلمة تتقاطع؛ أما الآليات فلا.

كل تدفّق في الجدول أدناه هو معاملة ذرّية واحدة، وأثقلها يستخدم قليلًا فوق نصف سقف الحوسبة لكل معاملة — لذا فالحد الفاصل ليس قريبًا لأي شيء يفعله Bloom اليوم.

مقاس على Rome devnet، توقيع واحد لكل حالة — النطاقات الملاحظة عبر سلسلتين:

| تدفّق مسار Solana                                                     | CU         |
| --------------------------------------------------------------------- | ---------- |
| تحويل RWA مقيّد                                                       | \~339–381K |
| موافقة wUSDC                                                          | \~189–191K |
| شراء من واجهة المتجر (الموافقة + الشراء = توقيعان إجمالًا)            | \~730–796K |
| تفريغ جانب النقد إلى حساب الرمز المميز الخاص بالمحفظة                 | \~42–54K   |
| تحويل قيمة بسيط                                                       | \~47K      |
| `TestApprover.approve` — قبول ضمن قائمة السماح، **موقّعة من المحفظة** | 220,794    |

للمقارنة، سقف الحوسبة لكل معاملة في Solana هو 1.4M CU — وأثقل تدفق في Bloom يستخدم قليلًا فوق نصفه فقط.

## الحضانة: لماذا يبقى RWA عند الاصطناعي

سؤال التصميم الذي يجب أن يجيب عنه كل أصل مقيّد الصلاحية: *هل يمكن للرمز أن يتسرّب خارج محيط الامتثال؟* على مسار Solana، الإجابة هي بنيوية لا سياساتية:

* **يعيش RWA كحالة EVM على السلسلة.** أرصدةه هي تخزين داخل حسابات برنامج Rome EVM. لا يوجد **SPL mint** له، ولا تمثيل لحساب رمز، ولا شيء أصلي في Solana يمكن نقله. (هذا مقصود — فنسخة ملفوفة/متماثلة ستكون باب الهروب.)
* **البنية الطرفية على جانب Solana لا تستطيع لمسه.** مقاطع نقل الأصول في المسار (`create_ata`، تحويلات SPL، التفريغ) تعمل على حسابات رموز SPL؛ أما أرصدة التخزين في EVM فلا يوجد لها مثل هذا الحساب. لا توجد تعليمة تنقل رصيد EVM إلى حساب رمز في Solana.
* **توقيع المالك على Solana هو وحده الذي يقود الاصطناعي**، وكل حركة يمكنه التعبير عنها هي استدعاء لعقد الرمز — الذي يطبّق بوابة قائمة السماح — لذا فإن تحويلًا إلى عنوان غير مدرج في القائمة يُرفَض بالطريقة نفسها سواء وقّعه مفتاح EVM أو مفتاح Solana.
* **جانب النقد هو الاستثناء المقصود.** wUSDC (العائد، متحصلات البيع) مدعوم بـ SPL و *يجب* أن يعود ذهابًا وإيابًا: مقطع الخروج (`transfer_spl`) ينقله من الاصطناعي إلى حساب الرمز المرتبط الخاص بالمحفظة، مع التحقق من البداية إلى النهاية. يبقى الأصل داخل المحيط؛ بينما يتدفق النقد بحرية.

نتيجتان عمليتان، بصياغة واضحة: واجهة مستخدم محفظة Solana لن تعرض حيازة RWA (لا يوجد رمز SPL ليُدرَج) — وتطبيق Bloom هو واجهة المواضع؛ كما أن فقدان مفتاح Solana يُستعاد عبر عملية الجهة المصدرة ([COMPLIANCE.md](/ar/alttbyqat-ala-rome/bloom/compliance.md#issuer-powers-transfer-agent-shaped))، لا بنقل الأصل خارج القناة — وهي بالضبط الخاصية التي يريدها الأصل المقيّد الصلاحية.


---

# 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/alttbyqat-ala-rome/bloom/lanes.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.