--- title: "فوساكا 🦓" metaTitle: "فولو-أوساكا (فوساكا)" description: "تعرف على ترقية بروتوكول فوساكا" lang: ar template: upgrade authors: ["Nixo", "ماريو هافيل"] --- **تم إطلاق ترقية فوساكا المرتقبة بشدة لشبكة إيثيريوم في 3 ديسمبر 2025** تأتي ترقية شبكة فوساكا بعد [بيكترا](/roadmap/pectra/) وتقدم المزيد من الميزات الجديدة وتحسن التجربة لكل مستخدم ومطور في [إيثيريوم](/). يتكون الاسم من ترقية طبقة التنفيذ أوساكا (Osaka) وإصدار طبقة الإجماع المسمى على اسم نجم فولو (Fulu). يتلقى كلا الجزأين من إيثيريوم ترقية تدفع توسع إيثيريوم وأمانه وتجربة المستخدم نحو المستقبل. تعد ترقية فوساكا مجرد خطوة واحدة في أهداف التطوير طويلة المدى لشبكة إيثيريوم. تعرف على المزيد حول [خارطة طريق البروتوكول](/roadmap/) و[الترقيات السابقة](/ethereum-forks/). ## التحسينات في فوساكا {#improvements-in-fusaka} ### توسيع كتل البيانات (البلوب) {#scale-blobs} #### PeerDAS {#peerdas} هذا هو _الحدث الأبرز_ في تفرع فوساكا، والميزة الرئيسية المضافة في هذه الترقية. تقوم شبكات طبقة 2 (L2) حاليًا بنشر بياناتها على إيثيريوم في كتل بيانات (بلوب)، وهي نوع البيانات المؤقتة التي تم إنشاؤها خصيصًا لشبكات طبقة 2 (L2). قبل فوساكا، كان يجب على كل عقدة كاملة تخزين كل كتلة بيانات للتأكد من وجود البيانات. مع ارتفاع قدرة المعالجة لكتل البيانات، يصبح تنزيل كل هذه البيانات مستهلكًا للموارد بشكل لا يمكن تحمله. مع [أخذ عينات توفر البيانات (DAS)](https://notes.ethereum.org/@fradamt/das-fork-choice)، بدلاً من الاضطرار إلى تخزين جميع بيانات البلوب، ستكون كل عقدة مسؤولة عن مجموعة فرعية من بيانات البلوب. يتم توزيع كتل البيانات بشكل عشوائي وموحد عبر العقد في الشبكة بحيث تحتفظ كل عقدة كاملة بـ 1/8 فقط من البيانات، مما يتيح توسعًا نظريًا يصل إلى 8x. لضمان توفر البيانات، يمكن إعادة بناء أي جزء من البيانات من أي 50% موجودة من الكل باستخدام طرق تقلل من احتمالية البيانات الخاطئة أو المفقودة إلى مستوى ضئيل من الناحية التشفيرية (حوالي واحد في 1020 إلى واحد في 1024). يحافظ هذا على متطلبات الأجهزة وعرض النطاق الترددي للعقد معقولة مع تمكين توسيع كتل البيانات مما يؤدي إلى مزيد من التوسع مع رسوم أقل لشبكات طبقة 2 (L2). [تعرف على المزيد حول PeerDAS](/roadmap/fusaka/peerdas/) **الموارد**: - [المواصفات الفنية لـ EIP-7594](https://eips.ethereum.org/EIPS/eip-7594) - [DappLion يتحدث عن PeerDAS: توسيع إيثيريوم اليوم | ETHSofia 2024](https://youtu.be/bONWd1x2TjQ?t=328) - [أكاديمي: توثيق لـ PeerDAS في إيثيريوم (PDF)](https://eprint.iacr.org/2024/1362.pdf) #### تفرعات معلمات البلوب فقط (BPO) {#blob-parameter-only-forks} تقوم شبكات طبقة 2 (L2) بتوسيع إيثيريوم - ومع نمو شبكاتها، تحتاج إلى نشر المزيد من البيانات على إيثيريوم. هذا يعني أن إيثيريوم ستحتاج إلى زيادة عدد كتل البيانات المتاحة لها بمرور الوقت. على الرغم من أن PeerDAS يتيح توسيع بيانات البلوب، إلا أنه يجب القيام بذلك تدريجيًا وبأمان. نظرًا لأن إيثيريوم عبارة عن كود يعمل على آلاف العقد المستقلة التي تتطلب الإجماع على نفس القواعد، فلا يمكننا ببساطة إدخال تغييرات مثل زيادة عدد كتل البيانات بالطريقة التي تنشر بها تحديثًا لموقع ويب. يجب أن يكون أي تغيير في القواعد عبارة عن ترقية منسقة حيث يتم ترقية كل عقدة وعميل وبرنامج مُدَقِّق قبل نفس الكتلة المحددة مسبقًا. تتضمن هذه الترقيات المنسقة عمومًا الكثير من التغييرات، وتتطلب الكثير من الاختبارات، وهذا يستغرق وقتًا. من أجل التكيف بشكل أسرع مع احتياجات كتل بيانات طبقة 2 (L2) المتغيرة، تقدم تفرعات معلمات البلوب فقط آلية لزيادة كتل البيانات دون الحاجة إلى الانتظار في جدول الترقية هذا. يمكن تعيين تفرعات معلمات البلوب فقط بواسطة العملاء، على غرار التكوينات الأخرى مثل حد الغاز. بين ترقيات إيثيريوم الرئيسية، يمكن للعملاء الموافقة على زيادة كتل البيانات `target` و `max` إلى 9 و 12 على سبيل المثال، ثم سيقوم مشغلو العقد بالتحديث للمشاركة في هذا التفرع الصغير. يمكن تكوين تفرعات معلمات البلوب فقط في أي وقت. عندما تمت إضافة كتل البيانات لأول مرة إلى الشبكة في ترقية دينكون، كان الهدف هو 3. تمت زيادة ذلك إلى 6 في بيكترا، وبعد فوساكا، يمكن الآن زيادة ذلك بمعدل مستدام بشكل مستقل عن ترقيات الشبكة الرئيسية هذه. ![Chart showing average blob count per block and increasing targets with upgrades](./average-blob-count-per-block.webp) مصدر الرسم البياني: [كتل بيانات إيثيريوم - @hildobby، Dune Analytics](https://dune.com/hildobby/blobs) **الموارد**: [المواصفات الفنية لـ EIP-7892](https://eips.ethereum.org/EIPS/eip-7892) #### الرسم الأساسي للبلوب مقيد بتكاليف التنفيذ {#blob-base-fee-bounded-by-execution-costs} تدفع شبكات طبقة 2 (L2) فاتورتين عند نشر البيانات: رسم البلوب وغاز التنفيذ اللازم للتحقق من كتل البيانات هذه. إذا كان غاز التنفيذ هو المهيمن، فقد ينخفض مزاد رسم البلوب إلى 1 Wei ويتوقف عن كونه إشارة سعرية. يحدد EIP-7918 سعرًا احتياطيًا نسبيًا تحت كل كتلة بيانات. عندما يكون الاحتياطي أعلى من الرسم الأساسي الاسمي للبلوب، تتعامل خوارزمية تعديل الرسوم مع الكتلة على أنها تتجاوز الهدف وتتوقف عن دفع الرسوم لأسفل وتسمح لها بالزيادة بشكل طبيعي. نتيجة لذلك: - يتفاعل سوق رسم البلوب دائمًا مع الازدحام - تدفع شبكات طبقة 2 (L2) على الأقل شريحة ذات مغزى من الحوسبة التي تفرضها على العقد - لم يعد بإمكان الارتفاعات المفاجئة في الرسم الأساسي على طبقة التنفيذ (EL) أن تجعل رسم البلوب عالقًا عند 1 Wei **الموارد**: - [المواصفات الفنية لـ EIP-7918](https://eips.ethereum.org/EIPS/eip-7918) - [شرح Storybook](https://notes.ethereum.org/@anderselowsson/AIG) ### توسيع طبقة 1 (L1) {#scale-l1} #### انتهاء صلاحية السجل وإيصالات أبسط {#history-expiry} في يوليو 2025، [بدأ عملاء طبقة التنفيذ في إيثيريوم في دعم انتهاء صلاحية السجل الجزئي](https://blog.ethereum.org/2025/07/08/partial-history-exp). أدى هذا إلى إسقاط السجل الأقدم من [الدمج](https://ethereum.org/roadmap/merge/) من أجل تقليل مساحة القرص التي يطلبها مشغلو العقد مع استمرار نمو إيثيريوم. يوجد مقترح تحسين إيثيريوم (EIP) هذا في قسم منفصل عن "مقترحات تحسين إيثيريوم الأساسية" لأن التفرع لا ينفذ أي تغييرات في الواقع - إنه إشعار بأن فرق العملاء يجب أن تدعم انتهاء صلاحية السجل بحلول ترقية فوساكا. عمليًا، يمكن للعملاء تنفيذ ذلك في أي وقت ولكن إضافته إلى الترقية يضعه بشكل ملموس في قائمة المهام الخاصة بهم ومكنهم من اختبار تغييرات فوساكا بالتزامن مع هذه الميزة. **الموارد**: [المواصفات الفنية لـ EIP-7642](https://eips.ethereum.org/EIPS/eip-7642) #### تعيين حدود عليا لـ MODEXP {#set-upper-bounds-for-modexp} حتى الآن، كان العقد المجمع مسبقًا MODEXP يقبل أرقامًا بأي حجم تقريبًا. جعل ذلك من الصعب اختباره، وسهل إساءة استخدامه، ومحفوفًا بالمخاطر بالنسبة لاستقرار العميل. يضع EIP-7823 حدًا واضحًا: يمكن أن يكون طول كل رقم إدخال على الأكثر 8192 بت (1024 بايت). يتم رفض أي شيء أكبر، ويتم حرق غاز المعاملة، ولا تحدث أي تغييرات في الحالة. إنه يغطي احتياجات العالم الحقيقي بشكل مريح للغاية مع إزالة الحالات القصوى التي عقدت تخطيط حد الغاز والمراجعات الأمنية. يوفر هذا التغيير مزيدًا من الأمان والحماية من هجمات الحرمان من الخدمة (DoS) دون التأثير على تجربة المستخدم أو المطور. **الموارد**: [المواصفات الفنية لـ EIP-7823](https://eips.ethereum.org/EIPS/eip-7823) #### سقف حد الغاز للمعاملة {#transaction-gas-limit-cap} يضيف EIP-[7825](https://eips.ethereum.org/EIPS/eip-7825) سقفًا قدره 16,777,216 (2^24) غاز لكل معاملة. إنه تعزيز استباقي ضد هجمات الحرمان من الخدمة (DoS) من خلال تقييد تكلفة أسوأ حالة لأي معاملة فردية بينما نرفع حد الغاز للكتلة. إنه يجعل من السهل نمذجة التحقق من الصحة والنشر للسماح لنا بمعالجة التوسع عبر رفع حد الغاز. لماذا 2^24 غاز بالضبط؟ إنه أصغر بشكل مريح من حد الغاز اليوم، وهو كبير بما يكفي لعمليات نشر العقود الحقيقية والعقود المجمعة مسبقًا الثقيلة، وكونه من مضاعفات الرقم 2 يجعله سهل التنفيذ عبر العملاء. يشبه هذا الحد الأقصى الجديد لحجم المعاملة متوسط حجم الكتلة قبل بيكترا، مما يجعله حدًا معقولًا لأي عملية على إيثيريوم. **الموارد**: [المواصفات الفنية لـ EIP-7825](https://eips.ethereum.org/EIPS/eip-7825) #### زيادة تكلفة غاز `MODEXP` {#modexp-gas-cost-increase} MODEXP هو دالة مدمجة كعقد مجمع مسبقًا تحسب الأسس المعيارية، وهو نوع من رياضيات الأرقام الكبيرة المستخدمة في التحقق من توقيع RSA وأنظمة الإثبات. يسمح للعقود بتشغيل هذه الحسابات مباشرة دون الحاجة إلى تنفيذها بأنفسهم. حدد المطورون وفرق العملاء MODEXP كعقبة رئيسية أمام زيادة حد الغاز للكتلة لأن تسعير الغاز الحالي غالبًا ما يقلل من تقدير مقدار قوة الحوسبة التي تتطلبها مدخلات معينة. هذا يعني أن معاملة واحدة تستخدم MODEXP يمكن أن تستغرق معظم الوقت اللازم لمعالجة كتلة كاملة، مما يؤدي إلى إبطاء الشبكة. يغير مقترح تحسين إيثيريوم (EIP) هذا التسعير ليتناسب مع التكاليف الحسابية الحقيقية عن طريق: - رفع الحد الأدنى للرسوم من 200 إلى 500 غاز وإزالة خصم الثلث من EIP-2565 على حساب التكلفة العامة - زيادة التكلفة بشكل أكثر حدة عندما يكون إدخال الأس طويلًا جدًا. إذا كان الأس (رقم "القوة" الذي تمرره كوسيطة ثانية) أطول من 32 بايت / 256 بت، فإن رسوم الغاز ترتفع بشكل أسرع بكثير لكل بايت إضافي - فرض رسوم إضافية على الأساس الكبير أو المعامل أيضًا. يُفترض أن يكون الرقمان الآخران (الأساس والمعامل) على الأقل 32 بايت - إذا كان أي منهما أكبر، ترتفع التكلفة بما يتناسب مع حجمه من خلال مطابقة التكاليف بشكل أفضل مع وقت المعالجة الفعلي، لم يعد بإمكان MODEXP التسبب في استغراق الكتلة وقتًا طويلاً للتحقق من صحتها. هذا التغيير هو واحد من عدة تغييرات تهدف إلى جعل زيادة حد الغاز لكتلة إيثيريوم آمنًا في المستقبل. **الموارد**: [المواصفات الفنية لـ EIP-7883](https://eips.ethereum.org/EIPS/eip-7883) #### حد حجم كتلة التنفيذ المشفرة بـ RLP {#rlp-execution-block-size-limit} يخلق هذا سقفًا لمدى الحجم المسموح به للكتلة - هذا حد لما يتم _إرساله_ عبر الشبكة وهو منفصل عن حد الغاز، والذي يحد من _العمل_ داخل الكتلة. يبلغ الحد الأقصى لحجم الكتلة 10 MiB، مع سماحية صغيرة (2 MiB) مخصصة لبيانات الإجماع بحيث يتناسب كل شيء وينتشر بشكل نظيف. إذا ظهرت كتلة أكبر من ذلك، يرفضها العملاء. هذا ضروري لأن الكتل الكبيرة جدًا تستغرق وقتًا أطول للانتشار والتحقق عبر الشبكة ويمكن أن تخلق مشكلات في الإجماع أو يتم إساءة استخدامها كمتجه لهجوم الحرمان من الخدمة (DoS). أيضًا، لن تقوم بروتوكولات النشر (gossip) في طبقة الإجماع بالفعل بإعادة توجيه الكتل التي تزيد عن حوالي 10 MiB، لذا فإن مواءمة طبقة التنفيذ مع هذا الحد يتجنب المواقف الغريبة المتمثلة في "رآها البعض، وأسقطها البعض الآخر". التفاصيل الدقيقة: هذا سقف لحجم كتلة التنفيذ المشفرة بـ [RLP](/developers/docs/data-structures-and-encoding/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](https://eips.ethereum.org/EIPS/eip-7934) #### تعيين حد الغاز الافتراضي إلى 60 مليون {#set-default-gas-limit-to-60-million} قبل رفع حد الغاز من 30M إلى 36M في فبراير 2025 (وبعد ذلك إلى 45M)، لم تتغير هذه القيمة منذ الدمج (سبتمبر 2022). يهدف مقترح تحسين إيثيريوم (EIP) هذا إلى جعل التوسع المستمر أولوية. ينسق EIP-7935 فرق عملاء طبقة التنفيذ (EL) لرفع حد الغاز الافتراضي فوق 45M الحالية لفوساكا. إنه مقترح تحسين إيثيريوم (EIP) إعلامي، ولكنه يطلب صراحة من العملاء اختبار حدود أعلى على شبكات التطوير، والتقارب حول قيمة آمنة، وشحن هذا الرقم في إصدارات فوساكا الخاصة بهم. يستهدف تخطيط شبكة التطوير ضغطًا يبلغ حوالي 60M (كتل كاملة مع حمل اصطناعي) وزيادات متكررة؛ تقول الأبحاث أن أمراض حجم الكتلة في أسوأ الحالات لا ينبغي أن ترتبط بأقل من حوالي 150M. يجب إقران الطرح بسقف حد الغاز للمعاملة (EIP-7825) بحيث لا يمكن لمعاملة واحدة أن تهيمن مع ارتفاع الحدود. **الموارد**: [المواصفات الفنية لـ EIP-7935](https://eips.ethereum.org/EIPS/eip-7935) ### تحسين تجربة المستخدم (UX) {#improve-ux} #### النظرة المستقبلية الحتمية للمُقترِح {#deterministic-proposer-lookahead} مع EIP-7917، ستصبح سلسلة المنارة على دراية بمُقترِحي الكتل القادمين للحقبة التالية. إن وجود رؤية حتمية حول المُدَقِّقين الذين سيقترحون الكتل المستقبلية يمكن أن يتيح [التأكيدات المسبقة](https://ethresear.ch/t/based-preconfirmations/17353) - وهو التزام مع المُقترِح القادم يضمن تضمين معاملة المستخدم في كتلته دون انتظار الكتلة الفعلية. تفيد هذه الميزة تطبيقات العملاء وأمان الشبكة لأنها تمنع الحالات القصوى حيث يمكن للمُدَقِّقين التلاعب بجدول المُقترِح. تسمح النظرة المستقبلية أيضًا بتقليل تعقيد التنفيذ. **الموارد**: [المواصفات الفنية لـ EIP-7917](https://eips.ethereum.org/EIPS/eip-7917) #### رمز التشغيل لعد الأصفار البادئة (CLZ) {#count-leading-zeros-opcode} تضيف هذه الميزة تعليمة صغيرة لآلة إيثيريوم الافتراضية (EVM)، وهي **عد الأصفار البادئة (CLZ)**. يتم تمثيل كل شيء تقريبًا في آلة إيثيريوم الافتراضية (EVM) كقيمة 256 بت - يُرجع رمز التشغيل الجديد هذا عدد بتات الصفر الموجودة في المقدمة. هذه ميزة شائعة في العديد من بنيات مجموعة التعليمات لأنها تتيح عمليات حسابية أكثر كفاءة. من الناحية العملية، يؤدي هذا إلى طي عمليات مسح البتات اليدوية اليوم في خطوة واحدة، لذا فإن العثور على أول بت محدد، أو مسح البايتات، أو تحليل حقول البتات يصبح أبسط وأرخص. رمز التشغيل منخفض التكلفة وثابت التكلفة وقد تم قياسه ليكون على قدم المساواة مع الإضافة الأساسية، مما يقلص رمز البايت ويوفر الغاز لنفس العمل. **الموارد**: [المواصفات الفنية لـ EIP-7939](https://eips.ethereum.org/EIPS/eip-7939) #### عقد مجمع مسبقًا لدعم منحنى secp256r1 {#secp256r1-precompile} يقدم مدقق توقيع secp256r1 (P-256) مدمجًا بأسلوب مفتاح مرور في العنوان الثابت `0x100` باستخدام نفس تنسيق الاستدعاء الذي اعتمدته بالفعل العديد من شبكات طبقة 2 (L2) وإصلاح الحالات القصوى، بحيث تعمل العقود المكتوبة لتلك البيئات على طبقة 1 (L1) دون تغييرات. ترقية لتجربة المستخدم! بالنسبة للمستخدمين، يفتح هذا التوقيع الأصلي للجهاز ومفاتيح المرور. يمكن للمحافظ الاستفادة من Apple Secure Enclave و مخزن المفاتيح في Android ووحدات أمان الأجهزة (HSMs) و FIDO2/WebAuthn مباشرة - لا توجد عبارة الاسترداد، وتهيئة أكثر سلاسة، وتدفقات متعددة العوامل تبدو وكأنها تطبيقات حديثة. يؤدي هذا إلى تجربة مستخدم أفضل، واسترداد أسهل، وأنماط تجريد الحساب التي تتطابق مع ما تفعله مليارات الأجهزة بالفعل. بالنسبة للمطورين، فإنه يأخذ إدخالاً بحجم 160 بايت ويعيد إخراجًا بحجم 32 بايت، مما يجعل من السهل نقل المكتبات الحالية وعقود طبقة 2 (L2). داخليًا، يتضمن فحوصات النقطة عند اللانهاية والمقارنة المعيارية للقضاء على الحالات القصوى الصعبة دون كسر المتصلين الصالحين. **الموارد**: - [المواصفات الفنية لـ EIP-7951](https://eips.ethereum.org/EIPS/eip-7951) - [المزيد حول RIP-7212](https://www.alchemy.com/blog/what-is-rip-7212) _(لاحظ أن EIP-7951 حل محل RIP-7212)_ ### ميتا (Meta) {#meta} #### طريقة `eth_config` في JSON-RPC {#eth-config} هذا استدعاء JSON-RPC يسمح لك بسؤال عقدتك عن إعدادات التفرع التي تقوم بتشغيلها. يُرجع ثلاث لقطات: `current` و `next` و `last` بحيث يمكن للمُدَقِّقين وأدوات المراقبة التحقق من أن العملاء مصطفون لتفرع قادم. من الناحية العملية، هذا لمعالجة قصور تم اكتشافه عندما تم إطلاق تفرع بيكترا على شبكة اختبار هوليسكي في أوائل عام 2025 مع تكوينات خاطئة طفيفة أدت إلى حالة عدم نهائية. يساعد هذا فرق الاختبار والمطورين على ضمان أن التفرعات الرئيسية ستتصرف كما هو متوقع عند الانتقال من شبكات التطوير إلى شبكات الاختبار، ومن شبكات الاختبار إلى الشبكة الرئيسية. تتضمن اللقطات: `chainId` و `forkId` ووقت تفعيل التفرع المخطط له، والعقود المجمعة مسبقًا النشطة، وعناوين العقود المجمعة مسبقًا، وتبعيات عقد النظام، وجدول كتل البيانات (البلوب) للتفرع. يوجد مقترح تحسين إيثيريوم (EIP) هذا في قسم منفصل عن "مقترحات تحسين إيثيريوم الأساسية" لأن التفرع لا ينفذ أي تغييرات في الواقع - إنه إشعار بأن فرق العملاء يجب أن تنفذ طريقة JSON-RPC هذه بحلول ترقية فوساكا. **الموارد**: [المواصفات الفنية لـ EIP-7910](https://eips.ethereum.org/EIPS/eip-7910) ## الأسئلة الشائعة {#faq} ### هل تؤثر هذه الترقية على جميع عقد ومُدَقِّقي إيثيريوم؟ {#does-this-upgrade-affect-all-ethereum-nodes-and-validators} نعم، تتطلب ترقية فوساكا تحديثات لكل من [عملاء التنفيذ وعملاء الإجماع](/developers/docs/nodes-and-clients/). سيصدر جميع عملاء إيثيريوم الرئيسيين إصدارات تدعم التفرع الصلب مميزة كأولوية عالية. يمكنك متابعة موعد توفر هذه الإصدارات في مستودعات GitHub الخاصة بالعملاء، أو [قنوات ديسكورد](https://ethstaker.org/support) الخاصة بهم، أو [ديسكورد EthStaker](https://dsc.gg/ethstaker)، أو عن طريق الاشتراك في مدونة إيثيريوم للحصول على تحديثات البروتوكول. للحفاظ على المزامنة مع شبكة إيثيريوم بعد الترقية، يجب على مشغلي العقد التأكد من أنهم يقومون بتشغيل إصدار عميل مدعوم. لاحظ أن المعلومات حول إصدارات العملاء حساسة للوقت، ويجب على المستخدمين الرجوع إلى أحدث التحديثات للحصول على أحدث التفاصيل. ### كيف يمكن تحويل ETH بعد التفرع الصلب؟ {#how-can-eth-be-converted-after-the-hardfork} - **لا يلزم اتخاذ أي إجراء بشأن ETH الخاص بك**: بعد ترقية فوساكا لشبكة إيثيريوم، ليست هناك حاجة لتحويل أو ترقية ETH الخاص بك. ستظل أرصدة حسابك كما هي، وسيظل ETH الذي تحتفظ به حاليًا متاحًا بشكله الحالي بعد التفرع الصلب. - **احذر من عمليات الاحتيال!** **أي شخص يطلب منك "ترقية" ETH الخاص بك يحاول الاحتيال عليك.** لا يوجد شيء تحتاج إلى القيام به فيما يتعلق بهذه الترقية. ستبقى أصولك غير متأثرة تمامًا. تذكر أن البقاء على اطلاع هو أفضل دفاع ضد عمليات الاحتيال. [المزيد حول التعرف على عمليات الاحتيال وتجنبها](/security/) ### ما قصة الحمر الوحشية؟ {#whats-with-the-zebras} الحمار الوحشي هو "التميمة" التي اختارها المطورون لفوساكا لأن خطوطه تعكس أخذ عينات توفر البيانات (DAS) القائمة على الأعمدة في PeerDAS، حيث تحتفظ العقد بشبكات فرعية معينة للأعمدة وتأخذ عينات من بضعة أعمدة أخرى من خانة كل نظير للتحقق من توفر بيانات البلوب. استخدم الدمج في عام 2022 [باندا](https://x.com/hwwonx/status/1431970802040127498) كتميمة له للإشارة إلى انضمام طبقتي التنفيذ والإجماع. منذ ذلك الحين، تم اختيار التمائم بشكل غير رسمي لكل تفرع وتظهر كفن ASCII في سجلات العميل في وقت الترقية. إنها مجرد طريقة ممتعة للاحتفال. ### ما هي التحسينات المضمنة لتوسيع طبقة 2 (L2)؟ {#what-improvements-are-included-for-l2-scaling} [PeerDAS](/roadmap/fusaka/peerdas) هو الميزة الرئيسية للتفرع. إنه ينفذ أخذ عينات توفر البيانات (DAS) الذي يفتح المزيد من قابلية التوسع للتجميعات، مما يؤدي نظريًا إلى توسيع مساحة البلوب حتى 8 أضعاف الحجم الحالي. سيتم أيضًا تحسين سوق رسم البلوب للتفاعل بكفاءة مع الازدحام وضمان دفع شبكات طبقة 2 (L2) رسومًا ذات مغزى للحوسبة والمساحة التي تفرضها كتل البيانات على العقد. ### كيف تختلف تفرعات BPO؟ {#how-are-bpo-forks-different} توفر تفرعات معلمات البلوب فقط آلية لزيادة عدد كتل البيانات باستمرار (الهدف والحد الأقصى) بعد تفعيل PeerDAS، دون الحاجة إلى الانتظار لترقية منسقة كاملة. يتم ترميز كل زيادة بشكل ثابت ليتم تكوينها مسبقًا في إصدارات العملاء التي تدعم فوساكا. كمستخدم أو مُدَقِّق، لا تحتاج إلى تحديث عملائك لكل BPO وتأكد فقط من متابعة التفرعات الصلبة الرئيسية مثل فوساكا. هذه هي نفس الممارسة كما كان من قبل، ولا توجد إجراءات خاصة مطلوبة. لا يزال يوصى بمراقبة عملائك حول الترقيات و BPOs وإبقائهم محدثين حتى بين الإصدارات الرئيسية حيث قد تتبع الإصلاحات أو التحسينات التفرع الصلب. ### ما هو جدول BPO؟ {#what-is-the-bpo-schedule} سيتم تحديد الجدول الزمني الدقيق لتحديثات BPO مع إصدارات فوساكا. اتبع [إعلانات البروتوكول](https://blog.ethereum.org/category/protocol) وملاحظات الإصدار لعملائك. مثال على كيف قد يبدو الأمر: - قبل فوساكا: الهدف 6، الحد الأقصى 9 - عند تفعيل فوساكا: الهدف 6، الحد الأقصى 9 - BPO1، بعد أسابيع قليلة من تفعيل فوساكا: الهدف 10، الحد الأقصى 15، بزيادة قدرها الثلثين - BPO2، بعد أسابيع قليلة من BPO1: الهدف 14، الحد الأقصى 21 ### هل سيؤدي هذا إلى خفض الرسوم على إيثيريوم (طبقة 1) {#will-this-lower-gas} لا تؤدي هذه الترقية إلى خفض رسوم الغاز على طبقة 1 (L1)، على الأقل ليس بشكل مباشر. التركيز الرئيسي هو توفير مساحة بلوب أكبر لبيانات التجميع، وبالتالي خفض الرسوم على طبقة 2 (L2). قد يكون لهذا بعض الآثار الجانبية على سوق رسوم طبقة 1 (L1) ولكن لا يُتوقع حدوث تغيير كبير. ### بصفتي مخزنًا (staker)، ماذا أحتاج أن أفعل من أجل الترقية؟ {#as-a-staker-what-do-i-need-to-do-for-the-upgrade} كما هو الحال مع كل ترقية للشبكة، تأكد من تحديث عملائك إلى أحدث الإصدارات المميزة بدعم فوساكا. اتبع التحديثات في القائمة البريدية و[إعلانات البروتوكول على مدونة مؤسسة إيثيريوم (EF)](https://blog.ethereum.org/category/protocol) للحصول على معلومات حول الإصدارات. للتحقق من إعدادك قبل تفعيل فوساكا على الشبكة الرئيسية، يمكنك تشغيل مُدَقِّق على شبكات الاختبار. يتم [تفعيل فوساكا في وقت أقرب على شبكات الاختبار](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement) مما يمنحك مساحة أكبر للتأكد من أن كل شيء يعمل والإبلاغ عن الأخطاء. يتم الإعلان عن تفرعات شبكة الاختبار أيضًا في القائمة البريدية والمدونة. ### هل تؤثر "النظرة المستقبلية الحتمية للمُقترِح" (EIP-7917) على المُدَقِّقين؟ {#does-7917-affect-validators} لا يغير هذا التغيير كيفية عمل عميل المُدَقِّق الخاص بك، ومع ذلك، فإنه سيوفر مزيدًا من التبصر في مستقبل واجبات المُدَقِّق الخاصة بك. تأكد من تحديث أدوات المراقبة الخاصة بك لمواكبة الميزات الجديدة. ### كيف تؤثر فوساكا على متطلبات عرض النطاق الترددي للعقد والمُدَقِّقين؟ {#how-does-fusaka-affect-bandwidth-requirements-for-nodes-and-validators} يُحدث PeerDAS تغييرًا كبيرًا في كيفية نقل العقد لبيانات البلوب. يتم تقسيم جميع البيانات إلى أجزاء تسمى أعمدة عبر 128 شبكة فرعية مع اشتراك العقد في بعضها فقط. يعتمد مقدار أعمدة الشبكة الفرعية التي يجب على العقد الاحتفاظ بها على تكوينها وعدد المُدَقِّقين المتصلين. ستعتمد متطلبات عرض النطاق الترددي الفعلية على كمية كتل البيانات المسموح بها في الشبكة ونوع العقدة. في لحظة تفعيل فوساكا، يظل هدف البلوب كما كان من قبل، ولكن مع PeerDAS، يمكن لمشغلي العقد رؤية انخفاض في استخدام القرص لكتل البيانات وحركة مرور الشبكة. نظرًا لأن BPOs تقوم بتكوين أعداد أكبر من كتل البيانات في الشبكة، سيزداد عرض النطاق الترددي اللازم مع كل BPO. لا تزال متطلبات العقد ضمن [الهوامش الموصى بها](https://eips.ethereum.org/EIPS/eip-7870) حتى بعد BPOs الخاصة بفوساكا. #### العقد الكاملة {#full-nodes} ستشترك العقد العادية التي لا تحتوي على أي مُدَقِّقين في 4 شبكات فرعية فقط، مما يوفر الحفظ لـ 1/8 من البيانات الأصلية. هذا يعني أنه مع نفس المقدار من بيانات البلوب، سيكون عرض النطاق الترددي للعقدة لتنزيلها أصغر بمعامل ثمانية (8). قد ينخفض استخدام القرص وعرض النطاق الترددي لتنزيل كتل البيانات لعقدة كاملة عادية بحوالي 80%، إلى بضعة ميغابايت فقط. #### المخزنون الفرديون {#solo-stakers} إذا تم استخدام العقدة لعميل مُدَقِّق، فيجب عليها الاحتفاظ بمزيد من الأعمدة وبالتالي معالجة المزيد من البيانات. مع إضافة مُدَقِّق، تشترك العقدة في ما لا يقل عن 8 شبكات فرعية للأعمدة وبالتالي تعالج ضعف كمية البيانات التي تعالجها العقدة العادية ولكنها لا تزال أقل مما كانت عليه قبل فوساكا. إذا كان رصيد المُدَقِّق أعلى من 287 ETH، فسيتم الاشتراك في المزيد والمزيد من الشبكات الفرعية. بالنسبة للمخزن الفردي، هذا يعني أن استخدام القرص وعرض النطاق الترددي للتنزيل سينخفض بحوالي 50%. ومع ذلك، لبناء الكتل محليًا وتحميل جميع كتل البيانات إلى الشبكة، هناك حاجة إلى المزيد من عرض النطاق الترددي للتحميل. سيحتاج البناة المحليون إلى عرض نطاق ترددي للتحميل أعلى بـ 2-3 مرات من ذي قبل في وقت فوساكا ومع هدف BPO2 البالغ 15/21 كتلة بيانات، يجب أن يكون عرض النطاق الترددي النهائي اللازم للتحميل أعلى بحوالي 5 مرات، عند 100Mpbs. #### المُدَقِّقون الكبار {#large-validators} ينمو عدد الشبكات الفرعية المشتركة مع إضافة المزيد من الرصيد والمُدَقِّقين إلى العقدة. على سبيل المثال، عند رصيد يبلغ حوالي 800 ETH، تحتفظ العقدة بـ 25 عمودًا وستحتاج إلى عرض نطاق ترددي للتنزيل أكثر بنسبة 30% تقريبًا من ذي قبل. يرتفع التحميل الضروري بشكل مشابه للعقد العادية ويلزم ما لا يقل عن 100Mbps. عند 4096 ETH، و 2 من المُدَقِّقين ذوي الحد الأقصى للرصيد، تصبح العقدة "عقدة فائقة" تحتفظ بجميع الأعمدة، وبالتالي تقوم بتنزيل وتخزين كل شيء. تعمل هذه العقد بنشاط على معالجة الشبكة من خلال المساهمة في إعادة البيانات المفقودة ولكنها تتطلب أيضًا عرض نطاق ترددي وتخزينًا أكبر بكثير. مع كون هدف البلوب النهائي أعلى بـ 6 مرات من ذي قبل، سيتعين على العقد الفائقة تخزين حوالي 600GB من بيانات البلوب الإضافية والحصول على عرض نطاق ترددي أسرع ومستدام للتنزيل عند حوالي 20Mbps. [اقرأ المزيد من التفاصيل حول المتطلبات المتوقعة.](https://ethpandaops.io/posts/fusaka-bandwidth-estimation/#theoretical-requirements) ### ما هي تغييرات آلة إيثيريوم الافتراضية (EVM) التي تم تنفيذها؟ {#what-evm-changes-are-implemented} تعزز فوساكا آلة إيثيريوم الافتراضية (EVM) بتغييرات وميزات ثانوية جديدة. - من أجل الأمان أثناء التوسع، سيتم [تحديد الحد الأقصى لحجم المعاملة الواحدة بـ 16.7 مليون](https://eips.ethereum.org/EIPS/eip-7825) وحدة غاز. - تمت إضافة [رمز التشغيل الجديد لعد الأصفار البادئة (CLZ)](https://eips.ethereum.org/EIPS/eip-7939) إلى آلة إيثيريوم الافتراضية (EVM) وسيمكن لغات العقود الذكية من أداء عمليات معينة بكفاءة أكبر. - [ستتم زيادة تكلفة العقد المجمع مسبقًا `ModExp`](https://eips.ethereum.org/EIPS/eip-7883)—ستفرض العقود التي تستخدمه رسوم غاز أكبر للتنفيذ. ### كيف يؤثر حد الغاز الجديد البالغ 16M على مطوري العقود؟ {#how-does-new-16m-gas-limit-affects-contract-developers} تقدم فوساكا حدًا [للحد الأقصى لحجم المعاملة الواحدة إلى 16.7 مليون](https://eips.ethereum.org/EIPS/eip-7825) (2^24) وحدة غاز. هذا هو تقريبًا الحجم السابق للكتلة المتوسطة مما يجعلها كبيرة بما يكفي لاستيعاب المعاملات المعقدة التي من شأنها أن تستهلك كتلة كاملة. يخلق هذا الحد حماية للعملاء، ويمنع هجمات الحرمان من الخدمة (DoS) المحتملة في المستقبل مع حد غاز أعلى للكتلة. الهدف من التوسع هو تمكين المزيد من المعاملات من الدخول إلى سلسلة الكتل دون أن تستهلك معاملة واحدة الكتلة بأكملها. معاملات المستخدم العادية بعيدة كل البعد عن الوصول إلى هذا الحد. قد تتأثر بعض الحالات القصوى مثل عمليات التمويل اللامركزي (DeFi) الكبيرة والمعقدة، أو عمليات نشر العقود الذكية الكبيرة أو المعاملات المجمعة التي تستهدف عقودًا متعددة بهذا التغيير. سيتعين تقسيم هذه المعاملات إلى معاملات أصغر أو تحسينها بطريقة أخرى. استخدم المحاكاة قبل إرسال المعاملات التي قد تصل إلى الحد. طريقة RPC `eth_call` غير محدودة وستسمح بمحاكاة معاملات أكبر من الحد الفعلي لسلسلة الكتل. يمكن تكوين الحد الفعلي لطرق RPC بواسطة مشغل العميل لضمان منع إساءة الاستخدام. ### ماذا يعني CLZ للمطورين؟ {#what-clz-means-for-developers} ستقوم مترجمات آلة إيثيريوم الافتراضية (EVM) مثل Solidity بتنفيذ واستخدام الوظيفة الجديدة لعد الأصفار داخليًا. قد تستفيد العقود الجديدة من وفورات الغاز إذا كانت تعتمد على هذا النوع من العمليات. اتبع الإصدارات وإعلانات الميزات للغة العقد الذكي للحصول على وثائق حول الوفورات المحتملة. ### هل هناك أي تغييرات على عقودي الذكية الحالية؟ {#what-clz-means-for-developers-2} ليس لفوساكا أي تأثير مباشر من شأنه أن يكسر أي عقود حالية أو يغير سلوكها. يتم إجراء التغييرات التي تم إدخالها على طبقة التنفيذ مع التوافق مع الإصدارات السابقة، ومع ذلك، راقب دائمًا الحالات القصوى والتأثير المحتمل. [مع زيادة تكلفة العقد المجمع مسبقًا `ModExp`](https://eips.ethereum.org/EIPS/eip-7883)، ستستهلك العقود التي تعتمد عليه المزيد من الغاز للتنفيذ. إذا كان عقدك يعتمد بشكل كبير على هذا ويصبح أكثر تكلفة للمستخدمين، فأعد النظر في كيفية استخدامه. ضع في اعتبارك [الحد الجديد البالغ 16.7 مليون](https://eips.ethereum.org/EIPS/eip-7825) إذا كانت المعاملات التي تنفذ عقودك قد تصل إلى حجم مماثل. ## قراءة إضافية {#further-reading} - [خارطة طريق إيثيريوم](/roadmap/) - [Forkcast: فوساكا](https://forkcast.org/upgrade/fusaka) - [مقترح تحسين إيثيريوم (EIP) الميتا لفوساكا](https://eips.ethereum.org/EIPS/eip-7607) - [إعلان مدونة شبكة اختبار فوساكا](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement) - [Bankless: ما ستجلبه فوساكا وبيكترا إلى إيثيريوم](https://www.bankless.com/read/what-fusaka-pectra-will-bring-ethereum) - [Bankless: ترقيات إيثيريوم القادمة: فوساكا وغلامستردام وما بعدها مع بريستون فان لون](https://x.com/BanklessHQ/status/1956017743289020633?t=502) - [ملفات فوساكا](https://www.youtube.com/playlist?list=PL4cwHXAawZxpz-erUbKKUnnGoQNdF8s7Z) - [شرح PEEPanEIPs](https://www.youtube.com/playlist?list=PL4cwHXAawZxoIenfk7OJry4rxcqX-eqBt)