شرح ترقية Pectra من إيثريوم: ما الذي تغيره تجريد الحساب فعليًا للمطورين والمستخدمين

مشاركة:
شرح ترقية Pectra من إيثريوم: ما الذي تغيره تجريد الحساب فعليًا للمطورين والمستخدمين

Pectra — اختصارًا لـ Prague/Electra — وصلت إلى الشبكة الرئيسية لإيثريوم في مطلع 2025، وتجمع بين تغييرات طبقة التنفيذ (Prague) وترقيات طبقة الإجماع (Electra). وهي الترقية الأكثر تأثيرًا على المطورين منذ Merge، ومحورها هو EIP-7702، التي تقدم شكلاً عمليًا وتدريجيًا من تجريد الحساب للحسابات التي يملكها المستخدمون (EOAs) دون إجبارهم على الانتقال إلى محافظ Smart Contract جديدة.

EIPs الثلاث التي تحدد Pectra

تضم Pectra عشرات EIPs، لكن ثلاثًا منها تدفع معظم التأثير الفعلي:

  • EIP-7702 — تعيين كود لـ EOA: تسمح لأي EOA بتبني كود Smart Contract مؤقتًا لمدة المعاملة. هذا هو فتح تجريد الحساب الذي يهم معظم المطورين.
  • EIP-7251 — زيادة الحد الأقصى الفعلي لرصيد المُدقق: ترفع الحد الأقصى للرصيد الفعلي للمدققين من 32 ETH إلى 2,048 ETH. يمكن لعمليات التخزين الكبيرة الآن دمج المدققين بدلاً من تشغيل مئات العقد بقيمة 32 ETH، مما يقلل من تحميل p2p والتعقيد التشغيلي بشكل كبير.
  • EIP-7549 — نقل فهرس اللجنة خارج المصادقة: تحسين كفاءة لطبقة الإجماع يقلل عدد الهاشات اللازمة لمعالجة المصادقات، مما يدعم إنتاجية أعلى ويضع الأساس لتوسيع نطاق الـ blob مستقبلًا عبر زيادة عدد blobs في Pectra (من 3/6 إلى 6/9 كحد أقصى مستهدف لكل كتلة).

ماذا يعني تجريد الحساب فعليًا

مصطلح تجريد الحساب يدور في خطاب إيثريوم منذ 2016 على الأقل. بعبارات بسيطة، يعني منح محافظ المستخدمين العادية (EOAs) القدرات البرمجية التي كانت دائمًا لدى Smart Contracts. قبل Pectra، كانت EOAs جامدة: لا يمكنها إلا توقيع المعاملات بمفتاحها الخاص، وتدفع دائمًا الرسوم بالـ ETH، وكل إجراء يتطلب معاملة موقعة منفصلة من مالك المحفظة.

تكسِر EIP-7702 هذه الصلابة بالسماح لـ EOA بتفويض تنفيذها إلى جزء من كود Smart Contract — مؤشر كود — موجود على السلسلة. يتم تعيين التفويض عبر نوع معاملة جديد (SET_CODE_TX_TYPE = 0x04)، ويستمر حتى يتم إلغاؤه. هذا يتيح أربع قدرات كانت مستحيلة سابقًا أو تطلبت حلولاً بديلة مرهقة:

  • دفع الغاز بأي رمز: يمكن لعقد paymaster تغطية تكاليف غاز ETH نيابة عن المستخدم، مما يسمح للتطبيقات برعاية الغاز أو قبول USDC كرسوم. لم يعد المستخدم بحاجة إلى ETH للتفاعل مع تطبيقات ETH.
  • المعاملات المجمعة: عمليات متعددة — approve + swap، approve + deposit + stake — تندمج في معاملة ذرية واحدة. توقيع واحد، تأكيد واحد، كتلة واحدة.
  • مفاتيح الجلسة: يمكن منح DApp مفتاحًا محددًا ومحدود الوقت يصرح بإجراءات معينة (مثل "أنفق حتى 50 USDC على هذه اللعبة خلال الـ 24 ساعة القادمة") دون كشف المفتاح الخاص الأساسي.
  • الاسترداد الاجتماعي: يمكن للكود المفوض تنفيذ منطق استرداد متعدد التوقيعات، مما يسمح لجهات الاتصال الموثوقة باستعادة الوصول إلى المحفظة إذا فُقد المفتاح الخاص.

قبل وبعد: مقارنة ملموسة

المبادلة على DEX

قبل Pectra: يفتح المستخدم MetaMask، يوافق على الرمز (المعاملة 1، غاز بالـ ETH، ~15 ثانية)، ينتظر التأكيد، ثم ينفذ المبادلة (المعاملة 2، غاز إضافي بالـ ETH، ~15 ثانية أخرى). تأكيدان منفصلان، دفعتان للغاز، نقطتا فشل محتملتان.

بعد Pectra: ينقر المستخدم على "Swap". تفوض المحفظة إلى عقد تجميع، ترسل معاملة واحدة توافق وتتبادل بشكل ذري، ويغطي paymaster التابع للتطبيق الغاز بـ USDC إذا لم يكن لدى المستخدم ETH. نقرة واحدة، تأكيد واحد.

تسجيل مستخدم جديد

قبل Pectra: يشتري المستخدم الجديد ETH من بورصة، يسحبها إلى المحفظة، ينتظر الوصول، ثم يمكنه التفاعل مع DApps. كان شرط الغاز عائقًا للالتحاق يقتل معدلات التحويل.

بعد Pectra: يرعى التطبيق المعاملات الأولى عبر paymaster. يمكن للمستخدم الالتحاق فقط باستخدام عملة مستقرة أو حتى أول معاملة بدون غاز. تنشئ المحفظة EOA قياسي — لا هجرة إلى محفظة Smart Contract، لا تعقيد عبارة الاسترداد بخلاف المعتاد.

آثار على بروتوكولات DeFi

تحصل بروتوكولات DeFi على ترقية كبيرة في تجربة المستخدم دون إعادة كتابة العقود. يمكن للبروتوكولات التي تنفذ واجهات أمامية متوافقة مع EIP-7702:

  • تقديم تدفقات "zap" بنقرة واحدة تجمع عدة عمليات DeFi (مثل ETH إلى رمز تخزين سائل إلى إيداع في خزانة عائد) دون خطوات موافقة متعددة.
  • تنفيذ رعاية الغاز للمستخدمين المؤهلين (مثل المستخدمين الذين لديهم أكثر من $1,000 في TVL للبروتوكول يحصلون على معاملات بدون غاز).
  • استخدام مفاتيح الجلسة لروبوتات الأوامر المحدودة والاستراتيجيات الآلية — يصرح المستخدمون لعقد معين بالتصرف نيابة عنهم ضمن معايير محددة، دون تسليم الأموال.

النقطة الحاسمة لمطوري البروتوكول: لستم بحاجة إلى إعادة نشر عقودكم. تعمل EIP-7702 على مستوى الحساب. تستقبل عقود Solidity الحالية استدعاءات من ما يبدو وكأنه EOA تتصرف مثل Smart Contract — الواجهة لم تتغير.

ما يحتاج المطورون لتغييره

لمطوري المحافظ، تقدم EIP-7702 نوع معاملة جديد يجب دعمه في تدفقات التوقيع. حقل authorization_list في معاملات النوع 0x04 يحتوي على tuples موقعة من (chain_id, address, nonce) تُعين تفويض الكود. يجب على المحافظ عرض هذه بوضوح للمستخدمين — تفويض إلى عقد ضار يعادل وظيفيًا منحه سيطرة كاملة على EOA لتلك المعاملة.

لمطوري DApps، البديل الرئيسي الجديد هو واجهة paymaster (المعيارية في ERC-4337 والآن قابلة للاستخدام مع EOAs عبر 7702). يتطلب دمج paymaster اختيار مزود bundler (Pimlico، Alchemy، Biconomy، وStackup جميعها تدعم هذا)، وتنفيذ منطق validatePaymasterUserOp، وتحديث الواجهة الأمامية لبناء نوع المعاملة الجديد بدلاً من معاملة EOA عادية.

تتبع تنفيذات مفاتيح الجلسة نمطًا حيث: (1) يوقع المستخدم تفويضًا إلى عقد مفتاح الجلسة، (2) يخزن الخادم الخلفي للتطبيق المفتاح المحدد والمعايير، (3) تُرسل الإجراءات التالية كمعاملات موقعة بواسطة مفتاح الجلسة بدلاً من EOA الأساسي. مكتبات مثل permissionless.js ووحدة تجريد الحساب في Viem قد شحنت بالفعل دعم EIP-7702.

الفجوات المتبقية

EIP-7702 هي تحسن تدريجي، وليس الرؤية الكاملة لتجريد الحساب. تبقى عدة قيود:

  • التفويض لكل حساب، وليس عامًا: يجب على كل EOA بشكل فردي الاشتراك في تفويض الكود. لا توجد ترقية شاملة للمحافظ على مستوى الشبكة — يعتمد التبني على شحن المحافظ للدعم وتنفيذ المستخدمين معاملة واحدة على الأقل لتعيين التفويض.
  • إعادة تعيين الكود على معاملات EOA العادية: إذا أرسلت EOA معاملة عادية (غير مفوضة)، يمكن مسح مؤشر الكود. تحتاج المحافظ إلى التعامل مع هذا بحذر لتجنب حالة مربكة للمستخدمين الذين يخلطون بين أنواع المعاملات القديمة والجديدة.
  • لا جلسات عبر السلاسل بشكل أصلي: مفاتيح الجلسة والتفويضات خاصة بكل سلسلة. تفويض على إيثريوم الرئيسي لا ينتقل إلى Arbitrum أو Base. يبقى تجريد الحساب عبر السلاسل مشكلة مفتوحة.
  • EOA ليست محفظة Smart Contract كاملة: EOAs مع تفويض EIP-7702 لا يمكنها استقبال ETH عبر selfdestruct، ولا يمكنها أن تكون هدفًا لنشر CREATE2 بنفس الطريقة، ولها افتراضات أمان مختلفة قليلاً عن محفظة Smart Contract أصلية مثل Safe.

خارطة طريق إيثريوم تعالج هذه الفجوات في ترقيات مستقبلية. EIP-7701 (تجريد حساب أصلي عبر نوع معاملة جديد) ونضوج بنية ERC-4337 هما الخطوات التالية. من الأفضل فهم Pectra على أنها تجعل تجريد الحساب عمليًا لقاعدة المستخدمين الحالية — أكثر من 500 مليون EOA — دون إجبار على الهجرة.

خلاصة المفاتيح للمطورين

  • إذا كنت تبني محافظ: شحن دعم نوع معاملة EIP-7702، عرض أهداف التفويض بوضوح، وتنفيذ دمج paymaster مع مزود bundler واحد على الأقل.
  • إذا كنت تبني DApps: يمكنك إضافة رعاية الغاز وتجميع المعاملات دون إعادة نشر العقود. عائد الاستثمار من تقليل خطوات الموافقة يُقاس بمعدلات التحويل.
  • إذا كنت تدير عملية تخزين: EIP-7251 تتيح لك دمج 64 × 32 ETH من المدققين في مدقق واحد بقيمة 2,048 ETH، مما يقلل تحميل p2p والتشغيل بنحو 98%.
  • إذا كنت تبني عبر السلاسل: لا تفترض أن تفويضات EOA تنتقل عبر السلاسل. صمم بنية مفتاح الجلسة للتعامل مع التفويض لكل سلسلة بشكل صريح.

Pectra لا تعيد اختراع إيثريوم — إنها تزيل الاحتكاك الذي جعل إيثريوم صعب الاستخدام لمدة عقد. خطوة الموافقة على الرمز المزدوجة، شرط ETH للغاز، عدم القدرة على أتمتة إجراءات المحفظة بأمان: هذه لم تكن قيودًا جوهرية لسلاسل الكتل، بل قيودًا لنموذج EOA. EIP-7702 تقفل معظمها. ما تبقى هو مشكلة تنفيذ لفرق المحافظ ومطوري DApps، وليست فجوة بروتوكولية.

مشاركة:
شرح ترقية Pectra من إيثريوم: ما الذي تغيره تجريد الحساب فعليًا للمطورين والمستخدمين | IRCNF - Intelligent Reliable Custom Next-gen Frameworks