في مقالاتنا السابقة ، قمنا بمراجعة مفصلة لدورة حياة محققي إثريوم وناقشنا العديد من الجوانب المتعلقة بالتحويل الصلب Electra القادم. الآن حان الوقت للتركيز على التغييرات في التحديثات المقبلة Electra و Prague وشرحها بالتفصيل.
تاريخ الشوكة الصلبة لـ Ethereum 2.0 Proof of Stake معقد. بدأت بإضافة طبقة البيانات إلى الطبقة التنفيذية الحالية ، حيث تم تشغيل الوضع Proof of Stake على طبقة البيانات ، في حين أن الطبقة التنفيذية لا تزال تعمل بنمط Proof of Work (Phase0 و Altair Hard Fork). ثم تم تنشيط PoS بالكامل في الشوكة الصلبة Bellatrix (على الرغم من عدم تمكين السحب). ثم سمحت الشوكة الصلبة Capella بالسحب ، واكتملت حياة المحققين. أجريت تعديلات طفيفة على معلمات سلسلة البيانات في الشوكة الصلبة الأخيرة Deneb (جزء من ترقية Dencun (Deneb/Cancun)) ، مثل نافذة الوقت للإثبات ومعالجة الانسحاب الطوعي وقيود تغيير المحقق. تغيرات رئيسية في Dencun حدثت في الطبقة التنفيذية ، حيث تم إطلاق معاملات Blob وغاز Blob والتزامات KZG لـ Blob ، وتم التخلي عن عملية SELFDESTRUCT.
الآن ، يقوم تحديث فرعي صلب لـ Prague/Electra (المعروف أيضًا باسم Pectra) بإدخال تحسينات مهمة على مستوى التنفيذ والتوافق. بصفتنا مدققي مشروع Lido ، نركز بشكل رئيسي على التغييرات ذات الصلة بالتوافق والرهن الواردة في هذا التحديث الصلب. ومع ذلك ، لا يمكننا تجاهل التغييرات الواردة على مستوى التنفيذ في Prague ، لأنها تشمل سمات هامة تؤثر على شبكة Ethereum والمحققين. دعونا نستكشف تفاصيل هذه التغييرات.
نظرة عامة أعلى لـ Pectra
Electra قدمت العديد من المزايا لطبقة العلامات التجارية. وتشمل التحديثات الرئيسية:
تسمح رصيد المحقق الصالح بالتغير بين 32 و 2048 ETH (بدلاً من ثابت 32 ETH).
يُسمح للمعتمدين ببدء سحب الأموال من خلال إيصال السحب من المستوى الثاني (لا يلزم مفتاح المعتمد النشط بعد الآن).
تغيير طريقة معالجة إيداعات Eth1 في طبقة البيانات المرجعية (لا يتم معالجتها بعد الآن من خلال تحليل حدث الإيداع).
إضافة إطار عام جديد لمعالجة طلبات العقود العادية من Eth1 على طبقة البوصلة (مماثلة لطريقة إدارة إيداع Electra السابقة).
في الوقت نفسه، قام براغ بإدخال التغييرات التالية على المستوى التنفيذي:
عقد معدل جديد يدعم منحنى BLS12-381 للتحقق من الأدلة zkSNARK (باستثناء المنحنى الشائع BN254).
عقد نظام جديد لتخزين والوصول إلى ما يصل إلى 8192 هاش للكتل التاريخية (مفيد للعملاء غير الحالة).
زيادة تكلفة الغاز calldata لتقليل حجم الكتلة وتشجيع المشاريع على نقل العمليات الكثيفة ل calldata (مثل rollup) إلى الكتل المميزة التي تم إدخالها في Dencun.
يدعم كمية أكبر من الكتل لكل كتلة Eth1 ويوفر واجهة برمجة تطبيقات لقراءة هذه الكمية.
يسمح لـ EOA (حساب المالك الخارجي) بامتلاك رمز حسابه الخاص، مما يوسع بشكل كبير العمليات التي يمكن لحساب EOA تنفيذها، مثل تنفيذ المكالمات المتعددة أو تفويض التنفيذ إلى عناوين أخرى.
دعونا نشير إلى الاقتراحات الخاصة بتحسين إيثيريوم (EIP) ذات الصلة لمناقشتها بشكل أعمق:
EIP - 7251 : زيادة ماكس \ _EFFECTIVE \ _BALANCE
EIP-7002: الخروج القابل للتنفيذ في الطبقة التنفيذية
EIP-6110: توفير إيداع المحقق السلسلة
EIP-7549: نقل فهرس اللجنة من البرهان
EIP-7685: طلب طبقة التنفيذ العامة
EIP-2537: ترميز مسبق لعمليات منحنى BLS12-381
EIP-2935: الاحتفاظ بتاريخ تجزئة كتلة في الحالة
EIP-7623: زيادة تكلفة calldata
تزايد طاقة التدفق للملفات EIP-7691
EIP-7840: إضافة جدولة blob إلى ملف تكوين EL
EIP-7702: تعيين كود حساب EOA
هذه الأوراق المالية البديلة تتعلق بشكل رئيسي بطبقة الاتفاق (العلامة)، بينما البعض الآخر يتعلق بطبقة التنفيذ. بعضها يتجاوز الطبقتين، لأن بعض العمليات (مثل الودائع والسحب) تتطلب تغييرات متزامنة بين طبقة الاتفاق وطبقة التنفيذ. نظرًا لهذا التبادل التبادلي، فإن فصل Electra و Prague ليس واقعيًا، لذلك سنستعرض كل EIP بالترتيب ونحدد المكونات في إيثريوم التي تتأثر في كل حالة.
EIP-7251: زيادة الحد الأقصى \ _EFFECTIVE \ _BALANCE
المرجع: EIP-7251
منذ أول عملية انقسام Phase0 ، استعدادا لإثبات حصة Ethereum ، تم تحديد الحد الأقصى للرصيد الفعال للمدققين عند 32 ETH حتى Electra. متطلبات مدقق التنشيط هي على الأقل spec.min_activation_balance (32 ETH). بمجرد التنشيط ، يبدأ المدققون بهذا الحد الأقصى للرصيد الفعال ، ولكن يمكنهم تقليل رصيدهم الفعال إلى spec.ejection \ _balance (16 ETH) ويتم طردهم عند الوصول إلى هذا الحد. يظل هذا المنطق "الأدنى" كما هو في إلكترا ، ولكن الآن زاد spec.max_effective_balance إلى 2048 ETH. نتيجة لذلك ، يمكن للمدققين إيداع ما بين 32 و 2048 ETH للتنشيط ، وكل ذلك سيساهم في رصيدهم الفعال. يمثل هذا التحول تحولا من "32ETH - إثبات الحصة" إلى "إثبات الحصة": )
سيتم استخدام الرصيد الصالح المتغير حاليًا ل:
زيادة احتمالية أن تصبح مقترحًا للكتلة ، تتناسب مع الرصيد الصالح
زيادة احتمالية أن تصبح عضوًا في اللجنة المتزامنة ، متناسبة مع الرصيد الصالح
كأساس لحساب تخفيض العقوبات النسبية والغير نشطة
الأنشطة الأولى هي العمليات الأكثر عائدًا للمحققين. لذا بعد Electra، ستشارك المحققون ذوو الرهن الكبير بشكل أكثر تواترًا في اقتراح الكتل واللجنة المتزامنة، وتتناسب ترددهم مع الرصيد الفعال الخاص بهم.
آخر تأثير متعلق بالتقليص. جميع العقوبات على التقليص تتناسب مع رصيد المحقق الفعال:
تخفيض الغرامة على "فورية" و "مؤجلة" أكبر للمحققين ذوي الرهن العالي.
*مع مخفض الحاجز الذي يحتوي على رهونات عالية، يكون الغرامة "المؤجلة" للتخفيض أكبر أيضًا، لأن الجزء المخفض من الإجمالي يصبح أكبر.
الإبلاغ عن المحققين الذين يمتلكون رصيدًا صالحًا عاليًا يحصل المبلغ الأعلى من خفض الرهن.
قدمت إليكترا أيضًا تغييرًا في نسبة الاقتطاع ، حيث تعرف جزءًا من رصيد المحقق المقتطع ويتلقاه المبلغ.
الخطوة التالية هي تأثير البطالة. عندما يكون المحقق غير متصل (برهان أو اقتراح) عندما يكون نشطًا، يتم تراكم درجة البطالة، مما يؤدي إلى فرض عقوبات على البطالة في كل دورة. هذه العقوبات مرتبطة أيضًا برصيد المحقق الصالح بنسبة مئوية.
نظرًا لزيادة الرصيد الفعال، فإن 'قيود الاستبدال' للمحققين تغيرت أيضًا. في 'إثيريوم قبل Electra'، غالبًا ما يكون لدى المحققين رصيد فعال مماثل، وتعريف قيود الاستبدال للخروج هو 'في دورة واحدة، يمكن لأكثر من 1/65536 (spec.churn_limit_quotient) من الرهن الإجمالي أن يخرج.' هذا خلق 'ثابت' يخرج كمية محددة من المحققين بنفس الرهن. ومع ذلك، بعد 'Electra'، قد يحدث خروج لعدد قليل فقط من 'الحيتان'، لأنها تمثل جزءًا هامًا من الرهن الإجمالي.
واحدة من النظر فيها هي تناوب مفاتيح التحقق العديدة على نسخة واحدة من مفتاح التحقق. حاليًا، يتم إجبار المفتشين الكبار على تشغيل آلاف مفاتيح التحقق على نسخة واحدة لتتكيف مع الرهن الكبير وتقسيمه إلى أجزاء بقيمة 32 إثريوم. مع Electra، لم يعد هذا السلوك إلزاميًا. من الناحية المالية، لا يؤثر هذا التغيير كثيرًا، نظرًا لأن المكافأة والاحتمالية تتناسب بشكل خطي مع مبلغ الرهن. وبالتالي، يعادل 100 مفتش بقيمة 32 إثريوم كاملة مفتشًا واحدًا بقيمة 3200 إثريوم. بالإضافة إلى ذلك، يمكن أن يكون لدى عدة مفاتيح تحقق نشطة مستند Eth1 مماثل، مما يسمح بسحب جميع المكافآت إلى عنوان إثريوم واحد، وبالتالي تجنب تكاليف الغاز المرتبطة بدمج المكافآت. ومع ذلك، فإن إدارة عدد كبير من المفاتيح ستؤدي إلى تكاليف إدارية إضافية.
زادت قدرة تجميع رصيد المحققين على نوع جديد من طلب التنفيذ. في الماضي، كان لدينا الإيداع والسحب. الآن، سيكون هناك نوع آخر: طلب التجميع. سيجمع بين محققين اثنين في واحد. سيتضمن طلب العملية المفتاح العام للمحقق المصدر والمفتاح العام المستهدف، وسيتم معالجته على غرار الإيداع والسحب. سيكون للتجميع أيضًا طلبات قيد المعالجة وقيود تغيير الرصيد، تمامًا مثل الإيداع والسحب.
يتم تلخيصها على النحو التالي:
لمراقبي التحقق المستقلين الصغار ، قدمت Electra القدرة على زيادة رصيدهم الصالح (والمكافأة) تلقائيًا. في السابق ، كان يمكن سحب أي فائض أكثر من 32 ETH فقط ، ولكن بعد Electra ، سيتم التبرع بالفائض هذا في نهاية المطاف لرصيدهم الصالح. ومع ذلك ، يمكن زيادة الرصيد الصالح فقط بمضاعفات spec.effective_balance_increment (1 ETH) ، مما يعني أن الزيادة تحدث فقط عندما يتم تحقيق الحد التالي لـ "1 ETH".
بالنسبة للمدققين المستقلين الكبار ، توفر Electra تبسيطا كبيرا للإدارة من خلال السماح بدمج مفاتيح مدقق نشطة متعددة في مفتاح واحد. على الرغم من أن هذا لن يغير قواعد اللعبة ، إلا أن تشغيل حصة 1x2048 هو بلا شك أبسط بكثير من إدارة تخزين 64 × 32.
بالنسبة لمقدمي الرهن السريع ، يقومون بجمع الرهن الصغير من المستخدمين وتوزيعه بين المحققين ، تضيف Electra مزيدًا من المرونة في نظام توزيع الرهن ، ولكنها تتطلب أيضًا إعادة بناء كبير لمحاسبة المحققين الذين يعتمدون على رصيد صحيح مقداره 32 ETH.
موضوع آخر مهم هو بيانات المحققين التاريخية وتقدير الأرباح ، وهو ذو صلة خاصة بالمشاركين الجدد الذين يحاولون تقييم المخاطر والعوائد. قبل Electra (حتى كتابة هذا المقال) ، قام الحد الأعلى لـ 32 ETH (سواء كانت الحد الأدنى أو الأقصى فعليًا) بإنشاء تكافؤ في البيانات التاريخية. رصيد المحققين الفعال ، والمكافآت ، والعقوبات الفردية للتقليل ، ومعدل اقتراح الكتل ، ومؤشرات أخرى ، كلها متماثلة. هذا التكافؤ يتيح لـ Ethereum اختبار آلية الاتفاق الخاصة بها بدون قيم استثنائية إحصائية ، مما يسمح بجمع بيانات سلوك الشبكة ذات القيمة.
بعد إلكترا، ستحدث تغييرات كبيرة في توزيع الإيداعات. سيكون مشاركة المحققين الكبار في اقتراح الكتل واللجنة المتزامنة أكثر تكرارًا، وسيواجهون عقوبات أكبر في حالات التقليص، كما ستكون لها تأثير أكبر على تأخير التقليص وقائمة الانتظار وقائمة الخروج. وعلى الرغم من أن هذا قد يشكل تحديًا في تجميع البيانات، إلا أن توافق إثيريوم يضمن أن الحساب غير الخطي هو الحد الأدنى. يستخدم المكون الوحيد غير الخطي sqrt(total_effective_balance) لحساب الأجر الأساسي، وهذا ينطبق على جميع المحققين. وهذا يعني أن أجور المحققين والتقليص ما زال يمكن تقديرها بناءً على "كل 1 إيثر" (أو بدقة أكبر، وفقًا لـ spec.effective_balance_increment، والتي قد تتغير في المستقبل).
لمزيد من المعلومات التفصيلية، يرجى الاطلاع على مقالنا السابق حول سلوك المحققين.
EIP-7002：الخروج القابل للتنفيذ من طبقة الخروج
مرجع: EIP-7002
كل مُوثَّق في Ethereum لديه زوجان من المفاتيح: مفتاح نشط ومفتاح سحب. يُستخدم المفتاح العام BLS النشط كهوية رئيسية للمُوثَّق في سلسلة الإشارات، حيث يُستخدم هذا الزوج من المفاتيح لتوقيع الكتل والإثبات والتقليص وتجميع اللجان المتزامنة، وكذلك (قبل هذا EIP) الخروج الطوعي (للموافقة على خروج موثق الإجماع بعد تأخير). الزوج الثاني من المفاتيح ("إثبات السحب") يمكن أن يكون آخر زوج من مفاتيح BLS أو حساب Eth1 العادي (مفتاح خاص وعنوان). الآن، يتطلب استخراج عنوان ETH توقيع رسالة السحب بواسطة المفتاح الخاص BLS النشط. قامت هذه EIP بتغيير ذلك.
في الواقع ، يمكن أن يكون مالكو هذين الزوجين من المفاتيح (النشطة والسحب) مختلفين. المفتاح النشط للمدقق مسؤول عن واجبات التحقق: تشغيل الخادم ، والحفاظ عليه وتشغيله ، وما إلى ذلك ، بينما يتم التحكم في بيانات اعتماد السحب عادة من قبل مالك الحصة ، الذي يتلقى المكافآت ويكون مسؤولا عن الأموال. في الوقت الحالي، لا يمكن إلا لمالك الحصة الذي يتحكم في بيانات اعتماد السحب بدء سحب المدقق ويمكنه فقط سحب المكافأة. يسمح هذا الموقف لمالك المفتاح النشط للمدقق بالاحتفاظ برصيد المدقق بشكل فعال باعتباره "رهينة". يمكن للمدققين "التوقيع المسبق" على رسالة الخروج وتسليمها إلى مالك الحصة ، لكن هذا الحل البديل ليس مثاليا. بالإضافة إلى ذلك, يتطلب كل من الاستخراج والسحب حاليا التفاعل مع مدققي طبقة المنارة من خلال واجهة برمجة تطبيقات مخصصة.
أفضل حل هو السماح لمالك الرهن بتنفيذ عمليات الإلغاء والسحب بنفس الوقت من خلال استدعاء العقد الذكي العادي. ينطوي ذلك على فحص توقيع Eth1 القياسي ، مما يبسط العملية بشكل كبير.
يتيح هذا EIP لأصحاب الرهن الإفراج عن الأموال وسحبها عن طريق إرسال المعاملات القياسية من عناوين ETH الخاصة بهم إلى عقد ذكي خاص لتنفيذ السحب والإفراج (مشابه لعملية الإيداع باستخدام العقد الحالي للإيداع). عملية السحب (أو الإفراج التي يتم تنفيذها عندما يكون هناك ما يكفي من الرهن) تتم على النحو التالي:
يُرسل طلب السحب (طلب "in") من المقامر إلى عقد "السحب" في النظام.
يتم احتساب رسوم محددة للعقد (بالتحويل إلى ETH) للحد من الهجمات الخبيثة المحتملة وعلى غرار EIP-1559 ، فإن الرسوم تزداد عند ازدحام قائمة الطلبات.
يقوم العقد بحفظ طلبات السحب / الانسحاب لـ "in" في تخزينه.
عندما يتم اقتراح كتلة على طبقة العلامات ، سيتم استرداد طلبات السحب / الانسحاب في قائمة الانتظار من التخزين.
يُعالج طبقة البيانات الشعارات الطلبات 'in'، ويتفاعل مع رصيد المحققين النشطين، ويُرتب لخروج المحققين ويشكل طلبات السحب 'out'.
طلب السحب 'out' يتم معالجته على مستوى التنفيذ، حيث يستلم الرهنة ETH الخاصة بهم.
على الرغم من أن الإيداع هو عملية يتم تنشيطها في كتلة Eth1، ثم يتم نقلها إلى طبقة العلامات عبر مجموعة "الانتظار" للإيداعات، إلا أن عملية السحب تتبع خطة مختلفة. يتم تنشيطهما في طبقة العلامات (عبر CLI)، ثم يتم نقلهما إلى كتلة Eth1. الآن، سيتم تشغيل الخطتان من خلال إطار عمل عام (كما هو موضح أدناه): إنشاء طلب في طبقة Eth1، معالجة مجموعة "الانتظار" للإيداعات/السحوبات/دمجها، ومعالجتها في طبقة العلامات. بالنسبة للعمليات مثل السحب، يتم معالجة مجموعة الإخراج أيضًا، وسيتم تسوية النتيجة في كتلة Eth1.
من خلال EIP هذا، يمكن للمقامرين استخدام معاملات ETH العادية لسحب وسحب محققيهم دون الحاجة مباشرة إلى تفاعل مع واجهة سطر الأوامر الخاصة بالمحقق أو الوصول إلى البنية التحتية للمحقق. يبسط هذا بشكل كبير عملية المراهنة، خاصة بالنسبة لمقدمي المراهنات الكبيرة. يمكن الآن عزل البنية التحتية للمحققين تقريبًا بالكامل، لأنه يتعين فقط الاهتمام بمفاتيح المحققين النشطة، بينما يمكن معالجة جميع عمليات المراهنة في مكان آخر. يقضي على حاجة المراهنين المستقلين إلى انتظار إجراءات المحققين النشطين، ويبسط بشكل كبير الجزء الخارجي لخدمة Lido مثل وحدة المراهنة المجتمعية.
لذلك ، أكملت عملية الرهن هذه EIP ، ونقلتها بالكامل إلى طبقة Eth1 ، مما يقلل بشكل كبير من مخاطر أمان البنية التحتية ويعزز لامركزية المبادرة المستقلة للرهن.
EIP-6110: إيداع محقق الإمداد على السلسلة
الرجاء الاطلاع على: EIP-6110
حالياً، يتم تنفيذ الودائع من خلال حدث "Deposit()" الصادر عن عقد الوديعة في النظام (كما هو مفصل في المقالات السابقة). يقبل العقد ETH وإثباتات المحقق ويصدر حدث "Deposit()"، ثم يتم تحليل هذه الأحداث وتحويلها إلى طلبات ودائع على طبقة العلامات. هذا النظام به العديد من العيوب: يتطلب التصويت على eth1data في طبقة العلامات، مما يزيد من التأخير بشكل كبير. بالإضافة إلى ذلك، تحتاج طبقة العلامات إلى الاستعلام عن طبقة التنفيذ، مما يزيد من التعقيد. تمت مناقشة هذه المشاكل بتفصيل في EIP. طريقة أبسط بكثير ولا تتطلب التعامل مع العديد من هذه المشاكل هي تضمين طلبات الوديعة مباشرة في كتل Eth1 في المواقع المحددة. يشبه هذا الآلية عملية التعامل مع السحب الموصوفة في EIP السابقة.
التغييرات المقترحة في هذا EIP واعدة للغاية. يمكن الآن إزالة معالجة eth1data بالكامل، ولم يعد هناك حاجة للتصويت أو التأخير لفترة طويلة بين الأحداث في Eth1 والودائع المضمنة على طبقة العلم. كما تمت إزالة منطق لقطات عقود الوديعة. يبسط هذا EIP معالجة الودائع ويجعلها متوافقة مع مخططات السحب المذكورة أعلاه.
بالنسبة للمراهنين والمحققين ، فإن هذه التغييرات تقلل بشكل كبير من التأخير بين الودائع وتفعيل المحققين. عند تقليص المحققين ، سيكون التعويض اللازم أسرع أيضًا.
لا يوجد ما يجب قوله أكثر عن هذا EIP، إلا أنه قام بإزالة البيانات القديمة وتبسيط العملية وخلق نتائج أفضل لجميع الأطراف ذات الصلة.
EIP-7685: طلب طبقة التنفيذ العامة
مرجع: EIP-7685
هذا ال EIP كان من المفترض أن يتم تقديمه قبل الثلاثة الأولى المتعلقة بالإيداع / السحب / الدمج، لأنه وضع الأساس لهذه ال EIP. ومع ذلك، يتم تقديمه هنا لتسليط الضوء على الحاجة المتزايدة لنقل البيانات المخصصة بين سلاسل Eth1 (التنفيذ) والعلامة (التوافق) والبلوكات (الطبقة). يؤثر هذا ال EIP على طبقتين، مما يجعل معالجة الطلبات التي تتم عن طريق معاملات ETH العادية أكثر كفاءة. حاليا، نحن نرى:
يتم "نقل" حدث الإيداع في كتلة Eth1 إلى كتلة الإشارة للمعالجة.
تم نقل طلبات السحب في الكتلة الدليلية (باستخدام واجهة سطر الأوامر) إلى كتل Eth1 للمعالجة.
يجب معالجة دمج المدقق, وهو أيضا طلب منارة ETH1->.
هذه العمليات الثلاث تظهر ضرورة معالجة متسقة لأنواع مختلفة من الطلبات عند التحول بين الطبقة التنفيذية وطبقة العلامات. بالإضافة إلى ذلك، نحتاج إلى القدرة على تنشيط هذه العمليات فقط باستخدام طبقة Eth1، لأن ذلك سيمكننا من عزل البنية التحتية للمحققين عن البنية التحتية لإدارة الرهن، مما يزيد من الأمان. لذا، فإن حل عام لإدارة هذه الطلبات ليس فقط عمليًا ولكنه ضروري أيضًا.
أنشأ هذا EIP إطارًا لما لا يقل عن ثلاث حالات رئيسية: الإيداع والسحب والدمج. هذا هو السبب في أن EIP المبكرة قد قدمت حقولًا مثل WITHDRAWAL_REQUEST_TYPE وDEPOSIT_REQUEST_TYPE، والآن ستضيف الدمج حقلاً آخر CONSOLIDATION_REQUEST_TYPE. بالإضافة إلى ذلك، قد يتضمن هذا EIP أيضًا آلية عامة لتقييد مثل هذه الطلبات (انظر الثوابت: PENDING_DEPOSITS_LIMIT، PENDING_PARTIAL_WITHDRAWALS_LIMIT، PENDING_CONSOLIDATIONS_LIMIT).
على الرغم من أن تفاصيل تنفيذ هذا الإطار لا تزال غير متاحة، إلا أنها بالتأكيد ستتضمن أنواع الطلبات الرئيسية، وآليات الكمال (مثل، طلبات التجزئة والهاش)، ومعالجة قوائم الانتظار وتحديد معدل الإجراءات.
يحمل هذا EIP مغزى معمارياً، مما يتيح لـ Eth1 تنشيط العمليات الرئيسية في طبقة الوسيطية من خلال إطار موحد. بالنسبة للمستخدمين النهائيين والمشاريع، فهذا يعني أن جميع الطلبات التي يتم تنشيطها على طبقة Eth1 سيتم نقلها ومعالجتها بكفاءة أكبر على طبقة الوسيطية.
EIP-2537: تجهيزات BLS12-381 لعمليات المنحنى
مرجع: EIP-2537
إذا كنت لا ترغب في التعمق، فيمكنك اعتبار التجهيز المسبق لـ BLS12-381 عملية تشفيرية معقدة بمثابة "تجزئة"، والتي يمكن الآن استخدامها في العقود الذكية. بالنسبة لأولئك الذين يهتمون، دعونا نناقش أكثر.
يتم استخدام العمليات الرياضية على المنحنيات البيضاوية مثل BLS12-381 (ونظيرتها BN-254) حاليًا لهدفين رئيسيين:
*توقيع BLS، حيث يتم استخدام عملية خاصة تسمى "الزوجية" للتحقق من هذه التوقيعات. يتم استخدام توقيعات BLS على نطاق واسع من قبل المحققين لأنها تجمع بين توقيعات متعددة في واحدة. يعتمد المحققون على توقيعات BLS (على الرغم من أنه يمكن أيضًا استخدام أي منحنى يدعم الزوجية ، مثل BN254) المبنية على منحنى BLS12-381.
التحقق من دليل zkSNARK ، حيث يتم استخدام الزوج للتحقق من الدليل. بالإضافة إلى ذلك ، يتم استخدام الزوج للتحقق من التزام KZG للكتلة الكبيرة التي تم إدخالها بواسطة الشوكة الصلبة Dencun.
إذا كنت ترغب في التحقق من توقيع BLS أو إثبات zkSNARK في العقود الذكية ، فيجب عليك حساب هذه "الأزواج" ، وهذا يكلف كثيرًا من الناحية الحسابية. لدى Ethereum بالفعل عقد مُعدّ مُسبقًا لعمليات BN254 curve (EIP-196 و EIP-197). ومع ذلك ، لم يتم تنفيذ منحنى BLS12-381 (الذي يُعتبر الآن أكثر أمانًا واستخدامًا واسعًا اليوم) كما تم تنفيذه مُسبقًا. بدون وجود مثل هذه العقود المُعدّ مُسبقًا ، يتطلب تنفيذ الأزواج وعمليات المنحنى الأخرى الكثير من الحسابات ، كما هو موضح هنا ، ويستهلك الكثير من الغاز (حوالي ~10^5 إلى 10^6 غاز).
أفتحت هذه المواصفة الفنية الباب أمام العديد من التطبيقات المحتملة، خاصة في التحقق من التوقيعات BLS المتاحة بتكلفة منخفضة بناءً على منحنى BLS12-381. وهذا يتيح إمكانية تنفيذ برامج مشتركة لأغراض متعددة. كما ذكر سابقًا، قام المراقبون في Ethereum بتوقيعات قائمة على BLS12-381. من خلال هذه المواصفة الفنية، يمكن للعقود الذكية القياسية الآن التحقق بكفاءة من توقيعات المراقبين المجتمعة. وهذا يمكن أن يبسط إثبات التوافق وتوصيل الأصول عبر الشبكات، نظرًا لاستخدام التوقيعات BLS على نطاق واسع في سلسلة الكتل. بالإضافة إلى ذلك، يسمح التوقيع الجماعي BLS ببناء العديد من البرامج المشتركة الفعّالة، مثل التصويت وتوفير أرقام عشوائية غير مركزية والتوقيع المشترك وغير ذلك.
فحص أدلة zkSNARK أرخص بدوره يفتح الباب أمام تطبيقات كثيرة. يعاني العديد من الحلول المبنية على zkSNARK حاليًا من تكاليف التحقق العالية من الأدلة، مما يجعل بعض المشاريع تكاد تكون غير عملية. يحتمل أن يغير هذا EIP هذا الوضع.
EIP-2935: حفظ تجزئات الكتلة التاريخية في الولاية
المرجع: EIP-2935
يقترح EIP هذا تخزين ٨١٩٢ تجزئة (حوالي ٢٧.٣ ساعة) من تجزئة الكتل التاريخية في حالة البلوكشين، لتوفير توسعة التاريخ لعملاء بدون حالة (مثل Rollup) والعقود الذكية. يقترح الاحتفاظ بتصرف حالي لرمز BLOCKHASH ، حيث يتم الحفاظ على الحد الأقصى للكتل ٢٥٦ ، بالإضافة إلى إدخال عقد نظام جديد مصمم خصيصًا لتخزين واسترداد تجزئة التاريخ. يُنفذ هذا العقد عملية set() عند معالجة الكتل في طبقة التنفيذ. يمكن لأي شخص الوصول إلى طريقة get() لاسترداد تجزئة الكتل المطلوبة من النطاق الدائري للتخزين المؤقت.
حالياً، يُعتَبَرُ الرجوع إلى تاريخ تجزئة البلوك في EVM ممكناً، ولكن الوصول مقيد بآخر 256 كتلة (حوالي 50 دقيقة). ومع ذلك، في بعض الحالات، يكون الوصول إلى بيانات الكتل الأقدم ضرورياً للغاية، خاصةً بالنسبة لتطبيقات الشبكات الجانبية (التي تحتاج إلى إثبات بيانات الكتل السابقة) وعملاء الحالة الغير مُتقدمة، حيث يحتاجون بشكل منتظم إلى الوصول إلى تجزئة البلوك الأوائل.
يوسّع هذا EIP نطاق الوقت المتاح لـ rollup وتطبيقات الشبكات المتداخلة ، مما يسمح لها بالوصول إلى البيانات التاريخية مباشرةً في EVM دون الحاجة إلى جمعها من خارجها. وبالتالي ، تصبح هذه الحلول أكثر صلابة واستدامة.
EIP-7623: زيادة تكلفة calldata
المرجع: EIP-7623
تعديل تكلفة البيانات يعدل الحجم المتاح للحمولة الفعالة للصفقة، ويمكن أن يكون كبيرًا في بعض الحالات (مثل عند تمرير مصفوفة كبيرة أو مخزن ثنائي كمعامل). تستخدم بشكل رئيسي بيانات الصفقة للتخزين المتداخل، حيث يتم إرسال الحمولة الفعالة من خلال بيانات الصفقة التي تحتوي على حالة التخزين المتداخل الحالية.
يعد جلب بيانات ثنائية كبيرة يمكن إثباتها إلى blockchain أمرا بالغ الأهمية لعمليات التراكم. تقدم ترقية Dencun (Deneb-Cancun) ابتكارا مهما لحالات الاستخدام هذه - معاملات blob (EIP-4844). معاملات Blob لها رسوم غاز "blob" مخصصة لها ، وبينما يتم تخزين أجسامها مؤقتا ، يتم دمج براهين التشفير الخاصة بها (التزام KZG) في طبقة الإجماع جنبا إلى جنب مع تجزئتها. نتيجة لذلك ، توفر النقط حلا أفضل للمجموعات من استخدام calldata لتخزين البيانات.
يمكن تحفيز rollup على نقل بياناته إلى blob من خلال "جزر الجزر". تُعتبر تكلفة الغاز الأقل لل blob كـ "الجزر"، بينما يعمل هذا EIP على زيادة تكلفة calldata كـ "العتلة"، مما يعيق تخزين البيانات الزائد في المعاملات. يكمل هذا EIP EIP-7691 التالي (زيادة إنتاجية Blob)، الذي يزيد من الحد الأقصى لكل كتلة blob.
EIP-7691: زيادة في سعة امتصاص الكتل
الرجاء الرجوع إلى: EIP-7691
في الشوكة الصلبة السابقة لـ Dencun ، تم إدخال البلوب ، وكانت القيمة الأولية للحد الأقصى والهدف لكل بلوب في كل كتلة تقديرًا محافظًا. يعود ذلك إلى تعقيد كيفية تعامل الشبكة نقطة إلى نقطة مع كائنات ثنائية كبيرة تنتشر بين العقد الموثقة. قد ثبتت التكوينات السابقة أنها جيدة ، مما يجعل هذا الوقت مناسبًا لاختبار القيم الجديدة. في السابق ، تم تعيين الحد الأقصى / الهدف لعدد البلوب في كل كتلة على 3/6. تم رفع هذه القيود حاليًا إلى 6/9 على التوالي.
بالاقتران مع EIP-7623 السابقة (زيادة تكلفة البيانات المتغيرة) ، تعزز هذه التعديلات نقل بيانات rollup من calldata إلى blobs. لا يزال العمل جاريًا في البحث عن أفضل معلمة لـ blob.
EIP-7840: إضافة جدولة blob إلى ملف تكوين EL
الرجاء الرجوع إلى: EIP-7840
تقترح هذه الـEIP إضافة الهدف والحد الأقصى لعدد الـblob لكل كتلة (التي تمت مناقشتها سابقًا) وقيمة baseFeeUpdateFraction إلى ملف تكوين طبقة التنفيذ في إثريوم (EL). كما يتيح للعميل استرداد هذه القيم عن طريق واجهة برمجة تطبيق العقد. تعتبر هذه الوظيفة مفيدة بشكل خاص لتقدير تكلفة غاز الـblob ومهام مماثلة.
EIP-7702: تعيين كود حساب EOA
مرجع: EIP-7702
هذا هو EIP مهم جدا من شأنه أن يجلب تغييرات كبيرة لمستخدمي Ethereum. كما نعلم ، لا يمكن أن تحتوي EOA (الحسابات المملوكة خارجيا) على أي رمز ، ولكن يمكنها توفير توقيعات المعاملات (tx.origin). في المقابل ، يحتوي العقد الذكي على رمز ثانوي ، ولكن لا يمكنه اقتراح توقيع مباشر ل "it". يمكن لأي تفاعل مستخدم يتطلب منطقا إضافيا وآليا ويمكن التحقق منه حاليا تنفيذ الإجراء المطلوب فقط عن طريق استدعاء عقد خارجي. ومع ذلك ، في هذه الحالة ، يصبح العقد الخارجي هو msg.sender للعقد اللاحق ، مما يجعل المكالمة "من العقد ، وليس المستخدم".
يقدم برنامج EIP هذا نوع معاملة SET_CODE_TX_TYPE=0x04 (كان لدينا معاملة 0x1 القديمة من قبل ، ومعاملة 0x02 الجديدة من برلين وترقية EIP-1559 ، ومعاملة النقطة 0x03 التي تم تقديمها في Dencun). يتيح لك هذا النوع الجديد من التجارة إعداد رموز لحسابات EOA. في الواقع ، يسمح ل EOA بتنفيذ رمز خارجي "في سياق حساب EOA الخاص بها". من منظور خارجي ، يبدو أن EOA "تستعير" رمزا من عقد خارجي وتنفذه أثناء المعاملة. من الناحية الفنية ، يتم ذلك عن طريق إضافة مجموعة من بيانات التفويض الخاصة إلى مخزن "الرمز" لعنوان EOA (حتى EIP هذا ، كان مخزن "الرمز" هذا فارغا دائما إلى EOA).
حاليًا ، يتضمن نوع المعاملة 0x04 الجديد المقترح في EIP مصفوفة:
authorization_list = [[chain_id، العنوان، الرقم التسلسلي، y_parity، r، s]، ...]
يُسمح لكل عنصر باستخدام الحساب برمجية من العنوان المُحدد (من آخر عنصر ترخيص صالح). عند معالجة مثل هذه المعاملات، سيتم تعيين برمجية EOA المعطاة إلى قيمة عنوان خاصة 0xef0100 || (23 بايت)، حيث يشير العنوان إلى عقد يحتوي على البرمجية المطلوبة، || تشير إلى الاتصال، و 0xef0100 يشير إلى قيمة سحرية خاصة للعقود الذكية العامة التي لا يمكن أن تحتوي عليها. هذه القيمة السحرية تضمن أن هذا EOA لا يمكن اعتباره عقدًا عامًا، ولا يمكن استدعاؤه مثل العقود العامة.
عندما يتم إطلاق هذا الـ EOA للتداول، سيتم استخدام العنوان المحدد لاستدعاء الشيفرة المقابلة في سياق هذا الـ EOA. على الرغم من أن تفاصيل تنفيذ هذا الـ EIP لا تزال غير واضحة، يمكن التأكيد على أنه سيحمل تغييرات هامة.
أحد التأثيرات الرئيسية هو القدرة على القيام بمكالمات متعددة مباشرة من EOA (multicall). تعد المكالمات المتعددة اتجاهًا مستمرًا في DeFi ، حيث يقدم العديد من البروتوكولات هذه الميزة كأداة قوية (مثل Uniswap V4 أو Balancer V3 أو Euler V2). مع هذا EIP ، يمكن الآن القيام بمكالمات متعددة مباشرة من EOA.
على سبيل المثال، يحل هذا الميزة الجديدة مشكلة شائعة في DeFi: تعتبر approve() + anything() غير كفءة وتتطلب معاملتين منفصلتين. يسمح هذا EIP بالمنطق العام لـ 'الترخيص المسبق'، مما يتيح إتمام مثل approve(X) + deposit(X) في صفقة واحدة.
يعتبر القدرة على "تمثيل" تنفيذ الصفقات الموكلة لـ EOA ميزة أخرى هامة هي مفهوم الرعاية. الرعاية هي ميزة يتم مناقشتها بانتظام وتحظى برغبة شديدة لمساعدة المستخدمين الجدد على الانضمام إلى الإيثيريوم.
فتحت البرمجة المتعلقة بـ EOA العديد من الإمكانيات ، مثل فرض قيود أمنية وتعيين حدود الإنفاق والمطالبة بمعرفة العميل ، وما إلى ذلك.
بالطبع ، يثير هذا التحول أيضا عددا من أسئلة التصميم. تتمثل إحدى المشكلات في استخدام chain_id ، والذي يحدد ما إذا كان التوقيع نفسه يمكن أن يكون صالحا عبر شبكات متعددة ، اعتمادا على ما إذا كان مضمنا أم لا في التوقيع. تعقيد آخر هو الاختيار بين استخدام عنوان رمز الكائن وتضمين الرمز الثانوي الفعلي. كلتا الطريقتين لها ميزاتها وقيودها الفريدة. بالإضافة إلى ذلك ، يلعب استخدام nonce دورا رئيسيا في تحديد ما إذا كان الإذن "متعدد الأغراض" أو "أحادي الغرض". تؤثر هذه العناصر على مشكلات الوظائف والأمان ، بما في ذلك جوانب مثل توقيعات الإبطال المجمع وسهولة الاستخدام. أثار فيتاليك هذه الأسئلة في مناقشة (هنا) تستحق المزيد من الاستكشاف.
يجب ملاحظة أن هذا التغيير سيؤثر على آلية أمان في Ethereum ، tx.origin. المزيد من التفاصيل حول تطبيق EIP هذا ضروري ، ولكن يبدو أن سيتم تغيير السلوك require(tx.origin == msg.sender). كان هذا الفحص دائمًا وسيلة موثوقة للتأكد من أن msg.sender هو EOA بدلاً من عقد. الطرق الأخرى ، مثل فحص EXTCODESIZE (للتحقق مما إذا كان عقدًا) ، عادة ما تفشل ويمكن تجاوزها (على سبيل المثال ، من خلال استدعاء دالة البناء أو نشر الكود في عنوان محدد مسبقًا بعد الصفقة). يتم استخدام هذه الفحوصات لمنع الهجمات المتكررة والقروض البرقية ، ولكن بعيدة عن كونها مثالية لأنها تعوق أيضًا تكامل البروتوكولات الخارجية. بعد هذا EIP ، يبدو أن حتى الفحص الموثوق requiretx.origin == msg.sender أصبح قديمًا. يجب على البروتوكولات التكيف من خلال إزالة هذه الفحوصات ، لأن الفارق بين "EOA" و "عقد" لن يكون ساري المفعول بعد الآن - الآن كل عنوان قد يحتوي على كود ذي صلة.
استمرار اختلاط الفصل بين EOA التقليدية والعقود الذكية. يجعل هذا EIP Ethereum أقرب إلى تصميم مثل TON حيث كل حساب في الأساس هو رمز قابل للتنفيذ. مع تعقيد التفاعل مع البروتوكول، فإن استخدام البرمجة اللوجيستية لتحسين تجربة المستخدم النهائي هو عملية تطور طبيعية.
الاستنتاج
ترقية براغ / إلكترا (بكترا) مقررة في مارس 2025. أبرز التغييرات المخططة تشمل:
يمكن الاعتماد على المراهنة القابلة للتغيير للمحققين ، حيث يمكن أن تصل الحد الأقصى إلى 2048 ETH ، مما يؤدي إلى تغيير كبير في توزيع المراهنة وجدول زمني للمحققين ، وتبسيط إدارة مقدمي المراهنة الكبيرة عن طريق دمج المراهنة الصغيرة
تحسين تفاعل طبقة التنفيذ مع طبقة الاتفاقية ، وتبسيط تبادل البيانات بين كتل تنفيذ Eth1 وكتل سلسلة العلامات. هذا سيبسط بشكل كبير عمليات الإيداع والتنشيط والسحب والانسحاب ، ويعزز هذه العمليات ويعزز التفاعل بين طبقة الاتفاقية وطبقة التنفيذ
دعم التوقيع BLS الأرخص والتحقق من zkSNARK مباشرة من خلال الترجمة المسبقة الجديدة "الصديقة للزوج" BLS12-381 في العقود الذكية
تشجيع Rollups على زيادة عتبة صفقات البلوب وزيادة تكلفة calldata في اعتماد صفقات البلوب
جعل EOA يعمل كحساب قابل للبرمجة، مما يمنحه القدرة على الاستدعاء المتعدد والرعاية وغيرها من الوظائف المتقدمة
كما ترون، ستؤثر Pectra بشكل كبير على تجربة المستخدم النهائية للرهن والطبقة القائمة على الاتفاق، وطبقة التنفيذ. على الرغم من أننا لا نستطيع في هذه المرحلة تحليل جميع هذه التغييرات بالتفصيل من خلال الشفرة لأن التطوير ما زال قائماً، إلا أننا سنغطي هذه التحديثات في المقالات المستقبلية.
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
تحليل إثيريوم坊 الهارد فورك القادم - ترقية Pectra
مقدمة
في مقالاتنا السابقة ، قمنا بمراجعة مفصلة لدورة حياة محققي إثريوم وناقشنا العديد من الجوانب المتعلقة بالتحويل الصلب Electra القادم. الآن حان الوقت للتركيز على التغييرات في التحديثات المقبلة Electra و Prague وشرحها بالتفصيل.
تاريخ الشوكة الصلبة لـ Ethereum 2.0 Proof of Stake معقد. بدأت بإضافة طبقة البيانات إلى الطبقة التنفيذية الحالية ، حيث تم تشغيل الوضع Proof of Stake على طبقة البيانات ، في حين أن الطبقة التنفيذية لا تزال تعمل بنمط Proof of Work (Phase0 و Altair Hard Fork). ثم تم تنشيط PoS بالكامل في الشوكة الصلبة Bellatrix (على الرغم من عدم تمكين السحب). ثم سمحت الشوكة الصلبة Capella بالسحب ، واكتملت حياة المحققين. أجريت تعديلات طفيفة على معلمات سلسلة البيانات في الشوكة الصلبة الأخيرة Deneb (جزء من ترقية Dencun (Deneb/Cancun)) ، مثل نافذة الوقت للإثبات ومعالجة الانسحاب الطوعي وقيود تغيير المحقق. تغيرات رئيسية في Dencun حدثت في الطبقة التنفيذية ، حيث تم إطلاق معاملات Blob وغاز Blob والتزامات KZG لـ Blob ، وتم التخلي عن عملية SELFDESTRUCT.
الآن ، يقوم تحديث فرعي صلب لـ Prague/Electra (المعروف أيضًا باسم Pectra) بإدخال تحسينات مهمة على مستوى التنفيذ والتوافق. بصفتنا مدققي مشروع Lido ، نركز بشكل رئيسي على التغييرات ذات الصلة بالتوافق والرهن الواردة في هذا التحديث الصلب. ومع ذلك ، لا يمكننا تجاهل التغييرات الواردة على مستوى التنفيذ في Prague ، لأنها تشمل سمات هامة تؤثر على شبكة Ethereum والمحققين. دعونا نستكشف تفاصيل هذه التغييرات.
نظرة عامة أعلى لـ Pectra
Electra قدمت العديد من المزايا لطبقة العلامات التجارية. وتشمل التحديثات الرئيسية:
في الوقت نفسه، قام براغ بإدخال التغييرات التالية على المستوى التنفيذي:
دعونا نشير إلى الاقتراحات الخاصة بتحسين إيثيريوم (EIP) ذات الصلة لمناقشتها بشكل أعمق:
هذه الأوراق المالية البديلة تتعلق بشكل رئيسي بطبقة الاتفاق (العلامة)، بينما البعض الآخر يتعلق بطبقة التنفيذ. بعضها يتجاوز الطبقتين، لأن بعض العمليات (مثل الودائع والسحب) تتطلب تغييرات متزامنة بين طبقة الاتفاق وطبقة التنفيذ. نظرًا لهذا التبادل التبادلي، فإن فصل Electra و Prague ليس واقعيًا، لذلك سنستعرض كل EIP بالترتيب ونحدد المكونات في إيثريوم التي تتأثر في كل حالة.
EIP-7251: زيادة الحد الأقصى \ _EFFECTIVE \ _BALANCE
المرجع: EIP-7251
منذ أول عملية انقسام Phase0 ، استعدادا لإثبات حصة Ethereum ، تم تحديد الحد الأقصى للرصيد الفعال للمدققين عند 32 ETH حتى Electra. متطلبات مدقق التنشيط هي على الأقل spec.min_activation_balance (32 ETH). بمجرد التنشيط ، يبدأ المدققون بهذا الحد الأقصى للرصيد الفعال ، ولكن يمكنهم تقليل رصيدهم الفعال إلى spec.ejection \ _balance (16 ETH) ويتم طردهم عند الوصول إلى هذا الحد. يظل هذا المنطق "الأدنى" كما هو في إلكترا ، ولكن الآن زاد spec.max_effective_balance إلى 2048 ETH. نتيجة لذلك ، يمكن للمدققين إيداع ما بين 32 و 2048 ETH للتنشيط ، وكل ذلك سيساهم في رصيدهم الفعال. يمثل هذا التحول تحولا من "32ETH - إثبات الحصة" إلى "إثبات الحصة": )
سيتم استخدام الرصيد الصالح المتغير حاليًا ل:
الأنشطة الأولى هي العمليات الأكثر عائدًا للمحققين. لذا بعد Electra، ستشارك المحققون ذوو الرهن الكبير بشكل أكثر تواترًا في اقتراح الكتل واللجنة المتزامنة، وتتناسب ترددهم مع الرصيد الفعال الخاص بهم.
آخر تأثير متعلق بالتقليص. جميع العقوبات على التقليص تتناسب مع رصيد المحقق الفعال:
قدمت إليكترا أيضًا تغييرًا في نسبة الاقتطاع ، حيث تعرف جزءًا من رصيد المحقق المقتطع ويتلقاه المبلغ.
الخطوة التالية هي تأثير البطالة. عندما يكون المحقق غير متصل (برهان أو اقتراح) عندما يكون نشطًا، يتم تراكم درجة البطالة، مما يؤدي إلى فرض عقوبات على البطالة في كل دورة. هذه العقوبات مرتبطة أيضًا برصيد المحقق الصالح بنسبة مئوية.
نظرًا لزيادة الرصيد الفعال، فإن 'قيود الاستبدال' للمحققين تغيرت أيضًا. في 'إثيريوم قبل Electra'، غالبًا ما يكون لدى المحققين رصيد فعال مماثل، وتعريف قيود الاستبدال للخروج هو 'في دورة واحدة، يمكن لأكثر من 1/65536 (spec.churn_limit_quotient) من الرهن الإجمالي أن يخرج.' هذا خلق 'ثابت' يخرج كمية محددة من المحققين بنفس الرهن. ومع ذلك، بعد 'Electra'، قد يحدث خروج لعدد قليل فقط من 'الحيتان'، لأنها تمثل جزءًا هامًا من الرهن الإجمالي.
واحدة من النظر فيها هي تناوب مفاتيح التحقق العديدة على نسخة واحدة من مفتاح التحقق. حاليًا، يتم إجبار المفتشين الكبار على تشغيل آلاف مفاتيح التحقق على نسخة واحدة لتتكيف مع الرهن الكبير وتقسيمه إلى أجزاء بقيمة 32 إثريوم. مع Electra، لم يعد هذا السلوك إلزاميًا. من الناحية المالية، لا يؤثر هذا التغيير كثيرًا، نظرًا لأن المكافأة والاحتمالية تتناسب بشكل خطي مع مبلغ الرهن. وبالتالي، يعادل 100 مفتش بقيمة 32 إثريوم كاملة مفتشًا واحدًا بقيمة 3200 إثريوم. بالإضافة إلى ذلك، يمكن أن يكون لدى عدة مفاتيح تحقق نشطة مستند Eth1 مماثل، مما يسمح بسحب جميع المكافآت إلى عنوان إثريوم واحد، وبالتالي تجنب تكاليف الغاز المرتبطة بدمج المكافآت. ومع ذلك، فإن إدارة عدد كبير من المفاتيح ستؤدي إلى تكاليف إدارية إضافية.
زادت قدرة تجميع رصيد المحققين على نوع جديد من طلب التنفيذ. في الماضي، كان لدينا الإيداع والسحب. الآن، سيكون هناك نوع آخر: طلب التجميع. سيجمع بين محققين اثنين في واحد. سيتضمن طلب العملية المفتاح العام للمحقق المصدر والمفتاح العام المستهدف، وسيتم معالجته على غرار الإيداع والسحب. سيكون للتجميع أيضًا طلبات قيد المعالجة وقيود تغيير الرصيد، تمامًا مثل الإيداع والسحب.
يتم تلخيصها على النحو التالي:
موضوع آخر مهم هو بيانات المحققين التاريخية وتقدير الأرباح ، وهو ذو صلة خاصة بالمشاركين الجدد الذين يحاولون تقييم المخاطر والعوائد. قبل Electra (حتى كتابة هذا المقال) ، قام الحد الأعلى لـ 32 ETH (سواء كانت الحد الأدنى أو الأقصى فعليًا) بإنشاء تكافؤ في البيانات التاريخية. رصيد المحققين الفعال ، والمكافآت ، والعقوبات الفردية للتقليل ، ومعدل اقتراح الكتل ، ومؤشرات أخرى ، كلها متماثلة. هذا التكافؤ يتيح لـ Ethereum اختبار آلية الاتفاق الخاصة بها بدون قيم استثنائية إحصائية ، مما يسمح بجمع بيانات سلوك الشبكة ذات القيمة.
بعد إلكترا، ستحدث تغييرات كبيرة في توزيع الإيداعات. سيكون مشاركة المحققين الكبار في اقتراح الكتل واللجنة المتزامنة أكثر تكرارًا، وسيواجهون عقوبات أكبر في حالات التقليص، كما ستكون لها تأثير أكبر على تأخير التقليص وقائمة الانتظار وقائمة الخروج. وعلى الرغم من أن هذا قد يشكل تحديًا في تجميع البيانات، إلا أن توافق إثيريوم يضمن أن الحساب غير الخطي هو الحد الأدنى. يستخدم المكون الوحيد غير الخطي sqrt(total_effective_balance) لحساب الأجر الأساسي، وهذا ينطبق على جميع المحققين. وهذا يعني أن أجور المحققين والتقليص ما زال يمكن تقديرها بناءً على "كل 1 إيثر" (أو بدقة أكبر، وفقًا لـ spec.effective_balance_increment، والتي قد تتغير في المستقبل).
لمزيد من المعلومات التفصيلية، يرجى الاطلاع على مقالنا السابق حول سلوك المحققين.
EIP-7002：الخروج القابل للتنفيذ من طبقة الخروج
مرجع: EIP-7002
كل مُوثَّق في Ethereum لديه زوجان من المفاتيح: مفتاح نشط ومفتاح سحب. يُستخدم المفتاح العام BLS النشط كهوية رئيسية للمُوثَّق في سلسلة الإشارات، حيث يُستخدم هذا الزوج من المفاتيح لتوقيع الكتل والإثبات والتقليص وتجميع اللجان المتزامنة، وكذلك (قبل هذا EIP) الخروج الطوعي (للموافقة على خروج موثق الإجماع بعد تأخير). الزوج الثاني من المفاتيح ("إثبات السحب") يمكن أن يكون آخر زوج من مفاتيح BLS أو حساب Eth1 العادي (مفتاح خاص وعنوان). الآن، يتطلب استخراج عنوان ETH توقيع رسالة السحب بواسطة المفتاح الخاص BLS النشط. قامت هذه EIP بتغيير ذلك.
في الواقع ، يمكن أن يكون مالكو هذين الزوجين من المفاتيح (النشطة والسحب) مختلفين. المفتاح النشط للمدقق مسؤول عن واجبات التحقق: تشغيل الخادم ، والحفاظ عليه وتشغيله ، وما إلى ذلك ، بينما يتم التحكم في بيانات اعتماد السحب عادة من قبل مالك الحصة ، الذي يتلقى المكافآت ويكون مسؤولا عن الأموال. في الوقت الحالي، لا يمكن إلا لمالك الحصة الذي يتحكم في بيانات اعتماد السحب بدء سحب المدقق ويمكنه فقط سحب المكافأة. يسمح هذا الموقف لمالك المفتاح النشط للمدقق بالاحتفاظ برصيد المدقق بشكل فعال باعتباره "رهينة". يمكن للمدققين "التوقيع المسبق" على رسالة الخروج وتسليمها إلى مالك الحصة ، لكن هذا الحل البديل ليس مثاليا. بالإضافة إلى ذلك, يتطلب كل من الاستخراج والسحب حاليا التفاعل مع مدققي طبقة المنارة من خلال واجهة برمجة تطبيقات مخصصة.
أفضل حل هو السماح لمالك الرهن بتنفيذ عمليات الإلغاء والسحب بنفس الوقت من خلال استدعاء العقد الذكي العادي. ينطوي ذلك على فحص توقيع Eth1 القياسي ، مما يبسط العملية بشكل كبير.
يتيح هذا EIP لأصحاب الرهن الإفراج عن الأموال وسحبها عن طريق إرسال المعاملات القياسية من عناوين ETH الخاصة بهم إلى عقد ذكي خاص لتنفيذ السحب والإفراج (مشابه لعملية الإيداع باستخدام العقد الحالي للإيداع). عملية السحب (أو الإفراج التي يتم تنفيذها عندما يكون هناك ما يكفي من الرهن) تتم على النحو التالي:
على الرغم من أن الإيداع هو عملية يتم تنشيطها في كتلة Eth1، ثم يتم نقلها إلى طبقة العلامات عبر مجموعة "الانتظار" للإيداعات، إلا أن عملية السحب تتبع خطة مختلفة. يتم تنشيطهما في طبقة العلامات (عبر CLI)، ثم يتم نقلهما إلى كتلة Eth1. الآن، سيتم تشغيل الخطتان من خلال إطار عمل عام (كما هو موضح أدناه): إنشاء طلب في طبقة Eth1، معالجة مجموعة "الانتظار" للإيداعات/السحوبات/دمجها، ومعالجتها في طبقة العلامات. بالنسبة للعمليات مثل السحب، يتم معالجة مجموعة الإخراج أيضًا، وسيتم تسوية النتيجة في كتلة Eth1.
من خلال EIP هذا، يمكن للمقامرين استخدام معاملات ETH العادية لسحب وسحب محققيهم دون الحاجة مباشرة إلى تفاعل مع واجهة سطر الأوامر الخاصة بالمحقق أو الوصول إلى البنية التحتية للمحقق. يبسط هذا بشكل كبير عملية المراهنة، خاصة بالنسبة لمقدمي المراهنات الكبيرة. يمكن الآن عزل البنية التحتية للمحققين تقريبًا بالكامل، لأنه يتعين فقط الاهتمام بمفاتيح المحققين النشطة، بينما يمكن معالجة جميع عمليات المراهنة في مكان آخر. يقضي على حاجة المراهنين المستقلين إلى انتظار إجراءات المحققين النشطين، ويبسط بشكل كبير الجزء الخارجي لخدمة Lido مثل وحدة المراهنة المجتمعية.
لذلك ، أكملت عملية الرهن هذه EIP ، ونقلتها بالكامل إلى طبقة Eth1 ، مما يقلل بشكل كبير من مخاطر أمان البنية التحتية ويعزز لامركزية المبادرة المستقلة للرهن.
EIP-6110: إيداع محقق الإمداد على السلسلة
الرجاء الاطلاع على: EIP-6110
حالياً، يتم تنفيذ الودائع من خلال حدث "Deposit()" الصادر عن عقد الوديعة في النظام (كما هو مفصل في المقالات السابقة). يقبل العقد ETH وإثباتات المحقق ويصدر حدث "Deposit()"، ثم يتم تحليل هذه الأحداث وتحويلها إلى طلبات ودائع على طبقة العلامات. هذا النظام به العديد من العيوب: يتطلب التصويت على eth1data في طبقة العلامات، مما يزيد من التأخير بشكل كبير. بالإضافة إلى ذلك، تحتاج طبقة العلامات إلى الاستعلام عن طبقة التنفيذ، مما يزيد من التعقيد. تمت مناقشة هذه المشاكل بتفصيل في EIP. طريقة أبسط بكثير ولا تتطلب التعامل مع العديد من هذه المشاكل هي تضمين طلبات الوديعة مباشرة في كتل Eth1 في المواقع المحددة. يشبه هذا الآلية عملية التعامل مع السحب الموصوفة في EIP السابقة.
التغييرات المقترحة في هذا EIP واعدة للغاية. يمكن الآن إزالة معالجة eth1data بالكامل، ولم يعد هناك حاجة للتصويت أو التأخير لفترة طويلة بين الأحداث في Eth1 والودائع المضمنة على طبقة العلم. كما تمت إزالة منطق لقطات عقود الوديعة. يبسط هذا EIP معالجة الودائع ويجعلها متوافقة مع مخططات السحب المذكورة أعلاه.
بالنسبة للمراهنين والمحققين ، فإن هذه التغييرات تقلل بشكل كبير من التأخير بين الودائع وتفعيل المحققين. عند تقليص المحققين ، سيكون التعويض اللازم أسرع أيضًا.
لا يوجد ما يجب قوله أكثر عن هذا EIP، إلا أنه قام بإزالة البيانات القديمة وتبسيط العملية وخلق نتائج أفضل لجميع الأطراف ذات الصلة.
EIP-7685: طلب طبقة التنفيذ العامة
مرجع: EIP-7685
هذا ال EIP كان من المفترض أن يتم تقديمه قبل الثلاثة الأولى المتعلقة بالإيداع / السحب / الدمج، لأنه وضع الأساس لهذه ال EIP. ومع ذلك، يتم تقديمه هنا لتسليط الضوء على الحاجة المتزايدة لنقل البيانات المخصصة بين سلاسل Eth1 (التنفيذ) والعلامة (التوافق) والبلوكات (الطبقة). يؤثر هذا ال EIP على طبقتين، مما يجعل معالجة الطلبات التي تتم عن طريق معاملات ETH العادية أكثر كفاءة. حاليا، نحن نرى:
هذه العمليات الثلاث تظهر ضرورة معالجة متسقة لأنواع مختلفة من الطلبات عند التحول بين الطبقة التنفيذية وطبقة العلامات. بالإضافة إلى ذلك، نحتاج إلى القدرة على تنشيط هذه العمليات فقط باستخدام طبقة Eth1، لأن ذلك سيمكننا من عزل البنية التحتية للمحققين عن البنية التحتية لإدارة الرهن، مما يزيد من الأمان. لذا، فإن حل عام لإدارة هذه الطلبات ليس فقط عمليًا ولكنه ضروري أيضًا.
أنشأ هذا EIP إطارًا لما لا يقل عن ثلاث حالات رئيسية: الإيداع والسحب والدمج. هذا هو السبب في أن EIP المبكرة قد قدمت حقولًا مثل WITHDRAWAL_REQUEST_TYPE وDEPOSIT_REQUEST_TYPE، والآن ستضيف الدمج حقلاً آخر CONSOLIDATION_REQUEST_TYPE. بالإضافة إلى ذلك، قد يتضمن هذا EIP أيضًا آلية عامة لتقييد مثل هذه الطلبات (انظر الثوابت: PENDING_DEPOSITS_LIMIT، PENDING_PARTIAL_WITHDRAWALS_LIMIT، PENDING_CONSOLIDATIONS_LIMIT).
على الرغم من أن تفاصيل تنفيذ هذا الإطار لا تزال غير متاحة، إلا أنها بالتأكيد ستتضمن أنواع الطلبات الرئيسية، وآليات الكمال (مثل، طلبات التجزئة والهاش)، ومعالجة قوائم الانتظار وتحديد معدل الإجراءات.
يحمل هذا EIP مغزى معمارياً، مما يتيح لـ Eth1 تنشيط العمليات الرئيسية في طبقة الوسيطية من خلال إطار موحد. بالنسبة للمستخدمين النهائيين والمشاريع، فهذا يعني أن جميع الطلبات التي يتم تنشيطها على طبقة Eth1 سيتم نقلها ومعالجتها بكفاءة أكبر على طبقة الوسيطية.
EIP-2537: تجهيزات BLS12-381 لعمليات المنحنى
مرجع: EIP-2537
إذا كنت لا ترغب في التعمق، فيمكنك اعتبار التجهيز المسبق لـ BLS12-381 عملية تشفيرية معقدة بمثابة "تجزئة"، والتي يمكن الآن استخدامها في العقود الذكية. بالنسبة لأولئك الذين يهتمون، دعونا نناقش أكثر.
يتم استخدام العمليات الرياضية على المنحنيات البيضاوية مثل BLS12-381 (ونظيرتها BN-254) حاليًا لهدفين رئيسيين:
*توقيع BLS، حيث يتم استخدام عملية خاصة تسمى "الزوجية" للتحقق من هذه التوقيعات. يتم استخدام توقيعات BLS على نطاق واسع من قبل المحققين لأنها تجمع بين توقيعات متعددة في واحدة. يعتمد المحققون على توقيعات BLS (على الرغم من أنه يمكن أيضًا استخدام أي منحنى يدعم الزوجية ، مثل BN254) المبنية على منحنى BLS12-381.
إذا كنت ترغب في التحقق من توقيع BLS أو إثبات zkSNARK في العقود الذكية ، فيجب عليك حساب هذه "الأزواج" ، وهذا يكلف كثيرًا من الناحية الحسابية. لدى Ethereum بالفعل عقد مُعدّ مُسبقًا لعمليات BN254 curve (EIP-196 و EIP-197). ومع ذلك ، لم يتم تنفيذ منحنى BLS12-381 (الذي يُعتبر الآن أكثر أمانًا واستخدامًا واسعًا اليوم) كما تم تنفيذه مُسبقًا. بدون وجود مثل هذه العقود المُعدّ مُسبقًا ، يتطلب تنفيذ الأزواج وعمليات المنحنى الأخرى الكثير من الحسابات ، كما هو موضح هنا ، ويستهلك الكثير من الغاز (حوالي ~10^5 إلى 10^6 غاز).
أفتحت هذه المواصفة الفنية الباب أمام العديد من التطبيقات المحتملة، خاصة في التحقق من التوقيعات BLS المتاحة بتكلفة منخفضة بناءً على منحنى BLS12-381. وهذا يتيح إمكانية تنفيذ برامج مشتركة لأغراض متعددة. كما ذكر سابقًا، قام المراقبون في Ethereum بتوقيعات قائمة على BLS12-381. من خلال هذه المواصفة الفنية، يمكن للعقود الذكية القياسية الآن التحقق بكفاءة من توقيعات المراقبين المجتمعة. وهذا يمكن أن يبسط إثبات التوافق وتوصيل الأصول عبر الشبكات، نظرًا لاستخدام التوقيعات BLS على نطاق واسع في سلسلة الكتل. بالإضافة إلى ذلك، يسمح التوقيع الجماعي BLS ببناء العديد من البرامج المشتركة الفعّالة، مثل التصويت وتوفير أرقام عشوائية غير مركزية والتوقيع المشترك وغير ذلك.
فحص أدلة zkSNARK أرخص بدوره يفتح الباب أمام تطبيقات كثيرة. يعاني العديد من الحلول المبنية على zkSNARK حاليًا من تكاليف التحقق العالية من الأدلة، مما يجعل بعض المشاريع تكاد تكون غير عملية. يحتمل أن يغير هذا EIP هذا الوضع.
EIP-2935: حفظ تجزئات الكتلة التاريخية في الولاية
المرجع: EIP-2935
يقترح EIP هذا تخزين ٨١٩٢ تجزئة (حوالي ٢٧.٣ ساعة) من تجزئة الكتل التاريخية في حالة البلوكشين، لتوفير توسعة التاريخ لعملاء بدون حالة (مثل Rollup) والعقود الذكية. يقترح الاحتفاظ بتصرف حالي لرمز BLOCKHASH ، حيث يتم الحفاظ على الحد الأقصى للكتل ٢٥٦ ، بالإضافة إلى إدخال عقد نظام جديد مصمم خصيصًا لتخزين واسترداد تجزئة التاريخ. يُنفذ هذا العقد عملية set() عند معالجة الكتل في طبقة التنفيذ. يمكن لأي شخص الوصول إلى طريقة get() لاسترداد تجزئة الكتل المطلوبة من النطاق الدائري للتخزين المؤقت.
حالياً، يُعتَبَرُ الرجوع إلى تاريخ تجزئة البلوك في EVM ممكناً، ولكن الوصول مقيد بآخر 256 كتلة (حوالي 50 دقيقة). ومع ذلك، في بعض الحالات، يكون الوصول إلى بيانات الكتل الأقدم ضرورياً للغاية، خاصةً بالنسبة لتطبيقات الشبكات الجانبية (التي تحتاج إلى إثبات بيانات الكتل السابقة) وعملاء الحالة الغير مُتقدمة، حيث يحتاجون بشكل منتظم إلى الوصول إلى تجزئة البلوك الأوائل.
يوسّع هذا EIP نطاق الوقت المتاح لـ rollup وتطبيقات الشبكات المتداخلة ، مما يسمح لها بالوصول إلى البيانات التاريخية مباشرةً في EVM دون الحاجة إلى جمعها من خارجها. وبالتالي ، تصبح هذه الحلول أكثر صلابة واستدامة.
EIP-7623: زيادة تكلفة calldata
المرجع: EIP-7623
تعديل تكلفة البيانات يعدل الحجم المتاح للحمولة الفعالة للصفقة، ويمكن أن يكون كبيرًا في بعض الحالات (مثل عند تمرير مصفوفة كبيرة أو مخزن ثنائي كمعامل). تستخدم بشكل رئيسي بيانات الصفقة للتخزين المتداخل، حيث يتم إرسال الحمولة الفعالة من خلال بيانات الصفقة التي تحتوي على حالة التخزين المتداخل الحالية.
يعد جلب بيانات ثنائية كبيرة يمكن إثباتها إلى blockchain أمرا بالغ الأهمية لعمليات التراكم. تقدم ترقية Dencun (Deneb-Cancun) ابتكارا مهما لحالات الاستخدام هذه - معاملات blob (EIP-4844). معاملات Blob لها رسوم غاز "blob" مخصصة لها ، وبينما يتم تخزين أجسامها مؤقتا ، يتم دمج براهين التشفير الخاصة بها (التزام KZG) في طبقة الإجماع جنبا إلى جنب مع تجزئتها. نتيجة لذلك ، توفر النقط حلا أفضل للمجموعات من استخدام calldata لتخزين البيانات.
يمكن تحفيز rollup على نقل بياناته إلى blob من خلال "جزر الجزر". تُعتبر تكلفة الغاز الأقل لل blob كـ "الجزر"، بينما يعمل هذا EIP على زيادة تكلفة calldata كـ "العتلة"، مما يعيق تخزين البيانات الزائد في المعاملات. يكمل هذا EIP EIP-7691 التالي (زيادة إنتاجية Blob)، الذي يزيد من الحد الأقصى لكل كتلة blob.
EIP-7691: زيادة في سعة امتصاص الكتل
الرجاء الرجوع إلى: EIP-7691
في الشوكة الصلبة السابقة لـ Dencun ، تم إدخال البلوب ، وكانت القيمة الأولية للحد الأقصى والهدف لكل بلوب في كل كتلة تقديرًا محافظًا. يعود ذلك إلى تعقيد كيفية تعامل الشبكة نقطة إلى نقطة مع كائنات ثنائية كبيرة تنتشر بين العقد الموثقة. قد ثبتت التكوينات السابقة أنها جيدة ، مما يجعل هذا الوقت مناسبًا لاختبار القيم الجديدة. في السابق ، تم تعيين الحد الأقصى / الهدف لعدد البلوب في كل كتلة على 3/6. تم رفع هذه القيود حاليًا إلى 6/9 على التوالي.
بالاقتران مع EIP-7623 السابقة (زيادة تكلفة البيانات المتغيرة) ، تعزز هذه التعديلات نقل بيانات rollup من calldata إلى blobs. لا يزال العمل جاريًا في البحث عن أفضل معلمة لـ blob.
EIP-7840: إضافة جدولة blob إلى ملف تكوين EL
الرجاء الرجوع إلى: EIP-7840
تقترح هذه الـEIP إضافة الهدف والحد الأقصى لعدد الـblob لكل كتلة (التي تمت مناقشتها سابقًا) وقيمة baseFeeUpdateFraction إلى ملف تكوين طبقة التنفيذ في إثريوم (EL). كما يتيح للعميل استرداد هذه القيم عن طريق واجهة برمجة تطبيق العقد. تعتبر هذه الوظيفة مفيدة بشكل خاص لتقدير تكلفة غاز الـblob ومهام مماثلة.
EIP-7702: تعيين كود حساب EOA
مرجع: EIP-7702
هذا هو EIP مهم جدا من شأنه أن يجلب تغييرات كبيرة لمستخدمي Ethereum. كما نعلم ، لا يمكن أن تحتوي EOA (الحسابات المملوكة خارجيا) على أي رمز ، ولكن يمكنها توفير توقيعات المعاملات (tx.origin). في المقابل ، يحتوي العقد الذكي على رمز ثانوي ، ولكن لا يمكنه اقتراح توقيع مباشر ل "it". يمكن لأي تفاعل مستخدم يتطلب منطقا إضافيا وآليا ويمكن التحقق منه حاليا تنفيذ الإجراء المطلوب فقط عن طريق استدعاء عقد خارجي. ومع ذلك ، في هذه الحالة ، يصبح العقد الخارجي هو msg.sender للعقد اللاحق ، مما يجعل المكالمة "من العقد ، وليس المستخدم".
يقدم برنامج EIP هذا نوع معاملة SET_CODE_TX_TYPE=0x04 (كان لدينا معاملة 0x1 القديمة من قبل ، ومعاملة 0x02 الجديدة من برلين وترقية EIP-1559 ، ومعاملة النقطة 0x03 التي تم تقديمها في Dencun). يتيح لك هذا النوع الجديد من التجارة إعداد رموز لحسابات EOA. في الواقع ، يسمح ل EOA بتنفيذ رمز خارجي "في سياق حساب EOA الخاص بها". من منظور خارجي ، يبدو أن EOA "تستعير" رمزا من عقد خارجي وتنفذه أثناء المعاملة. من الناحية الفنية ، يتم ذلك عن طريق إضافة مجموعة من بيانات التفويض الخاصة إلى مخزن "الرمز" لعنوان EOA (حتى EIP هذا ، كان مخزن "الرمز" هذا فارغا دائما إلى EOA).
حاليًا ، يتضمن نوع المعاملة 0x04 الجديد المقترح في EIP مصفوفة:
authorization_list = [[chain_id، العنوان، الرقم التسلسلي، y_parity، r، s]، ...]
يُسمح لكل عنصر باستخدام الحساب برمجية من العنوان المُحدد (من آخر عنصر ترخيص صالح). عند معالجة مثل هذه المعاملات، سيتم تعيين برمجية EOA المعطاة إلى قيمة عنوان خاصة 0xef0100 || (23 بايت)، حيث يشير العنوان إلى عقد يحتوي على البرمجية المطلوبة، || تشير إلى الاتصال، و 0xef0100 يشير إلى قيمة سحرية خاصة للعقود الذكية العامة التي لا يمكن أن تحتوي عليها. هذه القيمة السحرية تضمن أن هذا EOA لا يمكن اعتباره عقدًا عامًا، ولا يمكن استدعاؤه مثل العقود العامة.
عندما يتم إطلاق هذا الـ EOA للتداول، سيتم استخدام العنوان المحدد لاستدعاء الشيفرة المقابلة في سياق هذا الـ EOA. على الرغم من أن تفاصيل تنفيذ هذا الـ EIP لا تزال غير واضحة، يمكن التأكيد على أنه سيحمل تغييرات هامة.
أحد التأثيرات الرئيسية هو القدرة على القيام بمكالمات متعددة مباشرة من EOA (multicall). تعد المكالمات المتعددة اتجاهًا مستمرًا في DeFi ، حيث يقدم العديد من البروتوكولات هذه الميزة كأداة قوية (مثل Uniswap V4 أو Balancer V3 أو Euler V2). مع هذا EIP ، يمكن الآن القيام بمكالمات متعددة مباشرة من EOA.
على سبيل المثال، يحل هذا الميزة الجديدة مشكلة شائعة في DeFi: تعتبر approve() + anything() غير كفءة وتتطلب معاملتين منفصلتين. يسمح هذا EIP بالمنطق العام لـ 'الترخيص المسبق'، مما يتيح إتمام مثل approve(X) + deposit(X) في صفقة واحدة.
يعتبر القدرة على "تمثيل" تنفيذ الصفقات الموكلة لـ EOA ميزة أخرى هامة هي مفهوم الرعاية. الرعاية هي ميزة يتم مناقشتها بانتظام وتحظى برغبة شديدة لمساعدة المستخدمين الجدد على الانضمام إلى الإيثيريوم.
فتحت البرمجة المتعلقة بـ EOA العديد من الإمكانيات ، مثل فرض قيود أمنية وتعيين حدود الإنفاق والمطالبة بمعرفة العميل ، وما إلى ذلك.
بالطبع ، يثير هذا التحول أيضا عددا من أسئلة التصميم. تتمثل إحدى المشكلات في استخدام chain_id ، والذي يحدد ما إذا كان التوقيع نفسه يمكن أن يكون صالحا عبر شبكات متعددة ، اعتمادا على ما إذا كان مضمنا أم لا في التوقيع. تعقيد آخر هو الاختيار بين استخدام عنوان رمز الكائن وتضمين الرمز الثانوي الفعلي. كلتا الطريقتين لها ميزاتها وقيودها الفريدة. بالإضافة إلى ذلك ، يلعب استخدام nonce دورا رئيسيا في تحديد ما إذا كان الإذن "متعدد الأغراض" أو "أحادي الغرض". تؤثر هذه العناصر على مشكلات الوظائف والأمان ، بما في ذلك جوانب مثل توقيعات الإبطال المجمع وسهولة الاستخدام. أثار فيتاليك هذه الأسئلة في مناقشة (هنا) تستحق المزيد من الاستكشاف.
يجب ملاحظة أن هذا التغيير سيؤثر على آلية أمان في Ethereum ، tx.origin. المزيد من التفاصيل حول تطبيق EIP هذا ضروري ، ولكن يبدو أن سيتم تغيير السلوك require(tx.origin == msg.sender). كان هذا الفحص دائمًا وسيلة موثوقة للتأكد من أن msg.sender هو EOA بدلاً من عقد. الطرق الأخرى ، مثل فحص EXTCODESIZE (للتحقق مما إذا كان عقدًا) ، عادة ما تفشل ويمكن تجاوزها (على سبيل المثال ، من خلال استدعاء دالة البناء أو نشر الكود في عنوان محدد مسبقًا بعد الصفقة). يتم استخدام هذه الفحوصات لمنع الهجمات المتكررة والقروض البرقية ، ولكن بعيدة عن كونها مثالية لأنها تعوق أيضًا تكامل البروتوكولات الخارجية. بعد هذا EIP ، يبدو أن حتى الفحص الموثوق requiretx.origin == msg.sender أصبح قديمًا. يجب على البروتوكولات التكيف من خلال إزالة هذه الفحوصات ، لأن الفارق بين "EOA" و "عقد" لن يكون ساري المفعول بعد الآن - الآن كل عنوان قد يحتوي على كود ذي صلة.
استمرار اختلاط الفصل بين EOA التقليدية والعقود الذكية. يجعل هذا EIP Ethereum أقرب إلى تصميم مثل TON حيث كل حساب في الأساس هو رمز قابل للتنفيذ. مع تعقيد التفاعل مع البروتوكول، فإن استخدام البرمجة اللوجيستية لتحسين تجربة المستخدم النهائي هو عملية تطور طبيعية.
الاستنتاج
ترقية براغ / إلكترا (بكترا) مقررة في مارس 2025. أبرز التغييرات المخططة تشمل:
كما ترون، ستؤثر Pectra بشكل كبير على تجربة المستخدم النهائية للرهن والطبقة القائمة على الاتفاق، وطبقة التنفيذ. على الرغم من أننا لا نستطيع في هذه المرحلة تحليل جميع هذه التغييرات بالتفصيل من خلال الشفرة لأن التطوير ما زال قائماً، إلا أننا سنغطي هذه التحديثات في المقالات المستقبلية.