Parse Ethereum’s Hard Forks – ترقية Pectra

يقدم

في مقالتنا السابقة ، استعرضنا دورة حياة التحقق من Ethereum بالتفصيل ، ونناقش جوانب متعددة تتعلق بشوكة Electra Hard القادمة.الآن ، حان الوقت للتركيز على التغييرات في ترقيات Electra و Prague القادمة وشرحها بالتفصيل.

تاريخ Ethereum 2.0 “إثبات الحصة” الشوكة الصلبة معقد.يبدأ بإضافة طبقة منارة إلى طبقة التنفيذ الحالية ، والتي تحافظ على إثبات العمل (المرحلة 6 و Altair Hard Forks) بينما تبدأ طبقة منارة الإجماع على إجماع الحصة.بعد ذلك ، يتم تنشيط POS بالكامل في شوكة Bellatrix الصلبة (على الرغم من عدم تمكين الانسحاب).بعد ذلك ، يسمح Capella Hard Fork بسحب ، واستكمال دورة حياة المدقق.قامت Forks Hard Forks الحديثة (جزء من ترقية Dencun (DENB/Cancun)) بإجراء مراجعات بسيطة لمعلمات سلسلة منارة ، مثل النوافذ الزمنية التي تحتوي على أدلة ومعالجة المخارج الطوعية وقيود استبدال المدقق.تحدث التغييرات الرئيسية في Dencun في طبقة التنفيذ ، وإطلاق معاملات Blob ، و BLOB GAS ، و KZG وعود للنقاط ، والتخلي عن عمليات التدمير الذاتي.

الآن ، يقدم Prague/Electra (أي pectra) شوكة قوية ترقيات مهمة لطبقات التنفيذ والتوافق.بصفتنا مدققين في مشروع LIDO ، فإننا نركز بشكل أساسي على الإجماع والتغييرات المتعلقة بالقيام في هذا الشوكة الصعبة.ومع ذلك ، لا يمكننا تجاهل تغييرات طبقة التنفيذ في براغ ، لأنها تتضمن ميزات مهمة تؤثر على شبكة Ethereum والمقحة.دعنا نحفر في تفاصيل هذه التغييرات.

نظرة عامة على المستوى الأعلى من البكرا

يقدم Electra العديد من الميزات إلى طبقة منارة.تشمل التحديثات الرئيسية:

يسمح بالتوازن الصحيح للمقابلة أن يختلف بين 32 و 2048 ETH (بدلاً من 32 ETH ثابت).
يسمح للمقابح ببدء المخارج من خلال قسائم “الانسحاب” الثانوية (لم يعد مفتاح التحقق النشط مطلوبًا).
قم بتغيير كيفية معالجة طبقة المنارة ودائع eth1 (لم يعد الحدث محجوبًا من عقد الإيداع).
إضافة إطار عمل مشترك جديد للتعامل مع طلبات من عقود ETH1 العادية على طبقة منارة (على غرار كيفية إدارة رواسب ما قبل الإلكترى).

وفي الوقت نفسه ، قدم براغ التغييرات التالية على طبقة التنفيذ:

عقد مسبق جديد يدعم منحنى BLS12-381 للتحقق من أدلة Zksnark (باستثناء منحنى BN254 الشهير).
عقد نظام جديد لتخزين وصول ما يصل إلى 8192 تجزئة الكتلة التاريخية (مفيدة للغاية للعملاء عديمي الجنسية).
قم بزيادة تكاليف غاز Calldata لتقليل حجم الكتلة وتشجيع المشاريع على ترحيل العمليات المكثفة في CallData مثل Rollup to Blobs المقدمة في Dencun.
يدعم المزيد من النقط لكل كتلة ETH1 ويوفر واجهة برمجة التطبيقات لقراءة هذه الأرقام.
إن السماح لـ EOA (الحساب المملوك الخارجي) بتوسيع رمز الحساب الخاص به بشكل كبير ما يمكن أن تفعله EOA ، مثل تنفيذ Multicalls أو تفويض التنفيذ إلى عناوين أخرى.

دعونا نشير إلى اقتراح تحسين Ethereum (EIP) لمزيد من المناقشة:

EIP-7251: تمت إضافة MAX_EFFECTION_BALANCE
EIP-7002: يخرج طبقة التنفيذ
EIP-6110: يتم توفير إيداع everipier على السلسلة
EIP-7549: انقل مؤشر اللجنة من الدليل
EIP-7685: طلب طبقة التنفيذ العامة
EIP-2537: عملية منحنى BLS12-381
EIP-2935: حفظ التجزئة التاريخية في الدولة
EIP-7623: زيادة تكلفة CallData
EIP-7691: زيادة إنتاجية Blob
EIP-7840: إضافة جدول Blob إلى ملف تكوين EL
EIP-7702: إعداد رمز حساب EOA

تتضمن بعض هذه EIPs أساسًا طبقة الإجماع (منارة) ، بينما يرتبط البعض الآخر بطبقة التنفيذ.تمتد بعض طبقتين ، لأن عمليات معينة (مثل الودائع والسحب) تتطلب تغييرات متزامنة بين إجماع الطبقات وطبقات التنفيذ.بسبب هذا الترابط ، من غير العملي فصل Electra و Prague ، لذلك سنراجع كل EIP بدوره ونحدد مكونات Ethereum المتأثرة في كل حالة.

EIP-7251: تمت إضافة MAX_EFFECTION_BALANCE

المرجع: EIP-7251

منذ المرحلة الأولى من الشوكة الصلبة ، من أجل إعداد دليل على حصة Ethereum ، تم إصلاح الحد الأقصى لتوازن الصحيح للمحق في 32 ETH حتى Electra.تنشيط متطلبات التحقق على الأقل spec.min_activation_balance (32 eth).بعد التنشيط ، يبدأ المدقق بهذا الرصيد القصوى الصحيح ، ولكن يمكن أن يقلل من توازنه الصحيح إلى المواصفات.يبقى هذا المنطق “الحد الأدنى” دون تغيير في Electra ، ولكن الآن تم زيادة spec.max_ffective_balance إلى 2048 ETH.لذلك ، يمكن للمقحة إيداع ما بين 32 و 2048 ETH لتفعيله ، وكل ذلك سيساهم في توازنه الصحيح.يمثل هذا التحول التحول من “32th-Problaring of Stake” إلى “إثبات الحصة” 🙂

سيتم الآن استخدام هذا التوازن الصحيح المتغير لـ:

زيادة احتمال أن تصبح مقترحًا للكتلة ، تتناسب مع التوازن الفعال
زيادة احتمال أن تصبح عضوًا في اللجنة المتزامنة ، تتناسب مع التوازن الفعلي
كأساس لحساب كمية التخفيضات النسبية والعقوبات غير النشطة

النشاطين الأولين هما أكثر الإجراءات مجزية للمقدين.لذلك ، بعد Electra ، سيشارك المدققون من المهجرين الكبير بشكل متكرر في لجان الاقتراح والمزامنة ، مع تواتر يتناسب مع توازنها الفعلي.

تأثير آخر له علاقة مع التخفيضات.جميع التخفيضات تتناسب مع الرصيد الصحيح للمقالح:

إن التخفيضات “الفورية” و “التأخير” أكبر لمقدين المخاطر العالية.
تعتبر غرامات “المتأخرة” مع صحة قطع مع تعهدات عالية أكبر أيضًا ، حيث يصبح الجزء “المقطوع” من إجمالي التعهد أكبر.
يتلقى المبلغون عن المخالفات الذين يبلغون عن مراقبيهم مع أرصدة أعلى صالحة نسبة أكبر من المخاطر المنخفضة.

اقترح Electra أيضًا تغييرات على نسبة القطع ، وتحديد جزء من رصيد المدقق المقطوع واستلامه بواسطة المبلغين عن المخالفات.

التالي هو تأثير البطلان.عندما يكون المدقق غير متصل عندما يكون نشطًا (إثبات أو اقتراح) ، تتراكم درجة البطلان ، مما يؤدي إلى فرض عقوبة البطلان لكل دورة.تتعلق هذه العقوبات أيضًا بالتوازن الصحيح للمقاومةحَجمالعلاقة.

بسبب الزيادة في التوازن الصحيح ، تغير “الحد البديل” للمقالح أيضًا.في Ethereum “قبل Electra” ، عادةً ما يكون للمقاومة نفس الرصيد الصحيح ، ويتم تعريف حد استبدال الخروج على أنه “في دورة ، لا يمكن أن يكون هناك حصة إجمالية 1/65536 (spec.Churn_Limit_Quotient) ينشئ عدد “ثابت” من المخارج المخرج مع نفس الحصة.ومع ذلك ، بعد Electra ، قد لا يكون هناك سوى عدد قليل من “الحيتان” لأنها تمثل جزءًا مهمًا من التعهد الكلي.

أحد الاعتبارات الأخرى هو دوران العديد من مفاتيح التحقق على مثيل للتحقق الواحد.يتم إجبار المدققين الكبار حاليًا على تشغيل آلاف مفاتيح المدقق في حالة واحدة لاستيعاب الخداع الكبير ، وتقسيمها إلى 32 قسمًا ETH.مع Electra ، لم يعد هذا السلوك إلزاميًا.من منظور مالي ، يكون لهذا التغيير تأثير ضئيل لأن المكافآت والاحتمال يتم تحجيمها خطيًا مع مقدار التعهد.لذلك ، 100 من المدقق لكل 32 ETH يعادل واحد 3200 ETH.بالإضافة إلى ذلك ، يمكن أن يكون لمفاتيح التحقق النشطة المتعددة نفس بيانات الاعتماد على الانسحاب ETH1 ، مما يسمح بسحب جميع المكافآت إلى عنوان ETH واحد ، وتجنب تكاليف الغاز المرتبطة باندماج المكافآت.ومع ذلك ، فإن إدارة كميات كبيرة من المفاتيح تتحمل تكاليف إدارية إضافية.

تضيف القدرة على تجميع أرصدة المدقق نوع طلب طبقة تنفيذ جديدة.من قبل ، كان لدينا ودائع وسحب.الآن ، سيكون هناك نوع آخر: طلب إجمالي.وهو يجمع بين اثنين من المدققين في واحد.سيتضمن طلب العملية هذا المفتاح العام لـ Verifier للمصدر والمفتاح العام المستهدف وسيتم معالجته بشكل مشابه للودائع والسحب.سيكون للجماعات أيضًا طلبات معلقة وقيود استبدال التوازن ، تمامًا مثل الودائع والسحب.

الملخص كما يلي:

بالنسبة للمقدين المستقلين الصغار ، يقدم Electra القدرة على زيادة توازنهم الفعال (والمكافآت) تلقائيًا.في السابق ، لا يمكن سحب أي فائض يتجاوز 32 ETH إلا ، ولكن بعد Electra ، سيساهم هذا الفائض في النهاية في توازنه الفعلي.ومع ذلك ، يمكن أن يزيد التوازن الفعال فقط في مضاعفات المواصفات.
بالنسبة للمقاورين المستقلين الكبار ، يوفر Electra تبسيطًا كبيرًا لإدارة من خلال السماح بتوحيد مفاتيح المدقق النشطة المتعددة في واحدة.على الرغم من أن هذا لن يغير اللعبة ، إلا أن تشغيل حصة 1 × 2048 أمر أسهل بكثير من إدارة 64 × 32 حصص.
بالنسبة لمقدمي الخدمات المتنقلة عبر الهاتف المحمول ، الذين يجمعون الخداع الصغير من المستخدمين وتخصيصهم بين المدققين ، يضيف Electra مزيدًا من المرونة في نظام تخصيص الاهتمام ، ولكنهم يتطلبون أيضًا محاسبة للمقدين استنادًا إلى 32 أرصدة صالحة لـ ETH.

موضوع مهم آخر هو تقدير البيانات التاريخية والربح للمقدين ، وخاصة ذات الصلة بالمشاركين الجدد ، الذين يحاولون تقييم المخاطر والمكافآت.قبل Electra (حتى كتابة هذه السطور) ، تم إنشاء CAP 32 ETH (كلاهما الأصغر أو الأكبر ، في الواقع) التوحيد في البيانات التاريخية.جميع المحققين لديهم نفس رصيد التحقق من الصحة ، والمكافآت ، وعقوبات القطع الفردية ، وتواتر اقتراح الكتلة والمقاييس الأخرى.يتيح هذا التوحيد أن يسمح Ethereum باختبار آلية الإجماع الخاصة به دون القيم المتطرفة الإحصائية ، وبالتالي جمع بيانات سلوك الشبكة القيمة.

بعد Electra ، سيتغير توزيع Staking بشكل كبير.ستشارك المدققون الكبار في مقترحات الحظر ولجان التزامن بشكل متكرر ، مع زيادة العقوبات في التخفيضات وتأثير أكبر على التخفيضات المتأخرة وقوائم التنشيط وقوائم الخروج.على الرغم من أن هذا قد يخلق تحديات في تجميع البيانات ، إلا أن إجماع Ethereum يضمن أن الحوسبة غير الخطية ضئيلة.يستخدم المكون غير الخطي الوحيد SQRT (TOTAL_EFFICTION_BALANCE) لحساب المكافأة الأساسية ، والتي تنطبق على جميع المدققين.هذا يعني أنه لا يزال من الممكن تقدير المكافآت والتخفيضات على أساس “Per-1 ETH” (أو بشكل أكثر دقة ، استنادًا إلى spec.ffective_balance_increment ، والتي قد تتغير في المستقبل).

لمزيد من التفاصيل ، راجع مقالنا السابق حول سلوك المدقق.

EIP-7002: خروج طبقة التنفيذ القابلة للتنفيذ

المرجع: EIP-7002

يحتوي كل مصادقة في Ethereum على أزواج رئيسية: مفتاح نشط ومفتاح سحب.يعمل مفتاح BLS العام النشط كهوية رئيسية للمقالح في سلسلة المنارة ، والتي تستخدم لتوقيع الكتل ، والبراهين ، وتجمعات اللجان متزامنة ، و (قبل هذا EIP) المخرج الطوعي (لاتباع تأخير في إقرار الإقامة في موافقة الإدانة مخرج).يمكن أن يكون زوج المفتاح الثاني (“قسيمة السحب”) زوجًا آخر من مفاتيح BLS أو حساب ETH1 العادي (المفتاح الخاص والعنوان).الآن ، يجب استخراج رسائل السحب التي يتم توقيعها بواسطة مفتاح BLS الخاص النشط إلى عنوان ETH.تم تغيير هذا EIP.

في الواقع ، يمكن أن يكون أصحاب أزواج هاتين الاثنين (النشطين والانسحاب) مختلفًا.المفتاح النشط لـ Verifier مسؤول عن مسؤوليات التحقق: تشغيل الخادم ، وإبقائه يعمل بشكل طبيعي ، وما إلى ذلك ، وعادة ما يتم التحكم في قسائم السحب من قبل مالك الحصة ، الذي يتلقى المكافآت ويكون مسؤولاً عن الأموال.في الوقت الحاضر ، لا يمكن إلا لمالك التعهد الذي يتحكم في قسيمة السحب بدء خروج المدقق ، ويمكنه فقط سحب المكافأة.يتيح هذا الموقف لمالك المفتاح النشط الخاص بـ Verifier الاحتفاظ بتوازن Verifier بفعالية باعتباره “رهينة” في يده.يمكن للمقابلة “توقيع” رسالة الخروج مسبقًا وتسليمها إلى صاحب المصلحة ، لكن هذا الحل البديل ليس مثاليًا.بالإضافة إلى ذلك ، يتطلب كل من الاستخراج والخروج حاليًا التفاعل مع صحة طبقة منارة من خلال واجهة برمجة تطبيقات مخصصة.

أفضل حل هو السماح لمالك الحصة بأداء عمليات الخروج والسحب من خلال مكالمات العقد الذكية العادية.يتضمن ذلك فحص توقيع ETH1 القياسي ، والذي يبسط العمليات بشكل كبير.

يتيح هذا EIP لأصحاب المصلحة تشغيل عمليات السحب والخروج عن طريق إرسال المعاملات القياسية إلى عقود ذكية مخصصة من عنوان ETH الخاص بهم (على غرار عملية الإيداع الحالية باستخدام عقود “الإيداع”).تكون عملية الاستخراج (أو الخروج عند إزالة حصة كافية) كما يلي:

يرسل العهد طلب سحب (“في” طلب) إلى عقد “السحب” للنظام.
يتقاضى العقد رسومًا محددة (في ETH) للتخفيف من الهجمات الضارة المحتملة ، وعلى غرار EIP-1559 ، تزداد الرسوم عندما تكون قائمة انتظار الطلب مشغولة.
يحفظ العقد طلب “في” السحب/الخروج إلى تخزينه.
عند اقتراح كتلة إلى طبقة المنارة ، يتم استرداد طلب “في” السحب/الخروج في قائمة الانتظار من التخزين.
تقوم طبقة المنارة بمعالجة الطلب “في” ، وتتفاعل مع توازن المدقق النشط ، وترتب المدقق للخروج ، ويشكل طلب سحب “خارج”.
تتم معالجة طلب السحب “Out” في طبقة التنفيذ ، ويتلقى صاحب المصلحة ETH.

على الرغم من أن عمليات الودائع هي العمليات التي يتم تشغيلها في كتلة ETH1 ثم “تم نقلها” إلى طبقة منارة من خلال قائمة انتظار “الإيداع” المعلقة ، فإن عمليات السحب تتبع مخططات مختلفة.يتم تشغيلها على طبقة منارة (عبر CLI) ثم “نقل” إلى كتلة eth1.ستعمل كلا المخططين الآن من خلال نفس الإطار المشترك (كما هو موضح أدناه): قم بإنشاء طلب على طبقة ETH1 ، ومعالجة قوائم الإيداع/السحب/الدمج “المعلقة” ، ومعالجةها على طبقة منارة.بالنسبة لعمليات “الإخراج” مثل الانسحاب ، سيتم أيضًا معالجة قائمة انتظار الإخراج ، وسيتم “تسوية” النتيجة في كتلة eth1.

باستخدام EIP هذا ، يمكن لـ Stakerers استخدام المعاملات الأخلاقية العادية لاستخلاص وخروج مصادقيهم دون التفاعل المباشر مع CLI المدقق أو الوصول إلى البنية التحتية للمقاومة.هذا يبسط بشكل كبير عمليات التقييم ، وخاصة لمقدمي الخدمات الكبيرة.يمكن الآن أن تكون البنية التحتية للمقابلة معزولة تمامًا تقريبًا لأنه يتم الحفاظ على مفتاح التحقق النشط فقط ، في حين يمكن التعامل مع جميع عمليات التقييم في مكان آخر.إنه يلغي الحاجة إلى صانعي المستقلين لانتظار إجراءات المدقق النشط وتبسيط الجزء خارج السلسلة بشكل كبير من خدمات LIDO مثل وحدة Staking Community.

لذلك ، فإن هذا “EIP” يكمل “عملية المتهور ، وترحيلها تمامًا إلى طبقة ETH1 ، مما يقلل بشكل كبير من المخاطر الأمنية للبنية التحتية وتعزيز اللامركزية في مبادرات الاستئجار المستقلة.

EIP-6110: توريد ودائع التحقق على السلسلة

المرجع: EIP-6110

في الوقت الحالي ، يتم تحقيق الودائع من خلال الأحداث في عقد “الإيداع” للنظام (كما تمت مناقشته بالتفصيل في المقالات السابقة).يقبل العقد أحداث اعتماد ETH والتحقق والمشكلات “إيداع ()” ، والتي يتم تحليلها وتحويلها إلى طلبات الإيداع على طبقة المنارة.يحتوي النظام على العديد من العيوب: إنه يتطلب التصويت على ETH1DATA لطبقة سلسلة المنارة ، مما يضيف تأخيرات كبيرة.بالإضافة إلى ذلك ، تحتاج طبقة المنارة إلى الاستعلام عن طبقة التنفيذ ، مما يزيد من التعقيد.وتناقش هذه القضايا بالتفصيل في EIP.هناك طريقة أسهل للاستغناء عنها دون التعامل مع العديد من هذه المشكلات هي تضمين طلبات الإيداع مباشرة في كتلة eth1 في الموقع المحدد.تشبه هذه الآلية عملية معالجة الانسحاب الموضحة في EIP السابقة.

التغييرات المقترحة في هذا EIP واعدة.يمكن الآن إزالة معالجة ETH1DATA تمامًا ، ولم تعد مضطرًا للتصويت أو التأخير المطول بين الأحداث على الجانب ETH1 وإيداع شوائب على طبقة المنارة (حاليًا حوالي 12 ساعة).كما أنه يزيل منطق لقطات عقد الإيداع.يبسط EIP معالجة الإيداع ويحدده مع مخطط معالجة السحب الموضح أعلاه.

بالنسبة إلى Staker و Devidators ، فإن هذه التغييرات تقلل بشكل كبير من التأخير بين الإيداع وتفعيل المدقق.عندما يتم قطع المدققين ، ستكون المكملات الغذائية اللازمة أيضًا أسرع.

لا يوجد شيء آخر يمكن قوله عن هذا EIP ، إلا أنه يزيل المنطق القديم ، ويبسط العملية ويخلق نتائج أفضل لجميع المعنيين.

EIP-7685: طلب طبقة التنفيذ العامة

المرجع: EIP-7685

كان ينبغي اقتراح هذا EIP قبل أول ثلاثة eips المتعلقة بالإيداع/الانسحاب/الاندماج لأنه يضع الأساس لهذه EIPs.ومع ذلك ، فإن المقدمة هنا هي تسليط الضوء على الطلب المتزايد على البيانات المخصصة المتنافسة بين ETH1 (التنفيذ) وكتل سلسلة Beacon (الإجماع) (الطبقات).يؤثر هذا EIP على طبقتين ، مما يجعل معالجة الطلبات الناتجة عن المعاملات الأخلاقية التقليدية أكثر كفاءة.حاليا ، نلاحظ:

يتم “نقل” حدث الإيداع في كتلة eth1 إلى كتلة منارة للمعالجة.
يتم “نقل” طلب السحب (باستخدام CLI) في كتلة المنارة إلى كتلة ETH1 للمعالجة.
يجب معالجة دمج Verifier ، وهو أيضًا طلب ETH1- & GT ؛ منارة.

توضح هذه العمليات الثلاث ضرورة معالجة ثابتة لأنواع مختلفة من الطلبات عند التبديل بين طبقة التنفيذ وطبقة المنارة.علاوة على ذلك ، نحتاج إلى القدرة على تشغيل هذه العمليات باستخدام طبقة ETH1 فقط ، لأن هذا سيسمح لنا بعزل البنية التحتية للمقاومة من البنية التحتية لإدارة المدقق ، وبالتالي تحسين الأمن.لذلك ، فإن الحل العام لإدارة مثل هذه الطلبات عملية وضرورية.

تنشئ EIP إطارًا لثلاث مواقف رئيسية على الأقل: الودائع والسحب والاندماج.هذا هو السبب في أن EIP المبكر قدمت حقول مثل انسحاب jold_request_type و report_request_type ، والآن ستضيف الدمج حقلًا آخر ، consolidation_request_type.بالإضافة إلى ذلك ، قد تتضمن EIP آلية مشتركة للتعامل مع قيود مثل هذه الطلبات (ثوابت مرجعية: Pending_deposits_limit ، arend_partial_withdrawals_limit ، pending_consolidations_limit).

على الرغم من أن تفاصيل التنفيذ التفصيلية لهذا الإطار لا تزال غير متوفرة ، فإنها ستشمل بالتأكيد أنواع الطلبات الحرجة وآليات النزاهة (مثل الطلبات والتجزئة) ، ومعلقة معالجة قائمة الانتظار والحد من الأسعار.

هذا EIP ذو معنى معماريًا ، مما يمكّن ETH1 من تشغيل العمليات الحرجة في طبقة منارة من خلال إطار موحد.بالنسبة للمستخدمين والمشاريع النهائية ، فإن هذا يعني أنه سيتم تسليم جميع الطلبات التي يتم تشغيلها في طبقة ETH1 ومعالجتها بشكل أكثر كفاءة على طبقة المنارة.

EIP-2537: عملية منحنى BLS12-381

المرجع: EIP-2537

إذا كنت لا ترغب في الحصول على نظرة أعمق ، فيمكنك التفكير في عملية تجزئة BLS12-381 باعتبارها عملية تشفير معقدة “تجزئة” يمكن استخدامها الآن في العقود الذكية.للمهتمين ، دعونا نستكشف المزيد.

تستخدم العمليات الرياضية على المنحنيات الإهليلجية مثل BLS12-381 (و BN-254 المقابلة) حاليًا بشكل أساسي لأغراضين:

توقيعات BLS ، حيث يتم استخدام عملية خاصة تسمى “الاقتران” للتحقق من هذه التوقيعات.يتم استخدام توقيعات BLS على نطاق واسع من قبل التحقق لأنها تجمع التواقيع المتعددة في واحدة.يعتمد المدققون على توقيعات BLS بناءً على منحنيات BLS12-381 (على الرغم من أنها يمكن تنفيذها أيضًا باستخدام أي منحنى يدعم الاقتران ، مثل BN254).
التحقق من أدلة Zksnark ، حيث يتم استخدام الاقتران للتحقق من البراهين.بالإضافة إلى ذلك ، تستخدم التزامات KZG للقطع الكبيرة التي أدخلتها Dencun Hard Forks أيضًا الاقتران للتحقق من التزامات الكتلة.

إذا كنت ترغب في التحقق من توقيعات BLS أو أدلة Zksnark في عقد ذكي ، فيجب عليك حساب هذه “الأزواج” ، وهي مكلفة من الناحية الحسابية.لدى Ethereum بالفعل عقدًا مسبقًا (EIP-196 و EIP-197) لعملية منحنى BN254.ومع ذلك ، فإن منحنى BLS12-381 (الذي يعتبر الآن أكثر أمانًا وأكثر استخدامًا على نطاق واسع اليوم) لم يتم تنفيذه بعد على أنه مسبق.في حالة عدم وجود مثل هذه المجمعات ، يتطلب تنفيذ الاقتران وغيرها من عمليات المنحنى في العقود الذكية الكثير من الحسابات ، كما هو موضح هنا ، ويستهلك غازًا ضخمًا (حوالي 10^5 إلى 10^6 غاز).

يفتح EIP الباب أمام العديد من التطبيقات المحتملة ، خاصة في التحقق من توقيع BLS الرخيصة استنادًا إلى منحنى BLS12-381.هذا يجعل من الممكن تحقيق حلول العتبة لأغراض مختلفة.كما ذكرنا سابقًا ، استخدم مصادقو Ethereum التواقيع المستندة إلى BLS12-381.مع هذا EIP ، يمكن الآن للعقود الذكية القياسية التحقق من توقيعات المدقق المجمعة بكفاءة.يمكن أن يؤدي ذلك إلى تبسيط سد إثبات الإجماع وعبر أصول الشبكة ، حيث يتم استخدام تواقيع BLS على نطاق واسع في blockchains.تتيح توقيعات BLS العتبة نفسها بناء العديد من مخططات العتبة الفعالة للتصويت ، وتوليد الأرقام العشوائية اللامركزية ، وتوقيع متعدد ، وما إلى ذلك.

سوف يقوم التحقق من إثبات Zksnark أرخص بدوره بإلغاء قفل عدد كبير من التطبيقات.يتم إعاقة العديد من الحلول المستندة إلى Zksnark حاليًا بسبب ارتفاع تكاليف التحقق من الإثبات ، مما يجعل بعض المشاريع غير عملية تقريبًا.هذا EIP لديه القدرة على تغيير ذلك.

EIP-2935: حفظ التجزئة التاريخية في الدولة

المرجع: EIP-2935

يقترح هذا EIP تخزين 8192 (حوالي 27.3 ساعة) تجزئة الكتلة التاريخية في حالة blockchain ، وتوفير تاريخ ممتد للعملاء عديمي الجنسية مثل Rollups والعقود الذكية.وتوصي بالاحتفاظ بالسلوك الحالي لرمز OPCODE SCOLLHASH ، مع الحفاظ على حد على 256 كتلة ، مع تقديم عقد نظام جديد مصمم خصيصًا لتخزين واسترداد التجزئة التاريخية.يؤدي هذا العقد عملية set () عندما تقوم طبقة التنفيذ بمعالجة الكتلة.يمكن الوصول إلى طريقة GET () لأي شخص لاسترداد تجزئة الكتلة المطلوبة من المخزن المؤقت الحلقي.

حاليًا ، من الممكن الرجوع إلى تجزئة الكتلة التاريخية في EVM ، ولكن الوصول يقتصر على أحدث 256 كتل (حوالي 50 دقيقة).ومع ذلك ، يعد الوصول إلى بيانات الكتلة الأقدم أمرًا بالغ الأهمية في بعض الحالات ، خاصة بالنسبة للتطبيقات المتقاطعة (البيانات التي تتطلب كتل سابقة مثبتة) وعملاء عديمي الجنسية ، والتي تتطلب بشكل دوري الوصول إلى تجزئة الكتل المبكرة.

يمتد EIP هذا الإطار الزمني المتاح لتطبيقات Rollup و Cross-chain ، مما يسمح لهم بالوصول مباشرة إلى البيانات التاريخية في EVM دون الحاجة إلى جمعها خارجيًا.نتيجة لذلك ، تصبح هذه الحلول أكثر قوة واستدامة.

EIP-7623: زيادة تكلفة CallData

المرجع: EIP-7623

تنظم تكلفة CallData الحجم المتاح لحمولة المعاملات ويمكن أن تكون كبيرة في بعض الحالات (على سبيل المثال ، عند تمرير المصفوفات الكبيرة أو المخازن المؤقتة الثنائية كمعلمات).يعزى استخدام CallData المهم بشكل أساسي إلى Rollups ، والتي ترسل حمولات من خلال CallData التي تحتوي على حالة Rollup الحالية.

يعد تقديم بيانات ثنائية كبيرة مثبتة في blockchain أمرًا بالغ الأهمية.تقدم ترقية Dencun (DENEB-Cancun) ابتكارًا مهمًا لحالات الاستخدام هذه-معاملات BLOB (EIP-4844).تحتوي معاملات Blob على رسوم الغاز الخاصة بـ “blob” الخاصة بها.لذلك ، يوفر Blob حلاً أفضل لـ Rollup من استخدام CallData لتخزين البيانات.

شجع Rollup على نقل بياناتها إلى النقطة.يتم استخدام رسوم غاز النقطة المنخفضة كـ “جزر” ، ويؤدي هذا EIP إلى قيام تخزين البيانات المفرط في المعاملات عن طريق زيادة تكلفة CallData كـ “رافعة المالية”.يكمل EIP هذا EIP-7691 التالي (زيادة إنتاجية BLOB) ، مما يزيد من الحد الأقصى لعدد النقط المسموح به لكل كتلة.

EIP-7691: زيادة إنتاجية Blob

المرجع: EIP-7691

تم تقديم النقط في الشوكة الصلبة السابقة Dencun ، والقيم الأولية للحد الأقصى والهدف من النقاط “لكل كتلة” هي تقديرات محافظة.ويرجع ذلك إلى تعقيد التنبؤ بكيفية التعامل مع شبكة P2P مع انتشار الكائنات الثنائية الكبيرة بين عقد المدقق.لقد أثبت التكوين السابق جيدًا ، مما يجعل هذا الوقت المناسب لاختبار قيم جديدة.في السابق ، تم تعيين رقم النقطة الهدف/الحد الأقصى لكل كتلة على 3/6.يتم الآن رفع هذه القيود إلى 6/9 على التوالي.

إلى جانب EIP-7623 السابق (زيادة تكاليف CallData) ، يحفز هذا التعديل Rollup على نقل بياناته من CallData إلى blobs.يستمر عمل العثور على أفضل معلمات blob.

EIP-7840: أضف جدول Blob إلى ملف تكوين EL

المرجع: EIP-7840

يقترح هذا EIP إضافة العدد الهدف والحد الأقصى لـ “لكل كتلة” (تمت مناقشته سابقًا) وقيمة BaseFeeupDateFraction إلى ملف تكوين طبقة تنفيذ Ethereum (EL).كما أنه يمكّن العملاء من استرداد هذه القيم من خلال واجهة برمجة تطبيقات العقدة.هذه الميزة مفيدة بشكل خاص للمهام مثل تقدير تكاليف الغاز.

EIP-7702: إعداد رمز حساب EOA

المرجع: EIP-7702

هذا هو EIP مهم للغاية من شأنه أن يجلب تغييرات كبيرة لمستخدمي Ethereum.كما نعلم ، لا يمكن أن يكون لدى EOA (حساب مملوك خارجي) أي رمز ، ولكن يمكن أن يوفر توقيع معاملة (tx.origin).في المقابل ، فإن العقود الذكية لها رمز bytecode ، ولكن لا يمكن أن تقترح بشكل استباقي توقيعًا مباشرًا لـ “It”.يمكن لأي تفاعل مستخدم يتطلب منطقًا إضافيًا وتلقائيًا ويمكن التحقق منه إجراء الإجراءات المطلوبة حاليًا فقط عن طريق استدعاء العقود الخارجية.ومع ذلك ، في هذه الحالة ، يصبح العقد الخارجي هو msg.sender للعقد اللاحق ، مما تسبب في الدعوة إلى “المكالمة من العقد ، وليس المستخدم”.

يقدم EIP هذا set_code_tx_type = نوع المعاملة 0x04 (كان لدينا سابقًا معاملات 0x1 القديمة ، ومعاملات 0x02 جديدة من ترقيات برلين و EIP-1559 ، ومعاملات BLOB 0x03 المقدمة في Dencun).يسمح نوع المعاملة الجديد هذا بإعداد رموز حسابات EOA.في الواقع ، فإنه يسمح لـ EOA بتنفيذ الكود الخارجي “في سياق حساب EOA الخاص به.”من منظور خارجي ، أثناء عملية المعاملة ، يبدو أن EOA “اقتراض” الكود من العقد الخارجي وتنفيذه.من الناحية الفنية ، يتم تحقيق ذلك عن طريق إضافة tuple بيانات معتمدة إلى متجر “الكود” لعنوان EOA (كان هذا متجر “الكود” فارغًا دائمًا لـ EOA قبل هذا EIP).

حاليًا ، يحتوي نوع المعاملة 0x04 الجديد الذي اقترحه هذا EIP على صفيف:

Authorization_list = [[chain_id ، address ، nonce ، y_parity ، r ، s] ، …]

يسمح كل عنصر للحساب باستخدام الرمز من العنوان المحدد (من آخر عنصر إذن صالح).عند معالجة مثل هذه المعاملات ، يتم تعيين رمز EOA المعطى على قيمة العنوان 0xef0100 لا يمكن تضمين قيمة سحرية خاصة (وفقًا لـ EIP-3541).تضمن هذه القيمة السحرية أن هذه EOA لا يمكن اعتبارها عقدًا منتظمًا ، ولا يمكن أن يطلق عليها مثل العقد العادي.

عندما يبدأ هذا EOA في المعاملة ، سيتم استخدام العنوان المحدد للاتصال بالرمز المقابل في سياق EOA.على الرغم من أن تفاصيل التنفيذ الكاملة لهذا EIP ليست واضحة ، فمن المؤكد أنها ستجلب تغييرات كبيرة.

أحد التأثير الرئيسي هو القدرة على صنع متعددات مباشرة من EOA.تعد المكالمات المتعددة اتجاهًا ثابتًا في Defi ، وتوفر العديد من البروتوكولات هذه الميزة كأداة قوية (مثل UnisWap V4 أو Balancer V3 أو Euler V2).باستخدام EIP هذا ، يمكنك الآن بدء مكالمات متعددة مباشرة من EOA.

على سبيل المثال ، تحل هذه الميزة الجديدة مشكلة شائعة في Defi: الموافقة () + أي شيء () يتطلب عدم كفاءة معاملتين مستقلتين.يتيح هذا EIP منطق “التخصيص المسبق” الشائع ، بحيث يمكن إكمال (x) + الإيداع (x) في معاملة واحدة.

ميزة أخرى لتكون قادرة على “تمثيل” تنفيذ المعاملات بتكليف EOA هي مفهوم الرعاية.الرعاية هي ميزة تمت مناقشتها بشكل متكرر ومطلوب للغاية لمساعدة المستخدمين الجدد على إدخال Ethereum.

يفتح المنطق القابل للبرمجة المرتبط بـ EOA العديد من الاحتمالات مثل تنفيذ قيود الأمان ، وتحديد قبعات الإنفاق ، ومتطلبات KYC الإلزامية ، وأكثر من ذلك.

بالطبع ، يثير هذا التغيير أيضًا العديد من مشكلات التصميم.تتمثل إحدى المشكلات في استخدام chain_id ، والتي تحدد ما إذا كان التوقيع نفسه يمكن أن يكون صالحًا عبر شبكات متعددة ، اعتمادًا على ما إذا كان يتم تضمينه أو عدم تضمينه في التوقيع.هناك مشكلة معقدة أخرى وهي الاختيار بين استخدام عنوان الرمز الهدف وتضمين رمز Bytecode الفعلي.هاتان الطريقتان لهما خصائصهما الفريدة والقيود.بالإضافة إلى ذلك ، يلعب استخدام NonCE دورًا رئيسيًا في تحديد ما إذا كانت الأذونات “متعددة الأغراض” أو “الأغراض الفردية”.تؤثر هذه العناصر على المشكلات الوظيفية والأمان ، بما في ذلك توقيعات فشل الدُفعة وسهولة الاستخدام.أثار Vitalik هذه الأسئلة في مناقشة (هنا) ويستحق المزيد من الاستكشاف.

تجدر الإشارة إلى أن هذا التغيير سيؤثر على آلية أمان Ethereum ، TX.Origin.مزيد من التفاصيل حول تطبيق EIP ضروري ، ولكن يبدو أن سلوك المطلوبة (tx.origin == msg.sender) سيتغير.لطالما كان هذا الشيك هو الطريقة الأكثر موثوقية للتأكد من أن msg.sender هو EOA ، وليس عقدًا.طرق أخرى ، مثل التحقق من extcodesize (للتحقق مما إذا كان عقدًا) ، عادةً ما يفشل ويمكن التحايل عليه (على سبيل المثال عن طريق استدعاء المُنشئ أو نشر الكود على عنوان محدد مسبقًا بعد المعاملة).تُستخدم هذه الشيكات لمنع إعادة الدخول إلى هجمات قروض البرق ، ولكنها بعيدة عن المثالية ، لأنها تعيق أيضًا التكامل مع البروتوكولات الخارجية.بعد هذا eip ، حتى المطلوبة الموثوقة (tx.origin == msg.sender) يبدو أن التحقق قد أصبح قديمًا.يجب تكييف البروتوكول عن طريق إزالة هذه الشيكات ، لأن الفرق بين “EOA” و “العقد” لن يتم تطبيقه – الآن قد يكون هناك رمز ذي صلة لكل عنوان.

لا يزال الفصل بين EOA التقليدي والعقود الذكية غير واضح.هذا EIP يجرب Ethereum أقرب إلى تصميم مثل Ton ، حيث يكون كل حساب رمزًا قابل للتنفيذ بشكل أساسي.نظرًا لأن التفاعلات مع البروتوكولات تصبح أكثر تعقيدًا ، فإن استخدام المنطق القابل للبرمجة لتحسين تجربة المستخدم النهائي هو عملية طبيعية لهذا التطور.

ختاماً

من المقرر ترقية Prague /Electra (PECTRA) في مارس 2025.تشمل أهم تغييرات الخطة:

Variable Verifier – المخاطر الصالحة التي تصل إلى 2048 ETH ، والتي ستغير بشكل كبير توزيع الحصة ، وجدول الدقة ، وتبسيط إدارة مقدمي الخدمات الكبيرة من خلال دمج المخاطر الأصغر
قم بتحسين التفاعل بين طبقة التنفيذ وطبقة الإجماع ، وتبسيط تبادل البيانات بين كتلة التنفيذ ETH1 وكتلة سلسلة منارة.سيؤدي ذلك إلى تبسيط الودائع والتفعيلات والسحب والخارج ، وتسريع هذه العمليات ، ووضع الأساس لمزيد من التفاعل بين طبقة الإجماع وطبقة التنفيذ
دعم لتوقيعات BLS أرخص والتحقق من Zksnark مباشرة مع PROPOMPILATION PREFOMPILATION
شجع Rollups على تبني معاملات blob عن طريق زيادة عتبات المعاملات blob وزيادة تكاليف calldata
اجعل EOA بمثابة حساب قابل للبرمجة ، مما يمنحه مكالمات متعددة ، رعاية ، والميزات المتقدمة الأخرى

كما ترون ، سيكون لدى Pectra تأثير كبير على تجربة المستخدم النهائي لطبقة الإجماع والإجماع ، وكذلك طبقة التنفيذ.على الرغم من أننا لا نستطيع تحليل كل هذه التغييرات بالتفصيل من خلال التعليمات البرمجية في هذه المرحلة ، حيث لا يزال التطوير قيد التقدم ، إلا أننا سنغطي هذه التحديثات في المقالات المستقبلية.