إعادة توجيه العنوان الأصلي: شرح فوروارد هاردفورك براغ/إليكترا (بيكترا)

يقدم

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

تاريخ هارد فورك Ethereum 2.0 "إثبات الحصة" معقد. بدأت بإضافة طبقة المنارة إلى طبقة التنفيذ الحالية, إطلاق إجماع إثبات الحصة على طبقة المنارة مع الحفاظ على إثبات العمل على طبقة التنفيذ (Phase0 و Altair hardforks). ثم تم تنشيط PoS بالكامل في Bellatrix hardfork (على الرغم من عدم تمكين عمليات السحب). بعد ذلك ، سمحت Capella hardfork بعمليات السحب ، وإكمال دورة حياة المدقق. أحدث شوكة صلبة, Deneb (جزء من ترقية Dencun(Deneb / Cancun)), جلبت مراجعات طفيفة لمعلمات سلسلة المنارة, مثل النافذة الزمنية لتضمين الشهادات, التعامل مع المخارج الطوعية, وحد زبد المدقق. كانت التغييرات الأساسية في Dencun على طبقة التنفيذ ، حيث قدمت ابتكارات مثل معاملات blob ، وغاز blob ، والتزامات KZG للنقاط ، وإهمال عملية SELFDESTRUCT.

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

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

تقدم Electra العديد من الميزات لطبقة البيكون. تتضمن التحديثات الرئيسية:

• السماح للمدققين بامتلاك رصيد فعال يتراوح بين 32 و 2048 إثيريوم (بدلاً من 32 إثيريوم ثابتة).
• تمكين المحققين من ببدء الخروج باستخدام أوراق اعتماد "السحب" الثانوية (دون الحاجة إلى مفتاح المحقق النشط).
• تغيير كيفية معالجة إيث1 للودائع من قبل طبقة البيكون (التحرك بعيدًا عن تحليل الأحداث من عقد الوديعة).
• إضافة إطار عام جديد للتعامل مع الطلبات من عقود Eth1 العادية على طبقة الشعار (بطريقة مماثلة لكيفية إدارة الودائع قبل إليكترا).

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

• عقد مُعدّل مُعاينة داعم جديد يدعم منحنى BLS12-381 للتحقق من أدلة zkSNARK (بالإضافة إلى منحنى BN254 الشهير).
• عقد نظام جديد لتخزين والوصول إلى ما يصل إلى 8192 تجزئة تاريخية للكتلة (مفيدة للعملاء غير المتكاملين).
• تكاليف الغاز المرتبطة بالبيانات المتزايدة لتقليل حجم الكتلة وتشجيع المشاريع على نقل العمليات الكبيرة المتعلقة بالبيانات (مثل rollups) إلى blobs، التي تم تقديمها في Dencun.
• دعم عدد أكبر من الكتل لكل كتلة Eth1، جنبًا إلى جنب مع واجهة برمجة التطبيقات لقراءة هذه الأرقام.
• السماح لـ EOAs (الحسابات المملوكة خارجيًا) بامتلاك كود حسابها الخاص، مما يوسع بشكل كبير ما يمكن أن تفعله EOAs، مثل تنفيذ المكالمات المتعددة أو تفويض التنفيذ إلى عناوين أخرى.

لنشير إلى المقترحات الجديدة لتحسين إثيريوم (EIPs) ذات الصلة لتسهيل المزيد من النقاش:

• EIP-7251: زيادة الحد الأقصى للرصيد الفعال
• EIP-7002: تنفيذ طبقة المخرجات التي يمكن تشغيلها
• EIP-6110: إمداد إيداعات المحقق على السلسلة
• EIP-7549: نقل فهرس اللجنة خارج Attestation
• EIP-7685: طلبات طبقة التنفيذ متعددة الأغراض
• EIP-2537: تجهيز مسبق لعمليات منحنى BLS12-381
• EIP-2935: حفظ تجزئة تاريخية لتجزئة الكتل في الحالة
• EIP-7623: زيادة تكلفة بيانات الاستدعاء
• زيادة إنتاجية التدفق الغامضة EIP-7691
• EIP-7840: إضافة جدول blob إلى ملفات تكوين EL
• EIP-7702: تعيين كود حساب EOA

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

EIP-7251: زيادة الحد الأقصى للرصيد الفعال

المرجع: EIP-7251

منذ أول شوكة صلبة من Phase0 ، تم تنفيذها لإعداد Ethereum لإثبات الحصة ، وحتى Electra ، تم تحديد الحد الأقصى للرصيد الفعال للمدقق عند 32 ETH. يتطلب تنشيط المدقق spec.min_activation_balance على الأقل (32 ETH). بعد التنشيط ، يبدأ المدقق بهذا الحد الأقصى للرصيد الفعال ولكن يمكنه تقليل رصيده الفعال إلى spec.ejection_balance (16 ETH) ويتم إخراجه عند الوصول إلى هذا الحد. يظل منطق "الحد الأدنى" هذا دون تغيير في Electra ، ولكن الآن زاد spec.max_effective_balance إلى 2048 ETH. نتيجة لذلك ، يمكن للمدقق إيداع ما بين 32 و 2048 ETH للتنشيط ، مع مساهمة جميع المبالغ في هذا النطاق في رصيدها الفعال. يمثل هذا التحول انتقالا من "إثبات حصة 32ETH" إلى "إثبات الحصة" :)

سيتم استخدام الرصيد الفعال المتغير الآن:

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

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

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

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

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

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

حدود "churn limits" الخاصة بالمحققين تتغير أيضًا بسبب زيادة الأرصدة الفعالة. في إثيريوم "قبل إليكترا"، يكون لدى المحققين عمومًا نفس الرصيد الفعال، ويُحدد حد الخروج بأن "لا يمكن لأكثر من 1/65536 (معامل حد الخرج) من الرهان الإجمالي أن يغادر في حقبة واحدة." هذا يخلق عددًا "ثابتًا" من خروج المحققين بنفس الرهان. ومع ذلك، في "بعد إليكترا"، من الممكن حدوث سيناريو حيث يخرج فقط بعض "الحيتان"، حيث يمثلون جزءًا كبيرًا من الرهان الإجمالي.

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

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

للتلخيص:

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

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

بعد إلكترا، ستتغير توزيع الحصص بشكل كبير. سيشارك المحققون الكبار بشكل أكثر في اقتراحات الكتل واللجنة المتزامنة، وسيتلقون عقوبات أكبر في حالات التقليص، وسيكون لديهم تأثير أكبر على التقليصات المؤجلة وقوائم التفعيل وقوائم الخروج. على الرغم من أن هذا قد يخلق تحديات في تجميع البيانات، إلا أن توافق إثيريوم يضمن أن الحسابات غير الخطية تكون دقيقة. يستخدم المكون غير الخطي الوحيد sqrt(total_effective_balance) لحساب الجائزة الأساسية، والتي تنطبق بشكل موحد على جميع المحققين. هذا يعني أنه يمكن لا يزال تقدير مكافآت المحقق والتخفيضات على أساس "لكل 1 ETH" (أو، بدقة أكبر، لكل تخصيص متزايد للرصيد، والذي قد يتغير بشكل محتمل في المستقبل).

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

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

الإشارة: EIP-7002

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

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

الحل الأمثل هو السماح لمالكي الرهان بأداء كل من عمليات الخروج والسحب باستخدام استدعاء عقد ذكي منتظم. وهذا ينطوي على فحص توقيع Eth1 القياسي، مما يبسط بشكل كبير العمليات.

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

• يقوم مالك الحصة بإرسال طلب سحب (طلب "داخلي") إلى عقد "السحوبات" في النظام.
• يفرض العقد رسومًا محددة (بالإثيريوم) للحد من هجمات الإزعاج المحتملة ويعمل بشكل مماثل لـ EIP-1559، حيث تزيد الرسوم عندما يكون طابور الطلبات مشغولًا.
• يحفظ العقد طلب السحب/الخروج "in" إلى تخزينه.
• عندما يتم اقتراح كتلة لطبقة البيكون، يتم استرجاع طلبات الانسحاب/الخروج "in" المعلقة من التخزين.
• يقوم طبقة الشعلة بمعالجة طلبات "in"، والتفاعل مع رصيد المحقق النشط، وجدولة المحقق للخروج، وتشكيل طلبات السحب "out".
• يتم معالجة طلبات السحب "الخارجية" على طبقة التنفيذ، وصاحب الحصة يستلم إثيريومهم.

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

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

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

EIP-6110: إمداد إيداعات المحقق على السلسلة

المرجع: EIP-6110

حالياً، يتم تنفيذ الودائع عبر الأحداث في عقد "الإيداع" في النظام (كما تم مناقشته بالتفصيل في مقال سابق). يقبل العقد ETH وبيانات المحقق، ويبعث حدث "الإيداع()"، ويتم تحليل هذه الأحداث في وقت لاحق وتحويلها إلى طلبات إيداع على طبقة الشعاع. هذا النظام يحتوي على عيوب كثيرة: فهو يتطلب التصويت على eth1data على طبقة سلسلة الشعاع، مما يضيف تأخيرات كبيرة. بالإضافة إلى ذلك، تحتاج طبقة الشعاع للاستعلام عن طبقة التنفيذ، مما يقدم تعقيدات إضافية. يتم مناقشة هذه المشاكل بالتفصيل في EIP. طريقة أبسط، تقضي على العديد من هذه المشاكل، تتضمن تضمين طلبات الإيداع مباشرة في كتل Eth1 في موقع مخصص. يعكس هذا الآلية عملية معالجة السحب الموضحة في EIP السابق.

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

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

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

EIP-7685: طلبات طبقة التنفيذ متعددة الأغراض

المرجع: EIP-7685

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

• تحول أحداث الإيداع في الكتل Eth1 من "نقلها" من كتل Eth1 إلى كتل الشعاع للمعالجة.
• طلبات السحب في كتل Beacon (باستخدام CLI) تُحول "إلى" كتل Eth1 للمعالجة.
• الحاجة إلى التعامل مع تجميعات المحققين، التي هي أيضًا طلبات Eth1->Beacon.

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

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

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

يحمل هذا 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 fork) تستخدم أيضًا الزوجين للتحقق من التزامات التجمع.

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

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

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

EIP-2935: حفظ تجارب الكتل التاريخية في الحالة

المرجع: EIP-2935

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

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

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

EIP-7623: زيادة تكلفة البيانات الواردة

المرجع: EIP-7623

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

تعد القدرة على إدخال بيانات ثنائية كبيرة يمكن إثباتها في blockchain أمرا ضروريا لعمليات التراكم. قدمت ترقية Dencun (Deneb-Cancun) ابتكارا رئيسيا لحالات الاستخدام هذه - معاملات blob (EIP-4844). معاملات Blob لها رسوم غاز "blob" مخصصة لها ، وبينما يتم تخزين أجسامها مؤقتا ، يتم دمج براهين التشفير الخاصة بها (التزامات KZG) ، جنبا إلى جنب مع تجزئتها ، في طبقة الإجماع. وبالتالي ، توفر النقط حلا فائقا لعمليات التجميع مقارنة باستخدام calldata لتخزين البيانات.

يمكن تحقيق تشجيع rollups على تحويل بياناتها إلى blobs باستخدام نهج "الجزرة والعصا". تعمل رسوم الغاز الخاصة ب blobs المخفضة كـ "الجزرة"، بينما تعمل هذه EIP كـ "العصا" من خلال زيادة تكاليف ال calldata، مما ي desu المخزنات الزائدة للبيانات في المعاملات. تكمل هذه EIP EIP-7691 القادمة (زيادة تدفق blobs)، التي ترفع الحد الأقصى لعدد blobs المسموح بها في كل كتلة.

زيادة معدل نقل البيانات في EIP-7691: البلوب

المرجع: EIP-7691

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

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

EIP-7840: إضافة جدول blob إلى ملفات تكوين EL

المرجع: EIP-7840

تقترح هذه EIP إضافة الهدف والحد الأقصى لعدد "الكتل" (التي تم مناقشتها سابقًا) وقيم baseFeeUpdateFraction إلى ملفات تكوين Ethereum Execution Layer (EL). كما يتيح للعملاء استرداد هذه القيم من خلال واجهة برمجة التطبيقات (API) للعقد. تعتبر هذه الميزة مفيدة بشكل خاص لمهام مثل تقدير رسوم الغاز للكتل.

EIP-7702: تعيين كود حساب EOA

المرجع: EIP-7702

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

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

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

authorization_list = [[chain_id، address، nonce، y_parity، r، s]، ...]

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

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

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

على سبيل المثال، تُحل هذه الميزة الجديدة مشكلة شائعة في DeFi: عدم كفاءة approve() + anything() الذي يتطلب صفقتين منفصلتين. يسمح هذا EIP بمنطق "الموافقة المسبقة" العام، مما يتيح أن تُكمل الأفعال مثل approve(X) + deposit(X) في صفقة واحدة.

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

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

بطبيعة الحال ، يثير هذا التحول أيضا العديد من أسئلة التصميم. وتتمثل إحدى المسائل في استخدام chain_id، الذي يحدد ما إذا كان التوقيع نفسه يمكن أو لا يمكن أن يكون صالحا عبر شبكات متعددة استنادا إلى إدراجه أو استبعاده في التوقيع. مسألة معقدة أخرى هي ما إذا كان يجب استخدام عنوان الكود الهدف مقابل تضمين الرمز الثانوي الفعلي. كلا النهجين لهما ميزات وقيود فريدة. بالإضافة إلى ذلك ، يلعب استخدام nonce دورا رئيسيا في تحديد ما إذا كانت الأذونات "متعددة الاستخدامات" أو "ذات استخدام واحد". تؤثر هذه العناصر على الميزات والمخاوف الأمنية ، بما في ذلك جوانب مثل الإبطال الجماعي للتوقيعات وسهولة الاستخدام. أثار فيتاليك هذه الأسئلة في مناقشة (هنا) ، والتي تستحق المزيد من الاستكشاف.

من الأهمية بمكان ملاحظة أن هذا التغيير سيؤثر على إحدى آليات أمان Ethereum ، tx.origin. هناك حاجة إلى مزيد من التفاصيل حول تنفيذ EIP هذا ، ولكن يبدو أن سلوك يتطلب (tx.origin == msg.sender) سيتغير. كان هذا الفحص هو الطريقة الأكثر موثوقية للتأكد من أن msg.sender هو EOA وليس عقدا. غالبا ما تفشل الطرق الأخرى ، مثل التحقق من EXTCODESIZE (للتحقق مما إذا كان عقدا) ، ويمكن تجاوزها (على سبيل المثال ، عن طريق الاتصال من منشئ أو عن طريق نشر التعليمات البرمجية في عنوان محدد مسبقا بعد المعاملة). تم استخدام هذه الفحوصات لمنع هجمات إعادة الدخول والقروض السريعة ولكنها بعيدة كل البعد عن المثالية لأنها تعيق أيضا التكامل مع البروتوكولات الخارجية. بعد EIP هذا ، حتى التحقق الموثوق به يتطلب (tx.origin == msg.sender) يبدو أنه عفا عليه الزمن. يجب أن تتكيف البروتوكولات عن طريق إزالة عمليات التحقق هذه ، حيث لن يتم تطبيق التمييز بين "EOA" و "العقد" - الآن يمكن أن يكون لكل عنوان رمز مرتبط.

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

استنتاج

من المقرر أن يتم ترقية براغ/إليكترا (بيكترا) في مارس 2025. تشمل التغييرات المخطط لها الأكثر أهمية:

• مشاركة المحققين المتغيرة الفعالة، تصل إلى 2048 ETH، والتي ستغير تغييرا كبيرا توزيع المشاركة، جداول المحققين، وتبسيط الإدارة لمقدمي الرهن الكبيرة من خلال توحيد المشاركات الأصغر
• تحسين التفاعل بين طبقة التنفيذ والتوافق، وتبسيط تبادل البيانات بين كتل تنفيذ Eth1 وكتل سلسلة Beacon. سيبسط هذا إلى حد كبير عمليات الودائع والتنشيط والسحب والخروج، مما يعزز هذه العمليات ويمهد الطريق لمزيد من التفاعلات بين طبقات التوافق والتنفيذ
• دعم عمليات التحقق من توقيع BLS و zkSNARK الأرخص مباشرة في العقود الذكية من خلال التحويل البرمجي المسبق الجديد "الصديق للاقتران" BLS12-381
• مواصلة تشجيع الروابط لاعتماد معاملات blob بدلاً من البيانات الداخلية عن طريق زيادة عتبات معاملات blob ورفع تكاليف البيانات الداخلية
• تمكين حسابات الأشخاص الطبيعيين القائمة كحسابات قابلة للبرمجة، مما يمنحهم ميزات مثل المكالمات المتعددة، والرعاية، وغيرها من الوظائف المتقدمة

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

اخلاء المسؤوليه:

1. هذه المقالة مأخوذة من [ تك فلو]. إلى الأمام العنوان الأصلي: وأوضح هاردفورك براغ / إلكترا (بكترا). حقوق الطبع والنشر تنتمي إلى المؤلف الأصلي [MixBytes]. إذا كان لديك أي اعتراض على إعادة الطبع ، يرجى الاتصال فريق جيت للتعلم, وسيقوم الفريق بالتعامل معه في أقرب وقت ممكن وفقاً للإجراءات ذات الصلة.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة تمثل فقط وجهات نظر المؤلف الشخصية ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة النسخ الأخرى من المقال بواسطة فريق تعلم gate. ما لم يذكر خلاف ذلك، قد لا يتم نسخ أو توزيع المقال المترجم أو سرقته.