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

آخر تحديث للصفحة: 23 فبراير 2026

فوساكا

تم تفعيل ترقية Fusaka التي طال انتظارها على إيثريوم في 3 ديسمبر 2025

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

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

توسيع نطاق الكتل

بير داس

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

مع استخدام تقنية أخذ عينات من البيانات المتاحة (opens in a new tab) ، لم يعد من الضروري تخزين جميع بيانات البلوبس (Blobs)؛ إذ ستصبح كل عقدة مسؤولة فقط عن مجموعة فرعية من هذه البيانات. توزع بيانات البلوبس (Blobs) بشكل عشوائي وموحَّد عبر جميع العقد في الشبكة، بحيث تحتفظ كل عقدة كاملة بما يقارب ¹∕₈ فقط من إجمالي البيانات، مما يتيح توسيع نطاق الشبكة نظريًا حتى ثمانية أضعاف. لضمان توفر البيانات، يمكن إعادة بناء أي جزء من البيانات من أي 50% متوفرة من البيانات الكاملة باستخدام أساليب تقلل من احتمالية وجود بيانات خاطئة أو مفقودة إلى مستوى ضئيل من الناحية التشفيرية (ما يقرب من واحد في 1020 إلى واحد في 1024).

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

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

المصادر:

التفرعات الخاصة بمعلمات الكتل فقط

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

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

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

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

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

مخطط يوضح متوسط عدد الكتل (blobs) لكل كتلة والأهداف المتزايدة مع الترقيات

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

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

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

تدفع الطبقة الثانية فاتورتين عند نشر البيانات: رسوم blob ورسوم الغاز اللازمة للتحقق من تلك blobs. إذا كان غاز التنفيذ هو السائد، فإن مزاد رسوم البلوب يمكن أن ينخفض إلى 1 ويي ويتوقف عن كونه إشارة سعرية.

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

  • سوق رسوم البلوب يتفاعل دائمًا مع الاكتظاظ
  • تدفع الطبقة الثانية على الأقل جزءًا ذا مغزى من الحوسبة التي تفرضها على العقد
  • لم يعد بإمكان ارتفاع الرسوم الأساسية على EL أن يبقي رسوم blob عند 1 wei

المصادر:

توسيع نطاق الطبقة الأولى (L1)

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

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

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

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

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

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

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

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

MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN

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

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

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

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

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

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

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

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

التنبؤ المسبق للمقترح الحتمي

مع 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، باستخدام نفس تنسيق الاستدعاء المعتمد بالفعل من قبل العديد من الطبقات الثانية (L2s) ويعالج الحالات الهامشية، بحيث تعمل العقود المكتوبة لتلك البيئات على الطبقة الأولى (L1) دون تغييرات.

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

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

المصادر:

ما وراء

طريقة eth_config JSON-RPC

هذا استدعاء JSON-RPC يسمح لك بسؤال عقدتك عن إعدادات التفرع التي تعمل بها. يعيد ثلاث لقطات: current وnext وlast حتى يتمكن المدققون وأدوات المراقبة من التحقق من أن العملاء مستعدون لتفرع قادم.

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

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

يقع EIP هذا في قسم منفصل عن "EIPs الأساسية" لأن التفرع لا ينفذ أي تغييرات فعلية - بل هو إشعار بأنه يجب على فرق العملاء تنفيذ طريقة JSON-RPC هذه بحلول ترقية Fusaka.

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

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

هل يؤثر هذا التحديث على جميع عقد وإ إيثيريوم؟

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

كيف يمكن تحويل ETH بعد الانقسام الكلي؟

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

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

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

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

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

ما هي التحسينات المدرجة لتوسيع نطاق الطبقة الثانية (L2)؟

بير داس هي الميزة الرئيسية للتفرع. تنفذ أخذ عينات توفر البيانات (DAS) مما يتيح المزيد من قابلية التوسع لـ rollups، وتوسع نظريًا مساحة الكتل (blob) حتى 8 أضعاف حجمها الحالي. سيتم أيضًا تحسين سوق رسوم الكتل (blob) للتفاعل بكفاءة مع الازدحام وضمان دفع الطبقات الثانية (L2s) لرسوم معقولة مقابل الحوسبة والمساحة التي تفرضها الكتل على العقد.

بماذا تختلف تفرعات BPO؟

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

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

ما هو جدول تفرعات BPO؟

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

مثال على الشكل الذي قد يبدو عليه:

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

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

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

بصفتي مُكدِّسًا، ما الذي يجب أن أفعله من أجل الترقية؟

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

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

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

كيف يؤثر Fusaka على متطلبات عرض النطاق الترددي للعقد والمدققين؟

يُحدث بير داس تغييرًا كبيرًا في كيفية نقل العقد لبيانات الكتل (blob). يتم تقسيم جميع البيانات إلى أجزاء تسمى أعمدة عبر 128 شبكة فرعية مع اشتراك العقد في بعضها فقط. يعتمد عدد أعمدة الشبكات الفرعية التي يجب على العقد الاحتفاظ بها على تكوينها وعدد المدققين المتصلين. ستعتمد متطلبات عرض النطاق الترددي الفعلية على كمية الكتل (blobs) المسموح بها في الشبكة ونوع العقدة. في لحظة تفعيل Fusaka، يظل هدف الكتل (blob) كما هو من قبل، ولكن مع بير داس، يمكن لمشغلي العقد ملاحظة انخفاض في استخدامهم لقرص الكتل (blobs) وحركة مرور الشبكة. نظرًا لأن تفرعات BPO تقوم بتكوين أعداد أكبر من الكتل (blobs) في الشبكة، سيزداد عرض النطاق الترددي اللازم مع كل تفرع BPO.

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

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

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

المحصصون المنفردون

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

بالنسبة للمُكدِّس الفردي، يعني هذا أن استخدام القرص وعرض النطاق الترددي للتنزيل سينخفض بنسبة 50% تقريبًا. ومع ذلك، لبناء الكتل محليًا وتحميل جميع الكتل (blobs) إلى الشبكة، يلزم المزيد من عرض النطاق الترددي للتحميل. سيحتاج البناة المحليون إلى عرض نطاق ترددي للتحميل أعلى بمرتين إلى ثلاث مرات من ذي قبل في وقت Fusaka ومع هدف BPO2 البالغ 15/21 كتلة، سيتعين أن يكون عرض النطاق الترددي اللازم للتحميل النهائي أعلى بحوالي 5 مرات، عند 100 ميجابت في الثانية.

المدققون الكبار

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

عند 4096 ETH، وهو الحد الأقصى لرصيد مدققين، تصبح العقدة "عقدة فائقة" تحتفظ بجميع الأعمدة، وبالتالي تقوم بتنزيل وتخزين كل شيء. تقوم هذه العقد بنشاط بمعالجة الشبكة من خلال المساهمة بالبيانات المفقودة ولكنها تتطلب أيضًا عرض نطاق ترددي وتخزينًا أكبر بكثير. مع كون الهدف النهائي للكتل (blob) أعلى بست مرات من ذي قبل، سيتعين على العقد الفائقة تخزين حوالي 600 جيجابايت إضافية من بيانات الكتل والحصول على عرض نطاق ترددي للتنزيل المستمر أسرع عند حوالي 20 ميجابت في الثانية.

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

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

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

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

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

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

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

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

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

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

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

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

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

قراءة إضافية

آخر تحديث للصفحة: 23 فبراير 2026

architr4a (opens in a new tab)
JoeChenJJ (opens in a new tab)
corwintinesc (opens in a new tab)
+5

هل كانت هذه المقالة مفيدة؟