ما الذي تتضمنه ترقية بيكترا؟

عرض تقديمي بواسطة كريستين كيم في مؤتمر Devcon SEA يغطي مقترحات تحسين إيثيريوم (EIPs) المضمنة في ترقية بيكترا لشبكة إيثيريوم، وما تغيره في البروتوكول، وموعد التفعيل المتوقع على الشبكة الرئيسية، ومقترحات تحسين إيثيريوم التي تمت إزالتها من النطاق.

هذا النص هو نسخة يسهل الوصول إليها من النص الأصلي للفيديو (opens in a new tab) الذي نشرته مؤسسة إيثيريوم. تم تحريره بشكل طفيف لتسهيل القراءة.

مقدمة (0:00)

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

متى سيتم إطلاق بيكترا على الشبكة الرئيسية (0:23)

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

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

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

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

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

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

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

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

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

مقترحات تحسين إيثيريوم لطبقة التنفيذ (6:23)

دعونا ننتقل إلى صلب هذا الحديث — ما الذي تتضمنه ترقية بيكترا. هناك عشرة مقترحات تحسين إيثيريوم (EIPs) ستتضمنها بيكترا، وأربعة منها تركز على طبقة التنفيذ.

EIP-2537 هو عقد مجمع مسبقًا جديد في آلة إيثيريوم الافتراضية (EVM) — عمليات منحنى BLS12-381. هذا مخطط توقيع تشفيري جديد كان مطورو العقود الذكية يطلبونه لفترة طويلة جدًا. تم إنشاء هذا المقترح في عام 2020، وفي ذلك الوقت كان مطورو التطبيقات اللامركزية (dapps) يقولون إنهم يريدونه حقًا لأنه سيعطي بعض التطبيقات اللامركزية التي تعتمد على تشفير المعرفة الصفرية ضمانات خصوصية أقوى، وربما زيادة في الأمان وقابلية التوسع. توقيعات BLS هي أيضًا التجميع الذي يحدث على طبقة الإجماع لتصديقات المُدَقِّقين. هذا المقترح طال انتظاره. أحد المخاوف هو: هل لا تزال هناك تطبيقات تنتظر العقد المجمع مسبقًا BLS، وهل سيستخدمونه عندما يتم إطلاقه؟ ولكن إذا كنت من بين الحضور ولم تكن تعلم أن العقد المجمع مسبقًا BLS قادم أخيرًا — فهو قادم.

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

EIP-7685 — طلبات طبقة التنفيذ ذات الأغراض العامة. لا يقدم هذا المقترح حقًا ميزات جديدة لإيثيريوم — إنه مقترح لدعم مقترحات تحسين إيثيريوم الأخرى في بيكترا. في بيكترا، هناك بضعة مقترحات ستتمكن فيها طبقة التنفيذ من تمرير رسائل أكثر بكثير — أنواع مختلفة من الرسائل — إلى طبقة الإجماع والتي لم تكن قادرة على تمريرها من قبل. ستتمكن العقود الذكية على طبقة التنفيذ من تشغيل عمليات سحب المُدَقِّقين، والدمج، والإيداعات. بدلاً من تنفيذ قنوات الاتصال الجديدة هذه كل على حدة وبطريقة فريدة، ينشئ هذا المقترح هيكلًا معممًا — ناقلًا معممًا — لاستيعاب هذه الطلبات. سيكون من الأسهل اختباره، وأسهل في التنفيذ عبر العملاء، وأسهل في التوحيد القياسي، خاصة إذا أراد المطورون تقديم أنواع جديدة من الطلبات التي يمكن تشغيلها من طبقة التنفيذ.

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

مقترحات تحسين إيثيريوم لطبقة الإجماع (12:00)

هناك ستة مقترحات أخرى — هذه هي مقترحات تحسين إيثيريوم لطبقة الإجماع.

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

EIP-6110 — توفير إيداعات المُدَقِّقين على السلسلة. حدث الدمج وأصبحت إيثيريوم أكثر نضجًا كسلسلة كتل تعمل بآلية إثبات الحصة (PoS). يمكن الآن تخفيف بعض الافتراضات الأمنية. يزيل هذا المقترح جولة إضافية من التصويت تحدث على جانب طبقة الإجماع في كل مرة تقوم فيها بإيداع 32 ETH في عقد الإيداع، مما يضمن حدوث جميع عمليات التحقق من الإيداع على طبقة التنفيذ. هذا له فوائد لتجربة مستخدم المُدَقِّق — سيقلص الوقت بين إيداعك لـ 32 ETH ورؤية المُدَقِّق مفعلًا بالفعل على سلسلة المنارة.

EIP-7002 — عمليات سحب يمكن تشغيلها من طبقة التنفيذ. هذا جيد جدًا لمجمعات التخزين. في الوقت الحالي، إذا كنت ترغب في سحب مُدَقِّق بالكامل، يحتاج مشغل العقدة الذي يدير هذا المُدَقِّق إلى استخدام مفتاح السحب الخاص به لإجراء خروج كامل للمُدَقِّق. من خلال هذا المقترح، ستتمكن العقود الذكية من بدء عمليات السحب الكاملة هذه. إنه افتراض ثقة يمكنك الآن إزالته من مجمعات التخزين — يمكن لأمثال Lido و Rocket Pool ومجمعات التخزين الأخرى القائمة على العقود الذكية الآن تشغيل عمليات سحب كاملة للمُدَقِّقين إذا رغبوا في ذلك.

EIP-7251 — زيادة الحد الأقصى للرصيد الفعال. هذه مشكلة حقيقية. عندما كان المطورون يفكرون في سلسلة المنارة، لم يتوقعوا أن تنمو مجموعة المُدَقِّقين بهذه السرعة — نحن عند حوالي 1.2 أو 1.3 مليون مُدَقِّق. هناك الكثير من المُدَقِّقين النشطين، والكثير من الرسائل التي يتم تمريرها على طبقة الشبكة، وهذا أكثر من اللازم. إنه يرهق العقد، وإذا تُرك دون رادع فسيكون مشكلة كبيرة لصحة إيثيريوم. تم تصميم EIP-7251 لتشجيع المُدَقِّقين على دمج أرصدتهم من الإيثر والحصول على حد أقصى للرصيد الفعال أعلى من 32 ETH، مما يقلل من عدد المُدَقِّقين النشطين على إيثيريوم.

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

ملخص (17:19)

بيكترا هي مجموعة متنوعة من التحديثات. ستقوم بثلاثة أشياء: أولاً، إصلاح أوجه القصور الحرجة في إيثيريوم كسلسلة كتل تعمل بآلية إثبات الحصة (PoS) — فكر في MaxEB، هذا إصلاح حاسم لأن حجم مجموعة المُدَقِّقين يمكن أن يستمر في النمو دون رادع. ثانيًا، تحسين تجربة المستخدم — نوع المعاملة الجديد، وتصميمات أكثر مرونة، وبعض التحسينات لتصميمات أكثر منزوعة الثقة لمجمعات التخزين. وثالثًا، زيادة سعة توفر البيانات في إيثيريوم — لم يتم تضمين ذلك رسميًا في بيكترا ولكنه يبدو مرجحًا.

مقترحات تحسين إيثيريوم التي تمت إزالتها من بيكترا (18:02)

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

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

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

تم نقل هذه الآن إلى فوساكا. كان من المقرر في البداية أن يكون Verkle في فوساكا ولكن تم تأجيله منذ ذلك الحين. EOF و PeerDAS موجودان في فوساكا في الوقت الحالي. هناك مقترحات تحسين إيثيريوم أخرى سيعيد المطورون النظر في تضمينها في فوساكا — انتقال SSZ، وقوائم التضمين، والتغييرات في الإصدار، وانتهاء صلاحية السجل، و ePBS، واتجاه تجريد الحساب.

أسئلة وأجوبة (22:02)

المضيف: متى سيتم إطلاق EOF؟

كريستين كيم: لقد قلت للتو إن المطورين سيحاولون وضعه في فوساكا. هل أعتقد أن هذا مرجح؟ ربما لا. هل أعتقد أن فوساكا ستحدث في عام 2025؟ بالتأكيد لا. مقدار الوقت الذي استغرقه التحضير لبيكترا — ستستغرق فوساكا وقتًا مشابهًا إن لم يكن أطول.

المضيف: هل هناك مسار طوارئ لزيادة هدف كتلة البيانات بين الآن وتفعيل بيكترا؟

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

المضيف: هل المقترح هو تغيير حد كتلة البيانات فقط أم هدف كتلة البيانات أيضًا؟

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

المضيف: لقد حثثت الناس على المشاركة بشكل أكبر في الحوكمة. كيف يمكن للمجتمع المشاركة بشكل أكبر؟

كريستين كيم: ETH Research و ETH Magicians هما منتديان رائعان للنقاش للتصويت لصالح مقترحات تحسين إيثيريوم (EIPs) معينة وإظهار دعمك. ربما تكون مكالمات مطوري النواة (ACD) هي المكان الأكثر أهمية — كل ما عليك فعله هو ترك تعليق على جدول أعمال مكالمة ACD على GitHub والقول إن هذا هو مقترح تحسين إيثيريوم تود التحدث عنه أو تقديمه. عادة ما يكون مدير المكالمة موافقًا جدًا على منحك الوقت. لكن لا تأخذ الكثير من الوقت — ربما خمس دقائق لقول ما لديك.