تخطي إلى المحتوى الرئيسي

فوساكا 🦓

تم إطلاق ترقية فوساكا المرتقبة بشدة لشبكة إيثيريوم في 3 ديسمبر 2025

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

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

Ethereum's latest upgrade: Fusaka

A short overview of Ethereum's Fusaka upgrade featuring Ethereum Foundation contributors and ecosystem builders.

المشاهدة مع النص 

التحسينات في فوساكا

توسيع كتل البيانات (البلوب)

PeerDAS

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

مع أخذ عينات توفر البيانات (DAS) (opens in a new tab)، بدلاً من الاضطرار إلى تخزين جميع بيانات البلوب، ستكون كل عقدة مسؤولة عن مجموعة فرعية من بيانات البلوب. يتم توزيع كتل البيانات بشكل عشوائي وموحد عبر العقد في الشبكة بحيث تحتفظ كل عقدة كاملة بـ 1/8 فقط من البيانات، مما يتيح توسعًا نظريًا يصل إلى 8x. لضمان توفر البيانات، يمكن إعادة بناء أي جزء من البيانات من أي 50% موجودة من الكل باستخدام طرق تقلل من احتمالية البيانات الخاطئة أو المفقودة إلى مستوى ضئيل من الناحية التشفيرية (حوالي واحد في 1020 إلى واحد في 1024).

يحافظ هذا على متطلبات الأجهزة وعرض النطاق الترددي للعقد معقولة مع تمكين توسيع كتل البيانات مما يؤدي إلى مزيد من التوسع مع رسوم أقل لشبكات طبقة 2 (L2).

تعرف على المزيد حول PeerDAS

الموارد:

تفرعات معلمات البلوب فقط (BPO)

تقوم شبكات طبقة 2 (L2) بتوسيع إيثيريوم - ومع نمو شبكاتها، تحتاج إلى نشر المزيد من البيانات على إيثيريوم. هذا يعني أن إيثيريوم ستحتاج إلى زيادة عدد كتل البيانات المتاحة لها بمرور الوقت. على الرغم من أن PeerDAS يتيح توسيع بيانات البلوب، إلا أنه يجب القيام بذلك تدريجيًا وبأمان.

نظرًا لأن إيثيريوم عبارة عن كود يعمل على آلاف العقد المستقلة التي تتطلب الإجماع على نفس القواعد، فلا يمكننا ببساطة إدخال تغييرات مثل زيادة عدد كتل البيانات بالطريقة التي تنشر بها تحديثًا لموقع ويب. يجب أن يكون أي تغيير في القواعد عبارة عن ترقية منسقة حيث يتم ترقية كل عقدة وعميل وبرنامج مُدَقِّق قبل نفس الكتلة المحددة مسبقًا.

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

يمكن تعيين تفرعات معلمات البلوب فقط بواسطة العملاء، على غرار التكوينات الأخرى مثل حد الغاز. بين ترقيات إيثيريوم الرئيسية، يمكن للعملاء الموافقة على زيادة كتل البيانات target و max إلى 9 و 12 على سبيل المثال، ثم سيقوم مشغلو العقد بالتحديث للمشاركة في هذا التفرع الصغير. يمكن تكوين تفرعات معلمات البلوب فقط في أي وقت.

عندما تمت إضافة كتل البيانات لأول مرة إلى الشبكة في ترقية دينكون، كان الهدف هو 3. تمت زيادة ذلك إلى 6 في بيكترا، وبعد فوساكا، يمكن الآن زيادة ذلك بمعدل مستدام بشكل مستقل عن ترقيات الشبكة الرئيسية هذه.

Chart showing average blob count per block and increasing targets with upgrades

مصدر الرسم البياني: كتل بيانات إيثيريوم - @hildobby، Dune Analytics (opens in a new tab)

الموارد: المواصفات الفنية لـ EIP-7892 (opens in a new tab)

الرسم الأساسي للبلوب مقيد بتكاليف التنفيذ

تدفع شبكات طبقة 2 (L2) فاتورتين عند نشر البيانات: رسم البلوب وغاز التنفيذ اللازم للتحقق من كتل البيانات هذه. إذا كان غاز التنفيذ هو المهيمن، فقد ينخفض مزاد رسم البلوب إلى 1 Wei ويتوقف عن كونه إشارة سعرية.

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

  • يتفاعل سوق رسم البلوب دائمًا مع الازدحام
  • تدفع شبكات طبقة 2 (L2) على الأقل شريحة ذات مغزى من الحوسبة التي تفرضها على العقد
  • لم يعد بإمكان الارتفاعات المفاجئة في الرسم الأساسي على طبقة التنفيذ (EL) أن تجعل رسم البلوب عالقًا عند 1 Wei

الموارد:

توسيع طبقة 1 (L1)

انتهاء صلاحية السجل وإيصالات أبسط

في يوليو 2025، بدأ عملاء طبقة التنفيذ في إيثيريوم في دعم انتهاء صلاحية السجل الجزئي (opens in a new tab). أدى هذا إلى إسقاط السجل الأقدم من الدمج (opens in a new tab) من أجل تقليل مساحة القرص التي يطلبها مشغلو العقد مع استمرار نمو إيثيريوم.

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

الموارد: المواصفات الفنية لـ EIP-7642 (opens in a new tab)

تعيين حدود عليا لـ MODEXP

حتى الآن، كان العقد المجمع مسبقًا MODEXP يقبل أرقامًا بأي حجم تقريبًا. جعل ذلك من الصعب اختباره، وسهل إساءة استخدامه، ومحفوفًا بالمخاطر بالنسبة لاستقرار العميل. يضع EIP-7823 حدًا واضحًا: يمكن أن يكون طول كل رقم إدخال على الأكثر 8192 بت (1024 بايت). يتم رفض أي شيء أكبر، ويتم حرق غاز المعاملة، ولا تحدث أي تغييرات في الحالة. إنه يغطي احتياجات العالم الحقيقي بشكل مريح للغاية مع إزالة الحالات القصوى التي عقدت تخطيط حد الغاز والمراجعات الأمنية. يوفر هذا التغيير مزيدًا من الأمان والحماية من هجمات الحرمان من الخدمة (DoS) دون التأثير على تجربة المستخدم أو المطور.

الموارد: المواصفات الفنية لـ EIP-7823 (opens in a new tab)

سقف حد الغاز للمعاملة

يضيف EIP-7825 (opens in a new tab) سقفًا قدره 16,777,216 (2^24) غاز لكل معاملة. إنه تعزيز استباقي ضد هجمات الحرمان من الخدمة (DoS) من خلال تقييد تكلفة أسوأ حالة لأي معاملة فردية بينما نرفع حد الغاز للكتلة. إنه يجعل من السهل نمذجة التحقق من الصحة والنشر للسماح لنا بمعالجة التوسع عبر رفع حد الغاز.

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

الموارد: المواصفات الفنية لـ EIP-7825 (opens in a new tab)

زيادة تكلفة غاز MODEXP

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

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

يغير مقترح تحسين إيثيريوم (EIP) هذا التسعير ليتناسب مع التكاليف الحسابية الحقيقية عن طريق:

  • رفع الحد الأدنى للرسوم من 200 إلى 500 غاز وإزالة خصم الثلث من EIP-2565 على حساب التكلفة العامة
  • زيادة التكلفة بشكل أكثر حدة عندما يكون إدخال الأس طويلًا جدًا. إذا كان الأس (رقم "القوة" الذي تمرره كوسيطة ثانية) أطول من 32 بايت / 256 بت، فإن رسوم الغاز ترتفع بشكل أسرع بكثير لكل بايت إضافي
  • فرض رسوم إضافية على الأساس الكبير أو المعامل أيضًا. يُفترض أن يكون الرقمان الآخران (الأساس والمعامل) على الأقل 32 بايت - إذا كان أي منهما أكبر، ترتفع التكلفة بما يتناسب مع حجمه

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

الموارد: المواصفات الفنية لـ EIP-7883 (opens in a new tab)

حد حجم كتلة التنفيذ المشفرة بـ RLP

يخلق هذا سقفًا لمدى الحجم المسموح به للكتلة - هذا حد لما يتم إرساله عبر الشبكة وهو منفصل عن حد الغاز، والذي يحد من العمل داخل الكتلة. يبلغ الحد الأقصى لحجم الكتلة 10 MiB، مع سماحية صغيرة (2 MiB) مخصصة لبيانات الإجماع بحيث يتناسب كل شيء وينتشر بشكل نظيف. إذا ظهرت كتلة أكبر من ذلك، يرفضها العملاء. هذا ضروري لأن الكتل الكبيرة جدًا تستغرق وقتًا أطول للانتشار والتحقق عبر الشبكة ويمكن أن تخلق مشكلات في الإجماع أو يتم إساءة استخدامها كمتجه لهجوم الحرمان من الخدمة (DoS). أيضًا، لن تقوم بروتوكولات النشر (gossip) في طبقة الإجماع بالفعل بإعادة توجيه الكتل التي تزيد عن حوالي 10 MiB، لذا فإن مواءمة طبقة التنفيذ مع هذا الحد يتجنب المواقف الغريبة المتمثلة في "رآها البعض، وأسقطها البعض الآخر".

التفاصيل الدقيقة: هذا سقف لحجم كتلة التنفيذ المشفرة بـ RLP. الإجمالي 10 MiB، مع هامش أمان 2 MiB مخصص لتأطير كتلة سلسلة المنارة. عمليًا، يحدد العملاء

MAX_BLOCK_SIZE = 10,485,760 بايت و

SAFETY_MARGIN = 2,097,152 بايت،

ويرفضون أي كتلة تنفيذ تتجاوز حمولة RLP الخاصة بها

MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN

الهدف هو تقييد وقت النشر/التحقق في أسوأ الحالات والمواءمة مع سلوك النشر (gossip) في طبقة الإجماع، مما يقلل من مخاطر إعادة التنظيم/هجمات الحرمان من الخدمة (DoS) دون تغيير حساب الغاز.

الموارد: المواصفات الفنية لـ EIP-7934 (opens in a new tab)

تعيين حد الغاز الافتراضي إلى 60 مليون

قبل رفع حد الغاز من 30M إلى 36M في فبراير 2025 (وبعد ذلك إلى 45M)، لم تتغير هذه القيمة منذ الدمج (سبتمبر 2022). يهدف مقترح تحسين إيثيريوم (EIP) هذا إلى جعل التوسع المستمر أولوية.

ينسق EIP-7935 فرق عملاء طبقة التنفيذ (EL) لرفع حد الغاز الافتراضي فوق 45M الحالية لفوساكا. إنه مقترح تحسين إيثيريوم (EIP) إعلامي، ولكنه يطلب صراحة من العملاء اختبار حدود أعلى على شبكات التطوير، والتقارب حول قيمة آمنة، وشحن هذا الرقم في إصدارات فوساكا الخاصة بهم.

يستهدف تخطيط شبكة التطوير ضغطًا يبلغ حوالي 60M (كتل كاملة مع حمل اصطناعي) وزيادات متكررة؛ تقول الأبحاث أن أمراض حجم الكتلة في أسوأ الحالات لا ينبغي أن ترتبط بأقل من حوالي 150M. يجب إقران الطرح بسقف حد الغاز للمعاملة (EIP-7825) بحيث لا يمكن لمعاملة واحدة أن تهيمن مع ارتفاع الحدود.

الموارد: المواصفات الفنية لـ EIP-7935 (opens in a new tab)

تحسين تجربة المستخدم (UX)

النظرة المستقبلية الحتمية للمُقترِح

مع EIP-7917، ستصبح سلسلة المنارة على دراية بمُقترِحي الكتل القادمين للحقبة التالية. إن وجود رؤية حتمية حول المُدَقِّقين الذين سيقترحون الكتل المستقبلية يمكن أن يتيح التأكيدات المسبقة (opens in a new tab) - وهو التزام مع المُقترِح القادم يضمن تضمين معاملة المستخدم في كتلته دون انتظار الكتلة الفعلية.

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

الموارد: المواصفات الفنية لـ EIP-7917 (opens in a new tab)

رمز التشغيل لعد الأصفار البادئة (CLZ)

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

الموارد: المواصفات الفنية لـ EIP-7939 (opens in a new tab)

عقد مجمع مسبقًا لدعم منحنى secp256r1

يقدم مدقق توقيع secp256r1 (P-256) مدمجًا بأسلوب مفتاح مرور في العنوان الثابت 0x100 باستخدام نفس تنسيق الاستدعاء الذي اعتمدته بالفعل العديد من شبكات طبقة 2 (L2) وإصلاح الحالات القصوى، بحيث تعمل العقود المكتوبة لتلك البيئات على طبقة 1 (L1) دون تغييرات.

ترقية لتجربة المستخدم! بالنسبة للمستخدمين، يفتح هذا التوقيع الأصلي للجهاز ومفاتيح المرور. يمكن للمحافظ الاستفادة من Apple Secure Enclave و مخزن المفاتيح في Android ووحدات أمان الأجهزة (HSMs) و FIDO2/WebAuthn مباشرة - لا توجد عبارة الاسترداد، وتهيئة أكثر سلاسة، وتدفقات متعددة العوامل تبدو وكأنها تطبيقات حديثة. يؤدي هذا إلى تجربة مستخدم أفضل، واسترداد أسهل، وأنماط تجريد الحساب التي تتطابق مع ما تفعله مليارات الأجهزة بالفعل.

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

الموارد:

ميتا (Meta)

طريقة eth_config في JSON-RPC

هذا استدعاء JSON-RPC يسمح لك بسؤال عقدتك عن إعدادات التفرع التي تقوم بتشغيلها. يُرجع ثلاث لقطات: current و next و last بحيث يمكن للمُدَقِّقين وأدوات المراقبة التحقق من أن العملاء مصطفون لتفرع قادم.

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

تتضمن اللقطات: chainId و forkId ووقت تفعيل التفرع المخطط له، والعقود المجمعة مسبقًا النشطة، وعناوين العقود المجمعة مسبقًا، وتبعيات عقد النظام، وجدول كتل البيانات (البلوب) للتفرع.

يوجد مقترح تحسين إيثيريوم (EIP) هذا في قسم منفصل عن "مقترحات تحسين إيثيريوم الأساسية" لأن التفرع لا ينفذ أي تغييرات في الواقع - إنه إشعار بأن فرق العملاء يجب أن تنفذ طريقة JSON-RPC هذه بحلول ترقية فوساكا.

الموارد: المواصفات الفنية لـ EIP-7910 (opens in a new tab)

الأسئلة الشائعة

هل تؤثر هذه الترقية على جميع عقد ومُدَقِّقي إيثيريوم؟

نعم، تتطلب ترقية فوساكا تحديثات لكل من عملاء التنفيذ وعملاء الإجماع. سيصدر جميع عملاء إيثيريوم الرئيسيين إصدارات تدعم التفرع الصلب مميزة كأولوية عالية. يمكنك متابعة موعد توفر هذه الإصدارات في مستودعات GitHub الخاصة بالعملاء، أو قنوات ديسكورد (opens in a new tab) الخاصة بهم، أو ديسكورد EthStaker (opens in a new tab)، أو عن طريق الاشتراك في مدونة إيثيريوم للحصول على تحديثات البروتوكول. للحفاظ على المزامنة مع شبكة إيثيريوم بعد الترقية، يجب على مشغلي العقد التأكد من أنهم يقومون بتشغيل إصدار عميل مدعوم. لاحظ أن المعلومات حول إصدارات العملاء حساسة للوقت، ويجب على المستخدمين الرجوع إلى أحدث التحديثات للحصول على أحدث التفاصيل.

كيف يمكن تحويل ETH بعد التفرع الصلب؟

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

المزيد حول التعرف على عمليات الاحتيال وتجنبها

ما قصة الحمر الوحشية؟

الحمار الوحشي هو "التميمة" التي اختارها المطورون لفوساكا لأن خطوطه تعكس أخذ عينات توفر البيانات (DAS) القائمة على الأعمدة في PeerDAS، حيث تحتفظ العقد بشبكات فرعية معينة للأعمدة وتأخذ عينات من بضعة أعمدة أخرى من خانة كل نظير للتحقق من توفر بيانات البلوب.

استخدم الدمج في عام 2022 باندا (opens in a new tab) كتميمة له للإشارة إلى انضمام طبقتي التنفيذ والإجماع. منذ ذلك الحين، تم اختيار التمائم بشكل غير رسمي لكل تفرع وتظهر كفن ASCII في سجلات العميل في وقت الترقية. إنها مجرد طريقة ممتعة للاحتفال.

ما هي التحسينات المضمنة لتوسيع طبقة 2 (L2)؟

PeerDAS هو الميزة الرئيسية للتفرع. إنه ينفذ أخذ عينات توفر البيانات (DAS) الذي يفتح المزيد من قابلية التوسع للتجميعات، مما يؤدي نظريًا إلى توسيع مساحة البلوب حتى 8 أضعاف الحجم الحالي. سيتم أيضًا تحسين سوق رسم البلوب للتفاعل بكفاءة مع الازدحام وضمان دفع شبكات طبقة 2 (L2) رسومًا ذات مغزى للحوسبة والمساحة التي تفرضها كتل البيانات على العقد.

كيف تختلف تفرعات BPO؟

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

كمستخدم أو مُدَقِّق، لا تحتاج إلى تحديث عملائك لكل BPO وتأكد فقط من متابعة التفرعات الصلبة الرئيسية مثل فوساكا. هذه هي نفس الممارسة كما كان من قبل، ولا توجد إجراءات خاصة مطلوبة. لا يزال يوصى بمراقبة عملائك حول الترقيات و BPOs وإبقائهم محدثين حتى بين الإصدارات الرئيسية حيث قد تتبع الإصلاحات أو التحسينات التفرع الصلب.

ما هو جدول BPO؟

سيتم تحديد الجدول الزمني الدقيق لتحديثات BPO مع إصدارات فوساكا. اتبع إعلانات البروتوكول (opens in a new tab) وملاحظات الإصدار لعملائك.

مثال على كيف قد يبدو الأمر:

  • قبل فوساكا: الهدف 6، الحد الأقصى 9
  • عند تفعيل فوساكا: الهدف 6، الحد الأقصى 9
  • BPO1، بعد أسابيع قليلة من تفعيل فوساكا: الهدف 10، الحد الأقصى 15، بزيادة قدرها الثلثين
  • BPO2، بعد أسابيع قليلة من BPO1: الهدف 14، الحد الأقصى 21

هل سيؤدي هذا إلى خفض الرسوم على إيثيريوم (طبقة 1)

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

بصفتي مخزنًا (staker)، ماذا أحتاج أن أفعل من أجل الترقية؟

كما هو الحال مع كل ترقية للشبكة، تأكد من تحديث عملائك إلى أحدث الإصدارات المميزة بدعم فوساكا. اتبع التحديثات في القائمة البريدية وإعلانات البروتوكول على مدونة مؤسسة إيثيريوم (EF) (opens in a new tab) للحصول على معلومات حول الإصدارات. للتحقق من إعدادك قبل تفعيل فوساكا على الشبكة الرئيسية، يمكنك تشغيل مُدَقِّق على شبكات الاختبار. يتم تفعيل فوساكا في وقت أقرب على شبكات الاختبار (opens in a new tab) مما يمنحك مساحة أكبر للتأكد من أن كل شيء يعمل والإبلاغ عن الأخطاء. يتم الإعلان عن تفرعات شبكة الاختبار أيضًا في القائمة البريدية والمدونة.

هل تؤثر "النظرة المستقبلية الحتمية للمُقترِح" (EIP-7917) على المُدَقِّقين؟

لا يغير هذا التغيير كيفية عمل عميل المُدَقِّق الخاص بك، ومع ذلك، فإنه سيوفر مزيدًا من التبصر في مستقبل واجبات المُدَقِّق الخاصة بك. تأكد من تحديث أدوات المراقبة الخاصة بك لمواكبة الميزات الجديدة.

كيف تؤثر فوساكا على متطلبات عرض النطاق الترددي للعقد والمُدَقِّقين؟

يُحدث PeerDAS تغييرًا كبيرًا في كيفية نقل العقد لبيانات البلوب. يتم تقسيم جميع البيانات إلى أجزاء تسمى أعمدة عبر 128 شبكة فرعية مع اشتراك العقد في بعضها فقط. يعتمد مقدار أعمدة الشبكة الفرعية التي يجب على العقد الاحتفاظ بها على تكوينها وعدد المُدَقِّقين المتصلين. ستعتمد متطلبات عرض النطاق الترددي الفعلية على كمية كتل البيانات المسموح بها في الشبكة ونوع العقدة. في لحظة تفعيل فوساكا، يظل هدف البلوب كما كان من قبل، ولكن مع PeerDAS، يمكن لمشغلي العقد رؤية انخفاض في استخدام القرص لكتل البيانات وحركة مرور الشبكة. نظرًا لأن BPOs تقوم بتكوين أعداد أكبر من كتل البيانات في الشبكة، سيزداد عرض النطاق الترددي اللازم مع كل BPO.

لا تزال متطلبات العقد ضمن الهوامش الموصى بها (opens in a new tab) حتى بعد BPOs الخاصة بفوساكا.

العقد الكاملة

ستشترك العقد العادية التي لا تحتوي على أي مُدَقِّقين في 4 شبكات فرعية فقط، مما يوفر الحفظ لـ 1/8 من البيانات الأصلية. هذا يعني أنه مع نفس المقدار من بيانات البلوب، سيكون عرض النطاق الترددي للعقدة لتنزيلها أصغر بمعامل ثمانية (8). قد ينخفض استخدام القرص وعرض النطاق الترددي لتنزيل كتل البيانات لعقدة كاملة عادية بحوالي 80%، إلى بضعة ميغابايت فقط.

المخزنون الفرديون

إذا تم استخدام العقدة لعميل مُدَقِّق، فيجب عليها الاحتفاظ بمزيد من الأعمدة وبالتالي معالجة المزيد من البيانات. مع إضافة مُدَقِّق، تشترك العقدة في ما لا يقل عن 8 شبكات فرعية للأعمدة وبالتالي تعالج ضعف كمية البيانات التي تعالجها العقدة العادية ولكنها لا تزال أقل مما كانت عليه قبل فوساكا. إذا كان رصيد المُدَقِّق أعلى من 287 ETH، فسيتم الاشتراك في المزيد والمزيد من الشبكات الفرعية.

بالنسبة للمخزن الفردي، هذا يعني أن استخدام القرص وعرض النطاق الترددي للتنزيل سينخفض بحوالي 50%. ومع ذلك، لبناء الكتل محليًا وتحميل جميع كتل البيانات إلى الشبكة، هناك حاجة إلى المزيد من عرض النطاق الترددي للتحميل. سيحتاج البناة المحليون إلى عرض نطاق ترددي للتحميل أعلى بـ 2-3 مرات من ذي قبل في وقت فوساكا ومع هدف BPO2 البالغ 15/21 كتلة بيانات، يجب أن يكون عرض النطاق الترددي النهائي اللازم للتحميل أعلى بحوالي 5 مرات، عند 100Mpbs.

المُدَقِّقون الكبار

ينمو عدد الشبكات الفرعية المشتركة مع إضافة المزيد من الرصيد والمُدَقِّقين إلى العقدة. على سبيل المثال، عند رصيد يبلغ حوالي 800 ETH، تحتفظ العقدة بـ 25 عمودًا وستحتاج إلى عرض نطاق ترددي للتنزيل أكثر بنسبة 30% تقريبًا من ذي قبل. يرتفع التحميل الضروري بشكل مشابه للعقد العادية ويلزم ما لا يقل عن 100Mbps.

عند 4096 ETH، و 2 من المُدَقِّقين ذوي الحد الأقصى للرصيد، تصبح العقدة "عقدة فائقة" تحتفظ بجميع الأعمدة، وبالتالي تقوم بتنزيل وتخزين كل شيء. تعمل هذه العقد بنشاط على معالجة الشبكة من خلال المساهمة في إعادة البيانات المفقودة ولكنها تتطلب أيضًا عرض نطاق ترددي وتخزينًا أكبر بكثير. مع كون هدف البلوب النهائي أعلى بـ 6 مرات من ذي قبل، سيتعين على العقد الفائقة تخزين حوالي 600GB من بيانات البلوب الإضافية والحصول على عرض نطاق ترددي أسرع ومستدام للتنزيل عند حوالي 20Mbps.

اقرأ المزيد من التفاصيل حول المتطلبات المتوقعة. (opens in a new tab)

ما هي تغييرات آلة إيثيريوم الافتراضية (EVM) التي تم تنفيذها؟

تعزز فوساكا آلة إيثيريوم الافتراضية (EVM) بتغييرات وميزات ثانوية جديدة.

كيف يؤثر حد الغاز الجديد البالغ 16M على مطوري العقود؟

تقدم فوساكا حدًا للحد الأقصى لحجم المعاملة الواحدة إلى 16.7 مليون (opens in a new tab) (2^24) وحدة غاز. هذا هو تقريبًا الحجم السابق للكتلة المتوسطة مما يجعلها كبيرة بما يكفي لاستيعاب المعاملات المعقدة التي من شأنها أن تستهلك كتلة كاملة. يخلق هذا الحد حماية للعملاء، ويمنع هجمات الحرمان من الخدمة (DoS) المحتملة في المستقبل مع حد غاز أعلى للكتلة. الهدف من التوسع هو تمكين المزيد من المعاملات من الدخول إلى سلسلة الكتل دون أن تستهلك معاملة واحدة الكتلة بأكملها.

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

طريقة RPC eth_call غير محدودة وستسمح بمحاكاة معاملات أكبر من الحد الفعلي لسلسلة الكتل. يمكن تكوين الحد الفعلي لطرق RPC بواسطة مشغل العميل لضمان منع إساءة الاستخدام.

ماذا يعني CLZ للمطورين؟

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

هل هناك أي تغييرات على عقودي الذكية الحالية؟

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

مع زيادة تكلفة العقد المجمع مسبقًا ModExp (opens in a new tab)، ستستهلك العقود التي تعتمد عليه المزيد من الغاز للتنفيذ. إذا كان عقدك يعتمد بشكل كبير على هذا ويصبح أكثر تكلفة للمستخدمين، فأعد النظر في كيفية استخدامه.

ضع في اعتبارك الحد الجديد البالغ 16.7 مليون (opens in a new tab) إذا كانت المعاملات التي تنفذ عقودك قد تصل إلى حجم مماثل.

قراءة إضافية