إنتقل إلى المحتوى الرئيسي

محافظ EVM: نافذة التفويض

لا يوجد في معاملات Ethereum حقل يمكن أن يحمل توقيعًا ثانيًا، كما تطبّق الشبكة إعداد PQC على مستوى السلسلة كلها لا على كل مسار على حدة. لذلك تُوقَّع المعاملة المرسلة على مسار EVM في QoreChain بـ secp256k1 فقط، ولا يوفّر QoreSign توقيعًا هجينًا لـ EVM (إذ ترمي assertHybridLane("evm") الخطأ LANE_NOT_AVAILABLE).

بدلًا من ذلك، لا تقبل الشبكة معاملة EVM إلا إذا كان لمرسلها مفتاح ML-DSA-87 مسجَّل ونافذة تفويض EVM سارية تغطيها. تُفتح النافذة من المسار الأصلي بمعاملة موقَّعة توقيعًا هجينًا، فيفوّض المفتاح ما بعد الكمّي نشاط EVM مسبقًا. أما معاملة EVM نفسها فتُوقَّع بـ secp256k1 فقط. تفرض الشبكتان العامتان كلتاهما هذا الشرط (ميزة البروتوكول evm-pqc-authorisation-window، ويمكن قراءتها بالدالة fetchProtocolFeatures في QoreChain SDK أو عبر /qorechain/pqc/v1/protocol_features).

خطوات حساب EVM​

  1. سجّل مفتاح ML-DSA-87 للحساب على المسار الأصلي (buildRegisterPqKeyMessage، راجع التسجيل). في حساب eth_secp256k1 تملك بايتات العنوان العشرون نفسها صيغة qor1؛ استخدمها بوصفها sender.
  2. افتح نافذة بمعاملة موقَّعة توقيعًا هجينًا على المسار الأصلي: ارتفاع انتهاء الصلاحية، والحد الأقصى لعدد معاملات EVM، والحد الأقصى للقيمة، واختياريًا العقود التي يجوز استدعاؤها. يوفّر QoreChain SDK مُركِّبات لرسائل النافذة.
  3. أرسل معاملات EVM من أي محفظة EIP-1193 ما دامت النافذة مفتوحة. خارج النافذة، أو بعد تجاوز حدودها، ترفضها الشبكة، فلا يستطيع مفتاح secp256k1 وحده نقل قيمة على مسار EVM.

عندما تضيف الشبكة PQC لكل مسار إلى مسار EVM، سيضيف QoreSign وضع EVM هجينًا في إصدار فرعي جديد.

MetaMask ومحافظ EIP-1193 الأخرى​

لا تستطيع MetaMask ومحافظ EIP-1193 الأخرى إضافة توقيع ML-DSA-87 إلى eth_sendTransaction؛ لذا فإن النافذة، المفتوحة من محفظة تحتفظ بمفتاح ML-DSA-87، هي المسار المتاح لها.