شرح الشوكة الصلبة القادمة لـ Ethereum - ترقية Pectra

مقدمة

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

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

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

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

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

• السماح للرصيد الفعال للمحققين بالتنوع بين 32 و2048 ETH (بدلاً من 32 ETH ثابت).

• يسمح للمحققين ببدء عمليات الخروج عبر بيانات اعتماد "الانسحاب" الثانوية (لم تعد تتطلب مفاتيح محقق نشطة).

• تم تغيير الطريقة التي تتعامل بها طبقة المنارة مع ودائع Eth1 (لم تعد تحلل الأحداث من عقد الإيداع).

• أضف إطارًا عامًا جديدًا للتعامل مع الطلبات من عقود Eth1 العادية على طبقة المنارة (على غرار كيفية إدارة الودائع قبل Electra). في الوقت نفسه، قدمت براغ التغييرات التالية على طبقة التنفيذ: عقد جديد مُجمَّع مسبقًا مع دعم منحنى BLS12-381 للتحقق من أدلة zkSNARK (بالإضافة إلى منحنى BN254 الشهير).

• عقد نظام جديد لتخزين ما يصل إلى 8192 من تجزئة الكتل التاريخية والوصول إليها (مفيد جدًا للعملاء عديمي الجنسية).

• زيادة تكلفة غاز بيانات المكالمات لتقليل حجم الكتلة وتشجيع المشاريع على نقل العمليات التي تتطلب بيانات مكالمات مكثفة (مثل التجميعات) إلى الكتل المقدمة في Dencun.

• دعم أعداد أكبر من الكتل لكل كتلة Eth1، وتوفير واجهة برمجة التطبيقات لقراءة هذه الأرقام.

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

EIP-7002: Execution-Lier Outs

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

EIP-7251: زيادة MAX_EFFECTIVE_BALANCE

المرجع: EIP-7251

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

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

• زيادة احتمالية أن تصبح مقترح كتلة، بما يتناسب مع الرصيد الفعال

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

• كأساس لحساب مبالغ التخفيض النسبي وعقوبة عدم النشاط

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

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

• تكون عقوبات القطع الفورية والمؤجلة أكبر بالنسبة للمحققين ذوي المخاطر العالية.

• إن عقوبة القطع "المتأخرة" للمحققين المقطوعين ذوي المخاطر العالية تكون أكبر أيضًا لأن الجزء "المقطع" من إجمالي المخاطر يصبح أكبر.

• يتلقى المبلغون عن المخالفات الذين يبلغون عن المحققين الذين لديهم أرصدة فعالة أعلى نسبة أكبر من الحصة التي يتم تخفيضها.

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

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

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

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

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

للتلخيص:

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

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

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

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

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

المرجع: EIP-7002

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

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

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

• يحفظ العقد طلب الانسحاب/الخروج "داخلًا" في وحدة التخزين الخاصة به.

• عندما يتم اقتراح كتلة إلى طبقة المنارة، يتم استرداد طلبات السحب/الخروج "الداخلية" الموجودة في قائمة الانتظار من التخزين. تعمل طبقة المنارة على معالجة طلبات "الدخول"، والتفاعل مع أرصدة المحققين النشطين، وترتيب خروج المحققين، وتشكيل طلبات انسحاب "الخروج".

• "out" تتم معالجة طلبات السحب في طبقة التنفيذ ويتلقى المشاركون في العملية ETH الخاصة بهم.

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

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

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

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

المرجع: EIP-6110

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

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

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

المرجع: EIP-7685

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

• يتم "نقل" أحداث الإيداع في كتل Eth1 إلى كتلة المنارة للمعالجة. يتم "نقل" طلبات السحب في كتلة المنارة (باستخدام واجهة سطر الأوامر) إلى كتلة Eth1 للمعالجة.

• يجب معالجة دمج المحقق، وهو أيضًا طلب منارة Eth1->.

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

يضع هذا البرنامج إطارًا لثلاثة سيناريوهات رئيسية على الأقل: الودائع، والسحوبات، والاندماجات. لهذا السبب قدمت خطط 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 المستندة إلى منحنى BLS12-381 (على الرغم من أنه يمكن تنفيذها أيضًا باستخدام أي منحنى يدعم الاقتران، مثل BN254).

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

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

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

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

المرجع: EIP-2935

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

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

المرجع: EIP-7623

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

يمكن تشجيع عمليات التجميع على نقل بياناتها إلى الكتل من خلال نهج "العصا والجزرة". إن الرسوم المخفضة على الغاز المضاف تعمل بمثابة "جزرة"، ويعمل هذا EIP بمثابة "رافعة" من خلال زيادة تكاليف بيانات المكالمات، وبالتالي تثبيط تخزين البيانات المفرط في المعاملات. يكمل هذا EIP EIP-7691 التالي (زيادة إنتاجية Blob)، والذي يزيد من الحد الأقصى لعدد Blobs المسموح به لكل كتلة.

EIP-7691: زيادة معدل إنتاج الكتل

المرجع: EIP-7691

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

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

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

المرجع: EIP-7840

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

EIP-7702: تعيين رمز حساب EOA

المرجع: EIP-7702

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

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

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

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

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

أحد التأثيرات الرئيسية هو القدرة على إجراء مكالمات متعددة مباشرة من EOA. تعد المكالمات المتعددة اتجاهًا مستمرًا في DeFi، مع وجود العديد من البروتوكولات التي تقدم هذه الميزة كأداة قوية (على سبيل المثال Uniswap V4 أو Balancer V3 أو Euler V2). مع هذا EIP، أصبح من الممكن الآن بدء مكالمات متعددة مباشرة من EOA. على سبيل المثال، تحل هذه الميزة الجديدة مشكلة شائعة في DeFi: عدم كفاءة consent() + any() التي تتطلب معاملتين منفصلتين. يسمح هذا EIP بمنطق "الترخيص المسبق" العام بحيث يمكن إجراء أشياء مثل الموافقة (X) + الإيداع (X) في معاملة واحدة.

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

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

الخلاصة

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

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