بالإضافة إلى ترجمة النص الأصلي، يقدم هذا المقال أيضًا معلومات عن EIPs الأخرى لـ Pectra التي لم يتم ذكرها في النص الأصلي.
الرابط الأصلي:
النقاط الرئيسية
Pectra هو التحديث الكبير التالي لإيثريوم، ويتضمن تغييرات في طبقة التنفيذ (Prague) وطبقة الإجماع (Electra). بعد سلسلة من المنعطفات في ترقية شبكة الاختبار Pectra، تم تحديد تفعيل ترقية الشبكة الرئيسية Pectra في حوالي 7 مايو الساعة 10:05 بالتوقيت العالمي المنسق.
ستوفر هذه الترقية تحسينات رئيسية في الإيداع وقابلية التوسع Layer 2 وتجربة المستخدم (UX) ، وستؤسس الأساس للتحولات المستقبلية.
تشمل التغييرات الرئيسية: زيادة الحد الأقصى للرهانات للمتحققين، سحب الرهانات المرن، تعزيز تجريد الحسابات، وزيادة سعة البلوبي لرفع كفاءة الشبكة وأمانها.
مقدمة
مرت 31 شهرًا منذ "الدمج" (The Merge) و 24 شهرًا منذ ترقية "Shapella" و 13 شهرًا منذ ترقية "Dencun"، ستشهد إيثيريوم قريبًا ترقية كبيرة جديدة - - شوكة Pectra.
قبل ترقية الشبكة الرئيسية لـ Pectra ، كانت ترقية الشبكة الاختبارية مليئة بالمنعطفات.
تم تفعيل ترقية Pectra لشبكة Holesky الاختبارية في 24 فبراير الساعة 21:55 بتوقيت UTC، ولكنها توقفت بسبب خطأ في تكوين برنامج العميل (عناوين عقود الإيداع لـ Geth وNethermind وBesu كانت خاطئة)، مما أدى إلى حدوث انقسام في السلسلة. ناقش المطورون خطة لاستعادة الشبكة من خلال حدث عقوبة جماعية، يهدف إلى تسريع خروج المدققين غير الصحيحين وتحقيق حتمية الشبكة النهائية، والتي لن تتحقق حتى 11 مارس.
تمت ترقية Pectra لشبكة Sepolia الاختبارية كما هو مخطط له في 5 مارس، وقد أدى مشكلة في تكوين عقد الإيداع المخصص إلى حدوث استثناءات لدى بعض عملاء طبقة التنفيذ (EL) عند تضمين المعاملات في الكتل، لكن تم إصلاح المشكلة بسرعة، وتم تحقيق الانتهاء من الشبكة.
في 19 مارس، لإجراء اختبار لانسحاب المدققين، تم إطلاق شبكة اختبار جديدة تُدعى Hoodi، وتم تنشيط ترقية شبكة Pectra بنجاح في 26 مارس.
ترقية شبكة اختبار Pectra الخاصة بـ Ethereum استغرقت شهرين من التحديات، مما مهد الطريق لنشر الشبكة الرئيسية. تم تحديد موعد تفعيل ترقية الشبكة الرئيسية لـ Pectra في حوالي 7 مايو الساعة 10:05 بالتوقيت العالمي المنسق.
مثل التحديثات السابقة لإيثريوم، تتعلق Pectra بطبقتي التنفيذ (EL) والاتفاق (CL). يعكس اسمها هذا التركيز المزدوج: براغ (Prague) تمثل تحديث طبقة التنفيذ، إحياءً لذكرى مكان انعقاد Devcon 4؛ بينما Electra (نجمة Electra) ترمز إلى تحديث طبقة الاتفاق.
Pectra هو أحد أكثر الشوكات الصلبة في تاريخ Ethereum التي تتضمن عددًا كبيرًا من EIP (اقتراحات تحسين Ethereum) (11 EIP). تم تحسينه على أساس ترقية Dencun العام الماضي ، بهدف تحسين تجربة المستخدم (UX) ، وتحسين عمليات المدققين ، وتعزيز التوسع في Layer 2 ، ومن المتوقع أن يكون له تأثير عميق على نظام Ethereum البيئي.
سوف نقوم في هذه المقالة بتصنيف وتحليل كل EIP بناءً على المجال الذي ينتمي إليه.
تحسين آلية المدققين والرهانات
تحسن Pectra تجربة عمليات التحقق في نظام Ethereum PoS من خلال ثلاث تحسينات رئيسية EIP:
EIP-7251: زيادة الحد الأقصى من الرصيد الفعال (MaxEB)
حالياً، يحدد آلية الرهن في إيثيريوم الحد الأقصى الفعال للرهن لكل مُصادق بمقدار 32 ETH، مما يعني أن المُصادقين المستقلين يجب أن يقوموا بالرهن بوحدات قدرها 32 ETH، ولن تُحتسب المكافآت التي تتجاوز هذا الحد ضمن الرهن الفعال.
تقترح EIP-7251 زيادة الحد الأقصى للرصيد الفعال (MaxEB) إلى 2048 ETH، مما يسمح بتوسيع نطاق الرهانات للمحقق الفردي من 32 إلى 2048 ETH، وتأثيرات ذلك تشمل:
· تعزيز مرونة الرهان: يمكن للمراهنين إعادة استثمار جميع العائدات في الرصيد الفعال للرهان، دون الحاجة إلى التقيد بضعف 32 ETH. على سبيل المثال، يمكن لمحقق يمتلك 33 ETH الآن الحصول على مكافآت الرهان على جميع 33 ETH، مما يزيد من كفاءة ورشاقة الأموال.
· تقليل عدد المدققين: يوجد حاليًا 1.05 مليون مدقق نشط في الإيثيريوم، وتسمح هذه EIP للمشغلين الكبار بدمج مدققيهم، مما يقلل العدد الإجمالي ويخفف من عبء الشبكة.
· تقليل الحمل على الشبكة: على الرغم من أن المزيد من المدققين يساعد في إزالة المركزية، إلا أنه يزيد أيضًا من عبء النطاق الترددي والحوسبة. يمكن أن يؤدي زيادة MaxEB إلى تحسين مجموعة المدققين وتقليل تكاليف الاتصالات من نظير إلى نظير.
EIP-7002: يمكن لطبقة التنفيذ Trigger سحب
EIP-7002 يعزز بشكل أكبر من وظائف المدققين، حيث يسمح لهم بتنشيط الخروج والسحب الجزئي مباشرة من خلال مستندات السحب على الطبقة التنفيذية (0x01).
حاليًا، لدى المدققين مفتاحان:
مفتاح النشاط، يُستخدم لأداء مهام التحقق؛
مفتاح السحب، يُستخدم للوصول إلى وإدارة الأموال المرهونة.
في السابق، كان بإمكان مفتاح النشاط فقط تفعيل الخروج، بينما لم يكن بإمكان مفتاح السحب العمل بشكل مستقل. يسمح EIP-7002 لمفتاح السحب أيضًا بتفعيل السحب، مما يجلب:
· سيطرة أكبر على الأموال: يمكن للمحققين إدارة الأموال مباشرة دون الحاجة للاعتماد على مشغلي العقد.
· يدعم برك التخزين غير الموثوقة تمامًا، مما يزيد من الأمان ودرجة اللامركزية.
EIP-6110: تخزين ودائع المدققين على السلسلة
حالياً، بعد أن يقوم الموثقون الجدد بإجراء الإيداع في طبقة التنفيذ، يحتاجون إلى الانتظار حتى تتعرف طبقة الإجماع على ذلك وتعالجه، مما يؤدي إلى تأخير في التفعيل.
EIP-6110 يسمح لطبقة التنفيذ بنقل معلومات الإيداع مباشرة إلى طبقة الإجماع، مما يقلل من خطوات التحقق الإضافية، ويقلل من وقت تفعيل المدققين من حوالي 9 ساعات إلى حوالي 13 دقيقة.
تعزيز القدرة على التوسع Layer 2: زيادة قدرة معالجة Blob
EIP-7691: زيادة سعة بلوب
في العام الماضي، قدمت ترقية Dencun Blobs، كوسيلة فعالة لتخزين البيانات في Layer 2 rollups. حاليًا، يتم تقديم حوالي 21,000 Blob يوميًا على إيثيريوم، ولكن السعة تقترب من الحد الأقصى، مما يؤدي إلى ارتفاع الرسوم ويقيد السعة.
حالياً، عدد الBlob المستهدف لكل كتلة في الإيثيريوم هو 3، والحد الأقصى هو 6. تقترح EIP-7691 زيادة القيمة المستهدفة إلى 6 وزيادة الحد الأقصى إلى 9 لزيادة سعة تخزين البيانات، وتحسين القدرة على المعالجة وقابلية التوسع. سيؤدي ذلك إلى خفض تكاليف تخزين البيانات، مما يقلل من رسوم معاملات L2.
EIP-7623: رفع تكلفة calldata
قبل إطلاق آلية Blob، كانت L2 تستخدم بشكل رئيسي calldata لتخزين البيانات، ولا يزال يتم استخدامها في بعض الحالات لأنها قد تكون أكثر فعالية من حيث التكلفة.
EIP-7623 زيادة تكلفة calldata، لتحفيز L2 على استخدام تخزين blob للبيانات، وبالتالي تحسين كفاءة معاملات rollup.
تعزيز تجربة المستخدم (UX)
EIP-7702: تعيين كود حساب EOA
الفكرة الأساسية: منح EOA القدرة على العقد الذكي مؤقتًا
EIP-7702 قدم نوعًا جديدًا تمامًا من المعاملات (المحدد بـ 0x04)، يسمح للحسابات المملوكة خارجيًا (EOA) بالحصول مؤقتًا على وظائف العقود الذكية أثناء تنفيذ معاملة. بمعنى آخر، على الرغم من أن EOA تقليديًا ليس لديها كود، ويمكن استخدامها فقط لتوقيع المعاملات، إلا أنه من خلال هذا الاقتراح، يمكن لـ EOA "تحميل" جزء من الكود في معاملة واحدة، مما يسمح لها بتنفيذ عمليات معقدة مثل محفظة العقد الذكي.
المزايا الرئيسية
العمليات الجماعية: يمكن للمستخدمين إتمام عدة عمليات في معاملة واحدة (على سبيل المثال، مجموعة approve + deposit)، مما يتجنب مشكلة عدم الكفاءة الناتجة عن الحاجة إلى معاملات متعددة.
· رعاية الغاز: هذه الآلية تدعم أيضًا رعاية الطرف الثالث لرسوم المعاملات، مما يحسن تجربة المستخدم، ويسمح للمستخدمين بالتفاعل دون الحاجة إلى امتلاك ETH مسبقًا.
· تعزيز الأمان والمرونة: يمكن للمستخدمين التحكم في صلاحيات المعاملات بشكل دقيق، مثل السماح فقط للحسابات الفرعية بالعمل تحت شروط محددة، مما يعزز أمان الحساب.
التحديات المحتملة
· مشكلات التوافق البيئي: نظرًا لأن EOA تقليديًا يُعتبر بدون كود، قد تحتاج بعض العقود الذكية الحالية أو فحوصات الأمان (مثل require(tx.origin == msg.sender)) إلى تعديل لتناسب هذه الآلية المؤقتة لإعطاء الكود.
· زيادة تعقيد هيكل المعاملات: إن إدخال أنواع جديدة من المعاملات سيجعل المحافظ والعميل بحاجة إلى إجراء تغييرات كبيرة للتأكد من عدم ظهور ثغرات أمنية أو تكاليف إضافية عالية عند التعامل مع مجموعات التفويض الجديدة وإعدادات الشفرة المؤقتة.
EIP-7702 يسمح للمستخدمين العاديين EOA بالحصول مؤقتًا على وظائف العقود الذكية في معاملة واحدة، مما يدعم المعاملات الجماعية، ورعاية المعاملات، وإدارة الأذونات بشكل أكثر مرونة. يمكن أن تحسن هذه الآلية تجربة المستخدم بشكل كبير وتوسع وظائف dApp، لكنها ستكسر بعض الافتراضات التقليدية، مما يتطلب من جميع الأطراف في النظام البيئي التكيف والتحديث. بشكل عام، هذه اقتراح مهم يمهد الطريق لتجريد الحسابات، والهدف هو جعل حسابات Ethereum المستقبلية آمنة وأكثر مرونة.
EIPs أخرى
EIP-7685: طلبات طبقة التنفيذ العامة
الخلفية والهدف
حاليًا، يحتاج Eth1 (طبقة التنفيذ) وسلسلة الإشارة (طبقة الإجماع) إلى معالجة ثلاثة أنواع رئيسية من الطلبات:
الإيداع: تظهر أحداث الإيداع التي بدأها المستخدم في البداية في كتلة Eth1، ولكن تحتاج في النهاية إلى المعالجة على سلسلة الإشارة.
السحب: طلب السحب الصادر من سلسلة الإشارات (عادةً من خلال أدوات سطر الأوامر) يحتاج إلى معالجة على Eth1.
دمج المدققين: بنفس الطريقة، تحتاج هذه الطلبات أيضًا إلى الانتقال بين Eth1 وسلسلة الإشارة.
لماذا تحتاج إلى هذا الاقتراح
تتبادل أنواع العمليات المختلفة حاليًا بين طبقتين ، مما يسهل حدوث الارتباك. يقترح إطار المعالجة الموحد EIP-7685 ، والذي يهدف إلى:
· معالجة جميع هذه الطلبات بطريقة معيارية تجعل العملية أكثر وضوحًا وكفاءة.
· يعتمد على Eth1 فقط لتفعيل هذه العمليات، مما يتيح فصل بيئة تشغيل المدققين وإدارة الرهانات، وبالتالي تحسين الأمان.
المحتوى الرئيسي
نوع الطلب المحدد: تم تعريف معرف محدد لكل نوع من العمليات، مثل طلبات الإيداع والسحب الموجودة، والآن يجب إضافة نوع طلب الدمج.
ضمان التكامل: سيتم استخدام بعض الآليات (مثل التحقق من التجزئة، وتحويل البيانات إلى شجرة ميركل) لضمان تكامل البيانات المطلوبة وأمانها.
معالجة قائمة الانتظار وتحديد السرعة: سيتم وضع بعض القيود على الطلبات التي تحتاج إلى المعالجة (مثل عدد الودائع أو السحوبات أو طلبات الدمج التي تنتظر في نفس الوقت) لمنع تحميل النظام بشكل مفرط.
المعنى النهائي
بالنسبة للمستخدمين العاديين والمطورين، فهذا يعني أنه في المستقبل، سواء كان الأمر يتعلق بإجراء إيداع أو سحب أو دمج للتحقق، يمكن إنجاز هذه العمليات بشكل أسرع وأكثر أمانًا من خلال عملية موحدة ومعيارية. هذا لا يحسن كفاءة النظام فحسب، بل يساعد أيضًا في تقليل المخاطر العامة.
EIP-2537: تجميع مسبق للتشغيل على منحنى BLS12-381
الهدف الأساسي
يضيف هذا الاقتراح ميزة مدمجة في الإيثريوم (تسمى العقود المسبقة التجميع) مصممة خصيصًا لمعالجة العمليات الرياضية على منحنى BLS12–381.
لماذا نحتاج إلى هذا البرمجة المسبقة
· تحسين الكفاءة: تنفيذ العمليات المعقدة للمنحنيات البيانية مباشرة في العقود الذكية (مثل التحقق من التوقيع والتجميع) سيستهلك الكثير من الغاز. يمكن أن تقلل العقود المسبقة التجميع بشكل كبير من تكلفة هذه العمليات.
· أمان أعلى: مقارنةً بمنحنى BN254 المستخدم حالياً (أمان حوالي 80 بت)، يوفر منحنى BLS12–381 أماناً بحوالي 120 بت، مما يجعل العمليات التشفيرية أكثر أماناً.
الاستخدامات الرئيسية
· التحقق من توقيع BLS: يسمح توقيع BLS بتجميع عدة توقيعات في توقيع واحد، مما يقلل بشكل كبير من كمية الحسابات المطلوبة أثناء التحقق.
· التحقق من إثبات zkSNARK: في بعض حلول حماية الخصوصية وقابلية التوسع، يلزم التحقق من إثبات zkSNARK، وتعتمد هذه العمليات أيضًا على حسابات معقدة على المنحنيات البيضاوية.
المعنى الحقيقي
من خلال هذا EIP، يمكن للمطورين استخدام عمليات التشفير المتعلقة بمنحنى BLS12–381 بشكل أكثر كفاءة وتكلفة أقل في العقود الذكية، مما يدعم المزيد من التطبيقات المبتكرة، مثل آليات التوافق الأكثر كفاءة، والتفاعل عبر السلاسل، ومجموعة متنوعة من التطبيقات اللامركزية.
بإيجاز، EIP-2537 تهدف إلى حل مشكلة استهلاك الغاز الزائد أثناء إجراء عمليات التشفير عالية الأمان على السلسلة، من خلال استخدام عقود مسبقة التجميع لجعل هذه العمليات المعقدة أكثر كفاءة وفعالية.
EIP-2935: حفظ تاريخ كتل الهاش في الحالة
المشكلة الحالية
في آلة الإيثيريوم الافتراضية (EVM)، يمكن استخدام رمز العملية BLOCKHASH فقط للوصول إلى تجزئة آخر 256 كتلة (حوالي 50 دقيقة)، وهذا قد لا يكون كافياً لبعض التطبيقات، مثل التطبيقات عبر السلاسل التي تحتاج إلى إثبات بيانات الكتل الأقدم أو العملاء غير الحالتين (مثل rollup).
جوهر الاقتراح
توصي EIP-2935 بالاحتفاظ ب 8192 هاش كتلة إضافية في حالة blockchain (حوالي 27.3 ساعة) ، مما يوسع بشكل كبير نطاق بيانات الكتلة التاريخية القابلة للاستعلام.
كيف تحقق
بالإضافة إلى الاحتفاظ بعملية BLOCKHASH الحالية التي يمكنها الوصول فقط إلى آخر 256 كتلة، ستقدم الاقتراح أيضًا عقدًا نظاميًا جديدًا مخصصًا:
· set() الطريقة: عند معالجة كل كتلة، ستقوم العقدة الجديدة تلقائيًا بتخزين هاش الكتلة الحالية في مخزن دائري.
· get() الطريقة: يمكن لأي شخص أو عقد ذكي استخدام هذه الطريقة للاستعلام عن تجزئة الكتل التاريخية المخزنة في الذاكرة الدائرية.
الفوائد الفعلية
بهذا الشكل، يمكن لتطبيقات متعددة السلاسل، وrollup أو الأنظمة الأخرى التي تحتاج إلى الوصول إلى بيانات الكتل السابقة، الحصول مباشرة على المعلومات التاريخية المطلوبة على السلسلة، دون الحاجة إلى الاعتماد الإضافي على البيانات الخارجية، مما يجعل تصميمها أبسط وأكثر أمانًا وموثوقية.
EIP-7840: إضافة جدولة blob إلى ملف تكوين EL
الهدف الأساسي
تهدف هذه الاقتراح إلى كتابة المعلمات الرئيسية المتعلقة بجدولة blob (مثل عدد blobs المسموح به لكل كتلة ونسب تحديث رسوم الأساس) في ملف تكوين طبقة التنفيذ (EL).
الطريقة المحددة
· إضافة إعدادات "عدد الكتل المستهدفة" و"الحد الأقصى لعدد الكتل" في ملف التكوين.
· إضافة معلمة تسمى baseFeeUpdateFraction أيضًا، لضبط سرعة تحديث الرسوم الأساسية.
· يمكن للعميل الاستعلام عن هذه المعلمات من خلال واجهة برمجة التطبيقات الخاصة بالعقدة، لمعرفة التكوين المحدد لـ blob في الشبكة الحالية.
لماذا هو مفيد
يمكن أن تساعد هذه المعلومات المطورين ومشغلي العقد في تقدير تكاليف غاز بلوب بدقة أكبر، كما تسهم في إدارة الشبكة بشكل أفضل لتنسيق ومعالجة البيانات الكبيرة ضمن الكتل.
بشكل عام، يضيف EIP-7840 مجموعة من معلمات جدولة blob القابلة للتكوين لطبقة التنفيذ في إيثريوم، مما يجعل الشبكة أكثر كفاءة وشفافية عند معالجة البيانات الكبيرة (blob).
EIP-7549: نقل فهرس اللجنة من الإثبات
الفكرة الأساسية
حاليًا، تحتوي رسالة التصويت التحقق (Attestation) على ثلاثة أجزاء:
المشكلة هي أن فهرس اللجنة تم توقيعه أيضًا، مما يؤدي إلى أنه حتى لو كانت محتويات التصويت هي نفسها، فإن الجذور الموقعة التي يتم إنشاؤها ستكون مختلفة بسبب اختلاف الفهرس. هذا سيجعل من المستحيل تجميع الأصوات ذات المحتوى المتماثل معًا.
الحل الذي اقترحه EIP-7549 هو: إزالة فهرس اللجنة من رسالة التصويت الموقعة. بهذه الطريقة، سيكون فقط المحتوى الأساسي للتصويت (تصويت LMD GHOST و Casper-FFG) هو الذي يشارك في حساب التوقيع، مما يسمح لعدة مصادقين بنفس التصويت بإنتاج نفس جذر التوقيع، وبالتالي يمكن تجميعها معًا.
الفوائد الرئيسية
· تقليل عبء العمل من خلال التحقق بشكل كبير: في الحالة الحالية، قد يتطلب الأمر التحقق من 1366 صوتاً للوصول إلى توافق 2/3. بعد إزالة فهرس اللجنة، يكفي التحقق من حوالي 22 صوتاً (موفرًا حوالي 62 مرة من حجم الحساب)، مما يجعل الكفاءة في عملية التحقق، التي تحتاج إلى الكثير من العمليات الزوجية، ملحوظة للغاية، خاصة بالنسبة لعميل Casper FFG المعتمد على إثباتات المعرفة الصفرية.
· زيادة كفاءة تخزين البيانات على سلسلة الكتل: نظرًا لأن معلومات التصويت يمكن تجميعها بشكل أكثر كفاءة، فإنه يمكن تعبئة المزيد من الأصوات في كل كتلة. الآن، يمكن أن تحتوي الكتلة على أصوات من 2 من الفترات الزمنية فقط، وبعد التحسين يمكن أن تصل إلى 8 فترات زمنية كحد أقصى، حتى إذا كان هناك 1/8 فقط من المقترحين متصلين، يمكن تضمين جميع الأصوات في الكتلة.
من خلال إزالة فهرس اللجنة من رسالة الشهادة، يمكن تقليل عدد العمليات الزوجية التي يجب معالجتها أثناء التحقق من التصويت بشكل كبير، وكذلك يمكن تعبئة بيانات التصويت بشكل أكثر كفاءة، مما يحسن أداء عملية التحقق من الإجماع ويزيد من كفاءة استخدام التخزين على السلسلة. تعتبر هذه التحسينات مهمة بشكل خاص لآلية إجماع Casper FFG والتحقق من إثبات المعرفة الصفرية ذات الصلة.
استنتاج
ستدفع "Pectra" كترقية تغطي عددًا قياسيًا من EIP، تطوير الإيثيريوم في اتجاهات رئيسية مثل تجريد الحساب، تحسين آلية التحقق، زيادة كفاءة الشبكة وتوسيع Layer 2. في الوقت نفسه، كما أشار فيتاليك بوتيرين مؤخرًا، على الرغم من أن الإيثيريوم يعتمد على مسار توسيع مركزي حول Rollup، إلا أنه لا يزال يعمل على تحسين Layer 1، مثل زيادة حد الغاز مؤخرًا إلى 36 مليون، ومن المحتمل أن يتم تعزيز القدرة على مقاومة الرقابة، والإنتاجية، وقابلية التوسع في المستقبل.
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
كل ما تحتاج لمعرفته حول ترقية إثيريوم Pectra: تحليل كامل لجميع EIPs
المؤلف | تاناي فيد، كوين ميتريكس
ترجمة | GaryMa قال وو عن البلوكتشين
بالإضافة إلى ترجمة النص الأصلي، يقدم هذا المقال أيضًا معلومات عن EIPs الأخرى لـ Pectra التي لم يتم ذكرها في النص الأصلي.
الرابط الأصلي:
النقاط الرئيسية
Pectra هو التحديث الكبير التالي لإيثريوم، ويتضمن تغييرات في طبقة التنفيذ (Prague) وطبقة الإجماع (Electra). بعد سلسلة من المنعطفات في ترقية شبكة الاختبار Pectra، تم تحديد تفعيل ترقية الشبكة الرئيسية Pectra في حوالي 7 مايو الساعة 10:05 بالتوقيت العالمي المنسق.
ستوفر هذه الترقية تحسينات رئيسية في الإيداع وقابلية التوسع Layer 2 وتجربة المستخدم (UX) ، وستؤسس الأساس للتحولات المستقبلية.
تشمل التغييرات الرئيسية: زيادة الحد الأقصى للرهانات للمتحققين، سحب الرهانات المرن، تعزيز تجريد الحسابات، وزيادة سعة البلوبي لرفع كفاءة الشبكة وأمانها.
مقدمة
مرت 31 شهرًا منذ "الدمج" (The Merge) و 24 شهرًا منذ ترقية "Shapella" و 13 شهرًا منذ ترقية "Dencun"، ستشهد إيثيريوم قريبًا ترقية كبيرة جديدة - - شوكة Pectra.
قبل ترقية الشبكة الرئيسية لـ Pectra ، كانت ترقية الشبكة الاختبارية مليئة بالمنعطفات.
تم تفعيل ترقية Pectra لشبكة Holesky الاختبارية في 24 فبراير الساعة 21:55 بتوقيت UTC، ولكنها توقفت بسبب خطأ في تكوين برنامج العميل (عناوين عقود الإيداع لـ Geth وNethermind وBesu كانت خاطئة)، مما أدى إلى حدوث انقسام في السلسلة. ناقش المطورون خطة لاستعادة الشبكة من خلال حدث عقوبة جماعية، يهدف إلى تسريع خروج المدققين غير الصحيحين وتحقيق حتمية الشبكة النهائية، والتي لن تتحقق حتى 11 مارس.
تمت ترقية Pectra لشبكة Sepolia الاختبارية كما هو مخطط له في 5 مارس، وقد أدى مشكلة في تكوين عقد الإيداع المخصص إلى حدوث استثناءات لدى بعض عملاء طبقة التنفيذ (EL) عند تضمين المعاملات في الكتل، لكن تم إصلاح المشكلة بسرعة، وتم تحقيق الانتهاء من الشبكة.
في 19 مارس، لإجراء اختبار لانسحاب المدققين، تم إطلاق شبكة اختبار جديدة تُدعى Hoodi، وتم تنشيط ترقية شبكة Pectra بنجاح في 26 مارس.
ترقية شبكة اختبار Pectra الخاصة بـ Ethereum استغرقت شهرين من التحديات، مما مهد الطريق لنشر الشبكة الرئيسية. تم تحديد موعد تفعيل ترقية الشبكة الرئيسية لـ Pectra في حوالي 7 مايو الساعة 10:05 بالتوقيت العالمي المنسق.
مثل التحديثات السابقة لإيثريوم، تتعلق Pectra بطبقتي التنفيذ (EL) والاتفاق (CL). يعكس اسمها هذا التركيز المزدوج: براغ (Prague) تمثل تحديث طبقة التنفيذ، إحياءً لذكرى مكان انعقاد Devcon 4؛ بينما Electra (نجمة Electra) ترمز إلى تحديث طبقة الاتفاق.
Pectra هو أحد أكثر الشوكات الصلبة في تاريخ Ethereum التي تتضمن عددًا كبيرًا من EIP (اقتراحات تحسين Ethereum) (11 EIP). تم تحسينه على أساس ترقية Dencun العام الماضي ، بهدف تحسين تجربة المستخدم (UX) ، وتحسين عمليات المدققين ، وتعزيز التوسع في Layer 2 ، ومن المتوقع أن يكون له تأثير عميق على نظام Ethereum البيئي.
سوف نقوم في هذه المقالة بتصنيف وتحليل كل EIP بناءً على المجال الذي ينتمي إليه.
تحسين آلية المدققين والرهانات
تحسن Pectra تجربة عمليات التحقق في نظام Ethereum PoS من خلال ثلاث تحسينات رئيسية EIP:
EIP-7251: زيادة الحد الأقصى من الرصيد الفعال (MaxEB)
حالياً، يحدد آلية الرهن في إيثيريوم الحد الأقصى الفعال للرهن لكل مُصادق بمقدار 32 ETH، مما يعني أن المُصادقين المستقلين يجب أن يقوموا بالرهن بوحدات قدرها 32 ETH، ولن تُحتسب المكافآت التي تتجاوز هذا الحد ضمن الرهن الفعال.
تقترح EIP-7251 زيادة الحد الأقصى للرصيد الفعال (MaxEB) إلى 2048 ETH، مما يسمح بتوسيع نطاق الرهانات للمحقق الفردي من 32 إلى 2048 ETH، وتأثيرات ذلك تشمل:
· تعزيز مرونة الرهان: يمكن للمراهنين إعادة استثمار جميع العائدات في الرصيد الفعال للرهان، دون الحاجة إلى التقيد بضعف 32 ETH. على سبيل المثال، يمكن لمحقق يمتلك 33 ETH الآن الحصول على مكافآت الرهان على جميع 33 ETH، مما يزيد من كفاءة ورشاقة الأموال.
· تقليل عدد المدققين: يوجد حاليًا 1.05 مليون مدقق نشط في الإيثيريوم، وتسمح هذه EIP للمشغلين الكبار بدمج مدققيهم، مما يقلل العدد الإجمالي ويخفف من عبء الشبكة.
· تقليل الحمل على الشبكة: على الرغم من أن المزيد من المدققين يساعد في إزالة المركزية، إلا أنه يزيد أيضًا من عبء النطاق الترددي والحوسبة. يمكن أن يؤدي زيادة MaxEB إلى تحسين مجموعة المدققين وتقليل تكاليف الاتصالات من نظير إلى نظير.
EIP-7002: يمكن لطبقة التنفيذ Trigger سحب
EIP-7002 يعزز بشكل أكبر من وظائف المدققين، حيث يسمح لهم بتنشيط الخروج والسحب الجزئي مباشرة من خلال مستندات السحب على الطبقة التنفيذية (0x01).
حاليًا، لدى المدققين مفتاحان:
مفتاح النشاط، يُستخدم لأداء مهام التحقق؛
مفتاح السحب، يُستخدم للوصول إلى وإدارة الأموال المرهونة.
في السابق، كان بإمكان مفتاح النشاط فقط تفعيل الخروج، بينما لم يكن بإمكان مفتاح السحب العمل بشكل مستقل. يسمح EIP-7002 لمفتاح السحب أيضًا بتفعيل السحب، مما يجلب:
· سيطرة أكبر على الأموال: يمكن للمحققين إدارة الأموال مباشرة دون الحاجة للاعتماد على مشغلي العقد.
· يدعم برك التخزين غير الموثوقة تمامًا، مما يزيد من الأمان ودرجة اللامركزية.
EIP-6110: تخزين ودائع المدققين على السلسلة
حالياً، بعد أن يقوم الموثقون الجدد بإجراء الإيداع في طبقة التنفيذ، يحتاجون إلى الانتظار حتى تتعرف طبقة الإجماع على ذلك وتعالجه، مما يؤدي إلى تأخير في التفعيل.
EIP-6110 يسمح لطبقة التنفيذ بنقل معلومات الإيداع مباشرة إلى طبقة الإجماع، مما يقلل من خطوات التحقق الإضافية، ويقلل من وقت تفعيل المدققين من حوالي 9 ساعات إلى حوالي 13 دقيقة.
تعزيز القدرة على التوسع Layer 2: زيادة قدرة معالجة Blob
EIP-7691: زيادة سعة بلوب
في العام الماضي، قدمت ترقية Dencun Blobs، كوسيلة فعالة لتخزين البيانات في Layer 2 rollups. حاليًا، يتم تقديم حوالي 21,000 Blob يوميًا على إيثيريوم، ولكن السعة تقترب من الحد الأقصى، مما يؤدي إلى ارتفاع الرسوم ويقيد السعة.
حالياً، عدد الBlob المستهدف لكل كتلة في الإيثيريوم هو 3، والحد الأقصى هو 6. تقترح EIP-7691 زيادة القيمة المستهدفة إلى 6 وزيادة الحد الأقصى إلى 9 لزيادة سعة تخزين البيانات، وتحسين القدرة على المعالجة وقابلية التوسع. سيؤدي ذلك إلى خفض تكاليف تخزين البيانات، مما يقلل من رسوم معاملات L2.
EIP-7623: رفع تكلفة calldata
قبل إطلاق آلية Blob، كانت L2 تستخدم بشكل رئيسي calldata لتخزين البيانات، ولا يزال يتم استخدامها في بعض الحالات لأنها قد تكون أكثر فعالية من حيث التكلفة.
EIP-7623 زيادة تكلفة calldata، لتحفيز L2 على استخدام تخزين blob للبيانات، وبالتالي تحسين كفاءة معاملات rollup.
تعزيز تجربة المستخدم (UX)
EIP-7702: تعيين كود حساب EOA
الفكرة الأساسية: منح EOA القدرة على العقد الذكي مؤقتًا
EIP-7702 قدم نوعًا جديدًا تمامًا من المعاملات (المحدد بـ 0x04)، يسمح للحسابات المملوكة خارجيًا (EOA) بالحصول مؤقتًا على وظائف العقود الذكية أثناء تنفيذ معاملة. بمعنى آخر، على الرغم من أن EOA تقليديًا ليس لديها كود، ويمكن استخدامها فقط لتوقيع المعاملات، إلا أنه من خلال هذا الاقتراح، يمكن لـ EOA "تحميل" جزء من الكود في معاملة واحدة، مما يسمح لها بتنفيذ عمليات معقدة مثل محفظة العقد الذكي.
المزايا الرئيسية
· رعاية الغاز: هذه الآلية تدعم أيضًا رعاية الطرف الثالث لرسوم المعاملات، مما يحسن تجربة المستخدم، ويسمح للمستخدمين بالتفاعل دون الحاجة إلى امتلاك ETH مسبقًا.
· تعزيز الأمان والمرونة: يمكن للمستخدمين التحكم في صلاحيات المعاملات بشكل دقيق، مثل السماح فقط للحسابات الفرعية بالعمل تحت شروط محددة، مما يعزز أمان الحساب.
التحديات المحتملة
· مشكلات التوافق البيئي: نظرًا لأن EOA تقليديًا يُعتبر بدون كود، قد تحتاج بعض العقود الذكية الحالية أو فحوصات الأمان (مثل require(tx.origin == msg.sender)) إلى تعديل لتناسب هذه الآلية المؤقتة لإعطاء الكود.
· زيادة تعقيد هيكل المعاملات: إن إدخال أنواع جديدة من المعاملات سيجعل المحافظ والعميل بحاجة إلى إجراء تغييرات كبيرة للتأكد من عدم ظهور ثغرات أمنية أو تكاليف إضافية عالية عند التعامل مع مجموعات التفويض الجديدة وإعدادات الشفرة المؤقتة.
EIP-7702 يسمح للمستخدمين العاديين EOA بالحصول مؤقتًا على وظائف العقود الذكية في معاملة واحدة، مما يدعم المعاملات الجماعية، ورعاية المعاملات، وإدارة الأذونات بشكل أكثر مرونة. يمكن أن تحسن هذه الآلية تجربة المستخدم بشكل كبير وتوسع وظائف dApp، لكنها ستكسر بعض الافتراضات التقليدية، مما يتطلب من جميع الأطراف في النظام البيئي التكيف والتحديث. بشكل عام، هذه اقتراح مهم يمهد الطريق لتجريد الحسابات، والهدف هو جعل حسابات Ethereum المستقبلية آمنة وأكثر مرونة.
EIPs أخرى
EIP-7685: طلبات طبقة التنفيذ العامة
الخلفية والهدف
حاليًا، يحتاج Eth1 (طبقة التنفيذ) وسلسلة الإشارة (طبقة الإجماع) إلى معالجة ثلاثة أنواع رئيسية من الطلبات:
الإيداع: تظهر أحداث الإيداع التي بدأها المستخدم في البداية في كتلة Eth1، ولكن تحتاج في النهاية إلى المعالجة على سلسلة الإشارة.
السحب: طلب السحب الصادر من سلسلة الإشارات (عادةً من خلال أدوات سطر الأوامر) يحتاج إلى معالجة على Eth1.
دمج المدققين: بنفس الطريقة، تحتاج هذه الطلبات أيضًا إلى الانتقال بين Eth1 وسلسلة الإشارة.
لماذا تحتاج إلى هذا الاقتراح
تتبادل أنواع العمليات المختلفة حاليًا بين طبقتين ، مما يسهل حدوث الارتباك. يقترح إطار المعالجة الموحد EIP-7685 ، والذي يهدف إلى:
· معالجة جميع هذه الطلبات بطريقة معيارية تجعل العملية أكثر وضوحًا وكفاءة.
· يعتمد على Eth1 فقط لتفعيل هذه العمليات، مما يتيح فصل بيئة تشغيل المدققين وإدارة الرهانات، وبالتالي تحسين الأمان.
المحتوى الرئيسي
نوع الطلب المحدد: تم تعريف معرف محدد لكل نوع من العمليات، مثل طلبات الإيداع والسحب الموجودة، والآن يجب إضافة نوع طلب الدمج.
ضمان التكامل: سيتم استخدام بعض الآليات (مثل التحقق من التجزئة، وتحويل البيانات إلى شجرة ميركل) لضمان تكامل البيانات المطلوبة وأمانها.
معالجة قائمة الانتظار وتحديد السرعة: سيتم وضع بعض القيود على الطلبات التي تحتاج إلى المعالجة (مثل عدد الودائع أو السحوبات أو طلبات الدمج التي تنتظر في نفس الوقت) لمنع تحميل النظام بشكل مفرط.
المعنى النهائي
بالنسبة للمستخدمين العاديين والمطورين، فهذا يعني أنه في المستقبل، سواء كان الأمر يتعلق بإجراء إيداع أو سحب أو دمج للتحقق، يمكن إنجاز هذه العمليات بشكل أسرع وأكثر أمانًا من خلال عملية موحدة ومعيارية. هذا لا يحسن كفاءة النظام فحسب، بل يساعد أيضًا في تقليل المخاطر العامة.
EIP-2537: تجميع مسبق للتشغيل على منحنى BLS12-381
الهدف الأساسي
يضيف هذا الاقتراح ميزة مدمجة في الإيثريوم (تسمى العقود المسبقة التجميع) مصممة خصيصًا لمعالجة العمليات الرياضية على منحنى BLS12–381.
لماذا نحتاج إلى هذا البرمجة المسبقة
· تحسين الكفاءة: تنفيذ العمليات المعقدة للمنحنيات البيانية مباشرة في العقود الذكية (مثل التحقق من التوقيع والتجميع) سيستهلك الكثير من الغاز. يمكن أن تقلل العقود المسبقة التجميع بشكل كبير من تكلفة هذه العمليات.
· أمان أعلى: مقارنةً بمنحنى BN254 المستخدم حالياً (أمان حوالي 80 بت)، يوفر منحنى BLS12–381 أماناً بحوالي 120 بت، مما يجعل العمليات التشفيرية أكثر أماناً.
الاستخدامات الرئيسية
· التحقق من توقيع BLS: يسمح توقيع BLS بتجميع عدة توقيعات في توقيع واحد، مما يقلل بشكل كبير من كمية الحسابات المطلوبة أثناء التحقق.
· التحقق من إثبات zkSNARK: في بعض حلول حماية الخصوصية وقابلية التوسع، يلزم التحقق من إثبات zkSNARK، وتعتمد هذه العمليات أيضًا على حسابات معقدة على المنحنيات البيضاوية.
المعنى الحقيقي
من خلال هذا EIP، يمكن للمطورين استخدام عمليات التشفير المتعلقة بمنحنى BLS12–381 بشكل أكثر كفاءة وتكلفة أقل في العقود الذكية، مما يدعم المزيد من التطبيقات المبتكرة، مثل آليات التوافق الأكثر كفاءة، والتفاعل عبر السلاسل، ومجموعة متنوعة من التطبيقات اللامركزية.
بإيجاز، EIP-2537 تهدف إلى حل مشكلة استهلاك الغاز الزائد أثناء إجراء عمليات التشفير عالية الأمان على السلسلة، من خلال استخدام عقود مسبقة التجميع لجعل هذه العمليات المعقدة أكثر كفاءة وفعالية.
EIP-2935: حفظ تاريخ كتل الهاش في الحالة
المشكلة الحالية
في آلة الإيثيريوم الافتراضية (EVM)، يمكن استخدام رمز العملية BLOCKHASH فقط للوصول إلى تجزئة آخر 256 كتلة (حوالي 50 دقيقة)، وهذا قد لا يكون كافياً لبعض التطبيقات، مثل التطبيقات عبر السلاسل التي تحتاج إلى إثبات بيانات الكتل الأقدم أو العملاء غير الحالتين (مثل rollup).
جوهر الاقتراح
توصي EIP-2935 بالاحتفاظ ب 8192 هاش كتلة إضافية في حالة blockchain (حوالي 27.3 ساعة) ، مما يوسع بشكل كبير نطاق بيانات الكتلة التاريخية القابلة للاستعلام.
كيف تحقق
بالإضافة إلى الاحتفاظ بعملية BLOCKHASH الحالية التي يمكنها الوصول فقط إلى آخر 256 كتلة، ستقدم الاقتراح أيضًا عقدًا نظاميًا جديدًا مخصصًا:
· set() الطريقة: عند معالجة كل كتلة، ستقوم العقدة الجديدة تلقائيًا بتخزين هاش الكتلة الحالية في مخزن دائري.
· get() الطريقة: يمكن لأي شخص أو عقد ذكي استخدام هذه الطريقة للاستعلام عن تجزئة الكتل التاريخية المخزنة في الذاكرة الدائرية.
الفوائد الفعلية
بهذا الشكل، يمكن لتطبيقات متعددة السلاسل، وrollup أو الأنظمة الأخرى التي تحتاج إلى الوصول إلى بيانات الكتل السابقة، الحصول مباشرة على المعلومات التاريخية المطلوبة على السلسلة، دون الحاجة إلى الاعتماد الإضافي على البيانات الخارجية، مما يجعل تصميمها أبسط وأكثر أمانًا وموثوقية.
EIP-7840: إضافة جدولة blob إلى ملف تكوين EL
الهدف الأساسي
تهدف هذه الاقتراح إلى كتابة المعلمات الرئيسية المتعلقة بجدولة blob (مثل عدد blobs المسموح به لكل كتلة ونسب تحديث رسوم الأساس) في ملف تكوين طبقة التنفيذ (EL).
الطريقة المحددة
· إضافة إعدادات "عدد الكتل المستهدفة" و"الحد الأقصى لعدد الكتل" في ملف التكوين.
· إضافة معلمة تسمى baseFeeUpdateFraction أيضًا، لضبط سرعة تحديث الرسوم الأساسية.
· يمكن للعميل الاستعلام عن هذه المعلمات من خلال واجهة برمجة التطبيقات الخاصة بالعقدة، لمعرفة التكوين المحدد لـ blob في الشبكة الحالية.
لماذا هو مفيد
يمكن أن تساعد هذه المعلومات المطورين ومشغلي العقد في تقدير تكاليف غاز بلوب بدقة أكبر، كما تسهم في إدارة الشبكة بشكل أفضل لتنسيق ومعالجة البيانات الكبيرة ضمن الكتل.
بشكل عام، يضيف EIP-7840 مجموعة من معلمات جدولة blob القابلة للتكوين لطبقة التنفيذ في إيثريوم، مما يجعل الشبكة أكثر كفاءة وشفافية عند معالجة البيانات الكبيرة (blob).
EIP-7549: نقل فهرس اللجنة من الإثبات
الفكرة الأساسية
حاليًا، تحتوي رسالة التصويت التحقق (Attestation) على ثلاثة أجزاء:
· LMD GHOST التصويت (يشمل جذر الكتلة والفترة الزمنية)
· تصويت Casper-FFG (يشمل المصدر والهدف)
· مؤشر اللجنة (index)
المشكلة هي أن فهرس اللجنة تم توقيعه أيضًا، مما يؤدي إلى أنه حتى لو كانت محتويات التصويت هي نفسها، فإن الجذور الموقعة التي يتم إنشاؤها ستكون مختلفة بسبب اختلاف الفهرس. هذا سيجعل من المستحيل تجميع الأصوات ذات المحتوى المتماثل معًا.
الحل الذي اقترحه EIP-7549 هو: إزالة فهرس اللجنة من رسالة التصويت الموقعة. بهذه الطريقة، سيكون فقط المحتوى الأساسي للتصويت (تصويت LMD GHOST و Casper-FFG) هو الذي يشارك في حساب التوقيع، مما يسمح لعدة مصادقين بنفس التصويت بإنتاج نفس جذر التوقيع، وبالتالي يمكن تجميعها معًا.
الفوائد الرئيسية
· تقليل عبء العمل من خلال التحقق بشكل كبير: في الحالة الحالية، قد يتطلب الأمر التحقق من 1366 صوتاً للوصول إلى توافق 2/3. بعد إزالة فهرس اللجنة، يكفي التحقق من حوالي 22 صوتاً (موفرًا حوالي 62 مرة من حجم الحساب)، مما يجعل الكفاءة في عملية التحقق، التي تحتاج إلى الكثير من العمليات الزوجية، ملحوظة للغاية، خاصة بالنسبة لعميل Casper FFG المعتمد على إثباتات المعرفة الصفرية.
· زيادة كفاءة تخزين البيانات على سلسلة الكتل: نظرًا لأن معلومات التصويت يمكن تجميعها بشكل أكثر كفاءة، فإنه يمكن تعبئة المزيد من الأصوات في كل كتلة. الآن، يمكن أن تحتوي الكتلة على أصوات من 2 من الفترات الزمنية فقط، وبعد التحسين يمكن أن تصل إلى 8 فترات زمنية كحد أقصى، حتى إذا كان هناك 1/8 فقط من المقترحين متصلين، يمكن تضمين جميع الأصوات في الكتلة.
من خلال إزالة فهرس اللجنة من رسالة الشهادة، يمكن تقليل عدد العمليات الزوجية التي يجب معالجتها أثناء التحقق من التصويت بشكل كبير، وكذلك يمكن تعبئة بيانات التصويت بشكل أكثر كفاءة، مما يحسن أداء عملية التحقق من الإجماع ويزيد من كفاءة استخدام التخزين على السلسلة. تعتبر هذه التحسينات مهمة بشكل خاص لآلية إجماع Casper FFG والتحقق من إثبات المعرفة الصفرية ذات الصلة.
استنتاج
ستدفع "Pectra" كترقية تغطي عددًا قياسيًا من EIP، تطوير الإيثيريوم في اتجاهات رئيسية مثل تجريد الحساب، تحسين آلية التحقق، زيادة كفاءة الشبكة وتوسيع Layer 2. في الوقت نفسه، كما أشار فيتاليك بوتيرين مؤخرًا، على الرغم من أن الإيثيريوم يعتمد على مسار توسيع مركزي حول Rollup، إلا أنه لا يزال يعمل على تحسين Layer 1، مثل زيادة حد الغاز مؤخرًا إلى 36 مليون، ومن المحتمل أن يتم تعزيز القدرة على مقاومة الرقابة، والإنتاجية، وقابلية التوسع في المستقبل.
رابط مرجعي: