استدعاء EVM من Solana
اسمح لمحفظة Solana بقيادة عقود EVM على Rome — من دون مفتاح Ethereum. توقّع المحفظة، وتذهب معاملةها إلى Solana.
آخر تحديث
هل كان هذا مفيدا؟
اسمح لمحفظة Solana بقيادة عقود EVM على Rome — من دون مفتاح Ethereum. توقّع المحفظة، وتذهب معاملةها إلى Solana.
عكس استدعِ سولانا من EVM: تستدعي محفظة سولانا (مثل Phantom) أي عقد EVM على Rome مباشرةً، مع من دون مفتاح إيثريوم. هكذا Aerarium و Rome DEX تتيح للمستخدمين الأصليين لسولانا مشاركة العقود نفسها مع مستخدمي EVM.
الطريقة ذات الاستدعاء الواحد هي submitRomeTxSolanaLane; تشرح هذه الصفحة ما يفعله.
الهوية EVM لمحفظة سولانا هي العنوان الاصطناعي — آخر 20 بايت من keccak256 للمفتاح العام لسولانا المكوّن من 32 بايت:
synthetic_evm_address = keccak256(solana_pubkey)[12:]هذا هو msg.sender عندما تستدعي المحفظة عقدًا، والهوية الثابتة التي يوجد تحتها الـ nonce والتخزين. الاشتقاق مثبت في البروتوكول، لذا تُطابِق المحفظة دائمًا العنوان نفسه.
import { syntheticAddress } from "@rome-protocol/sdk";
const from = syntheticAddress(solanaPubkey); // 0x… 20 bytesالرصيد القابل للإنفاق للمستخدم الأصلي لسولانا يوجد في محفظة سولانا (كـرموز SPL)، ويظهر على جانب EVM بنسبة 1:1 بوصفه غلاف ERC20SPL (مثل wUSDC). العنوان الاصطناعي لا يحتفظ بشيء عند السكون، لذا تتدفق القيمة عبر من خلاله — وكل خطوة موقعة من محفظة سولانا:
التهيئة (مرة واحدة). لا يوجد PDA للمصادقة الخارجية للعنوان الاصطناعي الجديد تمامًا حتى create_pda يُنفَّذ — وتُوقَّع التحويلات أدناه بواسطة ذلك الـ PDA. submitRomeTxSolanaLane يُهيّئه تلقائيًا عند أول استخدام (أو استدعِ provisionSynthetic لخطوة "تفعيل" صريحة؛ تحقّق باستخدام isSyntheticProvisioned).
ساق التمويل (المحفظة → العنوان الاصطناعي). انقل الرمز من ATA الخاص بالمحفظة إلى الخاص بالعنوان الاصطناعي — خطوة ActivateAta التفعيل، المبنية بواسطة buildFundLeg. الآن wrapper.balanceOf(synthetic) يقرأ ذلك الرصيد، لذا ينفقه العنوان الاصطناعي كرمز ERC-20 عادي (transfer / transferFrom) — وليس كأصلٍ أصلي msg.value، لأنه لا يملكه.
الاستدعاء(ات) (DoTxUnsigned). ينفّذ العنوان الاصطناعي معاملة/معاملات EVM — مثل approve ثم خزنة deposit تسحب عبر transferFrom.
ساق السحب (العنوان الاصطناعي → المحفظة). بعد أن يضع السحب / الاقتراض / المطالبة رموزًا في العنوان الاصطناعي، buildSweepLeg يعيدها إلى ATA الخاص بمحفظة المستخدم نفسها (HelperProgram.transfer_spl)، وبذلك ينتهي صافي العنوان الاصطناعي إلى لا شيء.
submitRomeTxSolanaLane يقوم بكل ذلك. الآلية:
أنشئ معاملة EIP-1559 غير موقعة بـ من = العنوان الاصطناعي — من دون توقيع secp256k1.
اكتشف الحسابات — استدعِ rome_emulateCallAccounts باستخدام من, حقل, البيانات, و القيمة (عندما يكون الاستدعاء قابلاً للدفع). تمرير القيمة مهم: فالوكيل يحاكي الحقيقي الاستدعاء، لذا يتم تخصيص أي كتابة تخزين تعتمد على القيمة — مثل خانة mapping جديدة — ويُعاد حساب سولانا الخاص بها. احذفه وسيغيب ذلك الحساب، وتفشل المعاملة مع "instruction modified data of a read-only account."
جمّع معاملة سولانا: اثنتين من ComputeBudget تعليمات (يحتاج EVM الخاص بـ Rome إلى حد أعلى لوحدات الحوسبة CU ≈1.35M وإطار heap كبير ≈250 KB — إعدادات سولانا الافتراضية تفشل) + DoTxUnsigned التعليمات (RLP غير الموقّع + الحسابات المكتشفة) + محفظة الخزانة (يدفع التنفيذ لها رسومًا صغيرة؛ ويستثنيها الاكتشاف، لذا يُلحقها SDK).
توقّع المحفظة وتُرسل. تقوم محفظة سولانا بتوقيع معاملة سولانا (Ed25519) وإرسالها إلى Solana RPC — وليس إلى الوكيل. يتحقق وقت تشغيل سولانا من التوقيع؛ وعلى السلسلة، يشتق البرنامج msg.sender من ذلك الموقّع. فالسلطة هي توقيع سولانا، لا توقيع إيثريوم. (يُستخدم الوكيل فقط للمحاكاة/الاكتشاف في الخطوة 2.)
يملك PDA الخاص بالمستخدم (["EXTERNAL_AUTHORITY", synthetic_address]) حسابات رموزهم ويوقّع استدعاءات SPL البينية (CPIs) نيابةً عنهم — لذا يمكن لمستخدم سولانا الإيداع والاقتراض والمبادلة وتوفير السيولة بالكامل من Phantom.
Aerarium — يدير Compound v3 (الإيداع / الاقتراض) من Phantom عبر DoTxUnsigned.
Rome DEX — يتداول مسار سولانا ويوفّر السيولة في المجمع نفسه مثل مسار EVM.
كلاهما أصلي لسولانا من دون جسر أو محفظة ثانية — يجعل العنوان الاصطناعي مفتاح Phantom واحدًا حساب EVM من الدرجة الأولى.
استدعِ سولانا من EVM — الاتجاه الآخر، عبر CPI
التوافق البيني للرموز — كيف تُشارك الأرصدة عبر EVM وسولانا
آخر تحديث
هل كان هذا مفيدا؟
هل كان هذا مفيدا؟