أعلنت مؤسسة إيثريوم مؤخرًا فتح شبكة اختبار عامة Platåberget، بهدف إجراء تدريب مبكر على الترقية الكبرى القادمة في المرحلة التالية Glamsterdam (Gloas + Amsterdam).
هذه المرة ليست مجرد «شبكة اختبار أخرى»؛ إذ إن القواعد الأساسية ستتغير في أماكن كثيرة، مثل: • Proposer-Builder Separation المدمجة داخل البروتوكول (ePBS) • قائمة الوصول على مستوى الكتلة (BAL) • إعادة تسعير الـ Gas، وإضافة بُعد للفوترة حسب «بايت الحالة»
بالنسبة للمستخدمين العاديين، أوضح نقطة مباشرة: لم يعد بالإمكان الاعتماد على التجربة السابقة بأن «تحويل ETH عادي بشكل افتراضي = 21000 gas». فعند التحويل إلى عنوان جديد لم تُستخدم من قبل، لأن إنشاء الحساب سيستلزم دفع تكلفة إضافية مرتبطة بالحالة. وقد تؤدي المحافظ ومحركات الفهرسة وأدوات تقدير الـ gas إذا كانت ما زالت مكتوبة على افتراضات قديمة إلى حسابات غير صحيحة.
كما نبهت المؤسسة أيضًا: يجب تحديث الأدوات التي تعتمد على حدّ أقصى ثابت للـ gas. يمكن للمطورين تجربة ذلك أولًا على Platåberget، ثم اتباع إيقاع الشبكة الاختبارية الطويلة الأمد والشبكة الرئيسية لاحقًا.
الترقية الكبرى القادمة في عالم الإيثيريوم Glamsterdam: تغيّر ملموس وواقعي—لن يصبح التحويل إلى ETH دائمًا بسقف غاز ثابت قدره 21000.
بحسب ما ورد من مؤسسة الإيثيريوم: عند التحويل إلى عنوان موجود بالفعل يبقى ذلك قريبًا من 21000؛ أما التحويل إلى عنوان جديد لم يُطرح على السلسلة من قبل فسيؤدي إلى دفع غاز إضافي خاصّ بـ state (لأن الشبكة ستنشئ الحساب وتخزن حالة الحساب إلى الأبد). إذا كانت المحافظ أو المتصفحات أو حاسبات تقدير الغاز ما تزال تعتبر 21000 كحدٍّ أعلى “نهائي”، فقد تفشل عملية تقدير الرسوم أو تُرفض المعاملة بعد الإطلاق على الشبكة الرئيسية.
قامت EF بفتح شبكة اختبار عامة Plataberget، لتسهيل تجربة الأخطاء مبكرًا بالنسبة للمحافظ و dApps. كما تتضمن الترقية ePBS وBlock-level Access Lists ورفع الحد الأعلى لحجم العقود وغيرها. حاليًا ما زالت الترقية في مرحلة الاختبار/التدعيم، لذا لا يحتاج المستخدمون العاديون إلى القيام بأي إجراء هذا الأسبوع؛ الأهم أن يقوم المطورون والبنية التحتية بالمزامنة.
الترقية الكبيرة التالية على الإيثيريوم Glamsterdam: هناك تفصيلة قوية نوعًا ما—قواعد الخبرة القديمة المتعلقة بـ «معامل غاز ثابت قدره 21000 عند تحويل ETH عادي» ستتغير.
بحسب تقرير CoinDesk وشرح من مؤسسة الإيثيريوم: عند تحويل ETH إلى حسابات موجودة مسبقًا ما تزال هناك حاجة تقارب 21000 gas؛ لكن عند تحويل ETH إلى عنوان جديد لم يسبق له الظهور على السلسلة، فسيُحتسب بالإضافة إلى ذلك غاز إضافي خاص بـ state (يذكر التقرير أنه قرابة 18.36 ألف وحدة)—لأن الشبكة تحتاج إلى إنشاء حالة الحساب الجديدة والاحتفاظ بها على المدى الطويل. حجم العمل بين الحالتين أصلاً غير متساوٍ، لكن في السابق كانتا تُسعّران بنفس السعر.
لا داعي للهلع لدى المستخدمين العاديين، فالتغيير سيتحقق أولًا على شبكة الاختبار (مثل Platåberget). ما يحتاج إلى مواكبة فعلية هو المحافظ ومتصفحات الويب وأدوات تقدير رسوم المعاملات: إذا كان ما يزال يتم اعتبار 21000 كحد علوي وسفلي مُضمَّن (Hard-coded) فقد يؤدي ذلك إلى رفض المعاملة أو تسعير غير كافٍ.
على مستوى البروتوكول، بدأت الشبكة تعطي تسعيرًا أدق لـ «زيادة الحالة»، وهذا أقرب إلى القيود الحقيقية لهندسة العميل والمحفظة من مجرد الحديث عن TPS.
【ملاحظات البروتوكول】الترقية القادمة لِإيثيريوم قد تُغيّر «21000 gas» الافتراضية في المحفظة
وفقًا لما جمعته CoinDesk (قبل نحو يوم واحد): في ترقية Glamsterdam المخططة، سيتم تفكيك افتراض طويل الأمد يتمثل في أن «أي تحويل عادي من ETH افتراضيًا هو 21000 gas» —
• التحويل إلى عنوان موجود مسبقًا: سيظل تقريبًا وفق نفس بنية 21000 • التحويل إلى عنوان جديد لم يُسجَّل على السلسلة من قبل: سيتعين أيضًا تحمل تكلفة إضافية لإنشاء الحساب/كتابة الحالة (gas الخاصة بالحالة)
كما أشارت مؤسسة إيثيريوم في بيانها بتاريخ 8/17 حول شبكة اختبار Platåberget: سيجري إعادة تسعير أشياء مثل إنشاء الحساب، ونشر الكود، وكتابة مخازن (storage slots) جديدة؛ وأي أدوات تقوم بتثبيت gas limit بشكل ثابت قد تتأثر.
بالنسبة للمحافظ و dApp، ليست النقطة الأساسية هي الدعوة إلى صعود/هبوط الأسعار، بل التكيّف الهندسي: 1) لم يعد يمكن كتابة تقدير الرسوم بشكل ثابت دائمًا على 21000 2) يجب إعادة حساب نموذج تكلفة عمليات الإطلاق (airdrop)/أول تحويل 3) على جانب المستخدم أن يكون قادرًا على شرح «لماذا هذه العملية أغلى»
يمكن الرجوع إلى مناقشات إعادة تسعير gas مثل EIP-8037 / EIP-2780 في الاتجاهات ذات الصلة. ما تزال الترقية قيد التطوير والتقدّم عبر الاختبارات، وتُحسم التفاصيل وفق التنفيذ النهائي للعميل.
الترقية التالية على الإيثيريوم Hegotá (الهدف قرابة 2027) تجمع الآن قائمة طلبات~
وفقًا لتقارير من CoinDesk وغيرها، لدى المطورين حاليًا حوالي 66 اقتراح EIP على الطاولة. وفي الجولات القادمة من core dev سيتم اختيار المقترحات التي يمكن تنفيذها ويمكن اختبارها، والتي لديها فرصة للانضمام في الوقت المحدد. ومن بين ما هو واضح نسبيًا أن يتم المضي فيه هو FOCIL (EIP-7805) باتجاه تعزيز مقاومة الرقابة.
ومن نقاط الاهتمام التقنية الأخرى Frame Transactions (EIP-8141) إلى جانب Keyed Nonces وRecent Roots. تتمحور نقاط النقاش حول توفير المزيد من «الأدوات على مستوى البروتوكول» لتطبيقات الخصوصية، وتقليل الاعتماد على الـ relayer الخارجي. وتجدر الإشارة إلى أنه يجب توضيح ذلك—التحويل العادي للـ ETH بحد ذاته لن يتحول إلى خصوصية على مستوى السلسلة بالكامل، وسيظل تأثير الإخفاء يعتمد بدرجة كبيرة على تصميم تطبيقات الطبقة العليا.
يمكن الرجوع إلى المستندات العامة على: eips.ethereum.org (EIP-7805 / 8141 وغيرها). أما ما الذي سيتم اعتماده نهائيًا فسيعتمد على تنفيذ العميل وتقدم testnet.
اليوم لدينا تحديث ذو طابع تقني صارم حول البنية التحتية: قامت World Chain (حل L2 على Ethereum مبنيًا على OP Stack) بتفعيل قوائم الوصول على مستوى الكتل (Block-Level Access Lists, BALs) الخاصة بـ EIP-7928 على الشبكة الرئيسية ضمن الجدول الزمني.
يمكن فهم النقاط التقنية على النحو التالي: 1) سابقًا كانت كثير من العملاء تحتاج إلى تنفيذ المعاملات ضمن كتلة بالتسلسل لفهم تبعيات الحالة 2) يتيح EIP-7928 للكتلة أن تسجل بشكل صريح أي الحسابات وأي الخانات التخزينية تم قراءتها/كتابتها في هذه الكتلة، ما يسهل القراءة من القرص بالتوازي والتحقق بالتوازي، ويمهد أيضًا لجولات لاحقة ذات إنتاجية أعلى 3) كما قامت World Chain بدمجه في flashblock؛ حيث يتم بث قائمة الوصول بشكل مستمر كل نحو 200 ملّي ثانية تقريبًا، ما يجعل عملية التحقق يمكن أن تتم أثناء خروج الكتل مع فحصها بالتوازي؛ وتذكر التقارير المنشورة أن الهدف هو رفع الإنتاجية دون رفع العتبة الصلبة لمتطلبات أجهزة المُتحققين (الأرقام التفصيلية تعتمد على المصادر الرسمية والقياسات الفعلية)
على جانب شبكة Ethereum الرئيسية، لا تزال EIP-7928 تسير عبر مسار المناقشات القياسي/مسار الترقية اللاحق (يربطها البعض من خارج الدائرة بخارطة Glamsterdam)؛ أما على مستوى L2 فيتم استخدامها عبر runtime flag أولًا، أي كأنها دورة تدريب هندسية مبكرة للنظام البيئي.
تحقق سريع من المشروع: المستودع العام worldcoin/world-chain هو Rust monorepo، ومفتوح المصدر بترخيص MIT، وخلال الأيام القليلة الماضية لا يزال هناك التزام مستمر وإصدارات/PRs متتالية (تشمل إصلاحات مرتبطة بـ proofs وflashblock)، وليست مجرد واجهة فارغة لأغراض الترويج.
【مُلخّص الأخبار】 بنك إنجلترا يطلق مختبر الجنيه الإسترليني الرقمي المرحلة الثانية: هل يمكن للـعملات المستقرة والـCBDC أن تنجزا التسوية جنبًا إلى جنب؟
وفقًا لما ورد في تقرير CoinDesk، دخل «مختبر الجنيه الإسترليني الرقمي» التابع لبنك إنجلترا (BOE) المرحلة الثانية، مع التركيز على اختبار ما إذا كانت العملات المستقرة العامة والعملة الرقمية الصادرة عن البنك المركزي (الجنيه الإسترليني الرقمي) يمكن أن تعمل بتكامل ضمن تدفّق دفع واحد لتسوية تمويل التجارة عبر الحدود.
تشمل الجهات المشاركة NOBO Finance وDun & Bradstreet وPolygon Labs. ومن بين السيناريوهات المتصوّرة: يمكن للمصدّر أولًا الحصول على تمويل لسلفة فواتير عبر العملة المستقرة، على أن يقوم المستورد في المملكة المتحدة في النهاية بإتمام التسوية باستخدام الجنيه الإسترليني الرقمي. وتوفّر جهة Polygon بنية تحتية مرتبطة بـOpen Money Stack لتسوية العملات المستقرة (تحويلات بالعملات الورقية، محافظ، عقود ذكية وغيرها)، كما تحاول دمج بيانات معاملات المحفظة مع معلومات الائتمان الخاصة بالشركات لتكوين «ملف ائتماني» قابل لإعادة الاستخدام للشركات الصغيرة والمتوسطة.
يجب توضيح الحدود: لا يتناول المختبر عملاء حقيقيين أو أموالًا حقيقية، ولا يعني أيضًا أن المملكة المتحدة قد قررت بالفعل إصدار الجنيه الإسترليني الرقمي. والمزيد منه هو تقييم كيف يمكن لأشكال مختلفة من العملات الرقمية أن تتكامل (قابلية التشغيل البيني)، وما إذا كان بإمكان ذلك تقليل احتكاكات التحقق والتسوية في تمويل التجارة للشركات الصغيرة والمتوسطة.
المصدر: CoinDesk https://www.coindesk.com/business/2026/08/12/bank-of-england-to-test-stablecoin-digital-currency-use-in-cross-border-finance مختبر بنك إنجلترا للجنيه الإسترليني الرقمي https://www.bankofengland.co.uk/the-digital-pound/lab
اطّلعت على سجل التغييرات الرسمي بتاريخ 13/8؛ محتواه تقني بحت ولا يتناول الأسعار:
1)يتم تقليص زمن الـ slot في شبكة الاختبار أكثر: توجد بوابة ميزات (feature gate) خفّضت من 350→300ms ومن 300→250ms، ويستعد العميل لإيقاع إنتاج كتل أقصر. 2)تكرار التحديثات بشكل متزامن عبر عدة عملاء: لدى Agave إصدار مستقر v4.2.x في الفترة الأخيرة، ويتم الدفع باتجاه v4.3؛ كما أن Firedancer / Frankendancer لديه إصدارات مقابلة. 3)تهيئة الطريق لـ Alpenglow: على سبيل المثال، أتمتة/موازاة التحقق من تصويت BLS لتقليل مخاطر أن “ذروة سيول التصويت” قد تُحمّل التحقق في العقد حتى الحد الأقصى.
كيف نفهم الخطّين هذين: • تقصير الـ slot ≈ زيادة وتيرة إنتاج الكتل (فتح تدريجي مع مراعاة استقرار الشبكة) • Alpenglow هو إعادة كبيرة في آلية الإجماع؛ وفي المصادر العلنية الشائعة تكون الأهداف تقليل “تأكيد الإجماع” من رتبة عشرات الثواني إلى حوالي 150ms—وقد يظل نافذة الشبكة الرئيسية قابلة للتعديل وفق ما يحدث في الاختبار
تدقيق على مستوى الكود: لدى Agave (anza-xyz/agave) خلال الأيام الأخيرة ما زالت هناك عمليات commit وتحديثات إصدار كثيفة، ما يعني استمرار العمل الهندسي الفعلي وليس سردًا شكليًا.
Solana كادت أن تفعّل عتبة التجميد: درس أساسيات للبنية التحتية، وليس منشورًا عن السوق.
بحسب CoinDesk و منصة الإقفال/التحقق Marinade: أدّى خلل في التوجيه (routing) لدى مزوّد مراكز بيانات كبير إلى فصل ما يقرب من 29% من SOL المُرهَن (المُقفل في الإقفال). تصميم Solana هو: إذا تجاوزت حوالي الثلث من أوزان التحقق (صحة/ثقل التوكين/الترجيح) التي تُسند للأجزاء الخارجة عن الخدمة، فلن يتمكن الشبكة من إتمام finality (التأكيد النهائي للمعاملة). وتقول Marinade إنه في ذلك الوقت كان المتبقي حتى هذه العتبة قرابة 20 مليون وحدة فقط من كمية الـ SOL المُرهَن.
ثمة نقاط تقنية جديرة بالتذكّر: 1) يشير مصدر العطل إلى مسار/توجيه خاطئ من مركز Teraswitch في ميامي، وتمت مراجعته/تأثيره على جزء من العقد في أوروبا وآسيا؛ أما أمريكا الشمالية فعلى الإجمال ظلت ضمن الخدمة. 2) يذكر التقرير أن مشغّل شبكة واحدًا (AS2032) كان يتحكم مؤقتًا بأكثر من ربع أوزان التحقق/الترجيح المُرهَن، وأن هذا المستوى من التركّز بحد ذاته يمثل منطقة خطر. 3) تم إصلاح التوجيه خلال نحو 10 دقائق؛ تؤكد Solana Foundation أن إنتاج الكتل استمر، وأن المعاملات لا تزال تُنجَز على الأرض، وأن حوالي 597/699 من المُحقِّقين الذين لديهم رهانات حافظوا على التصويت — أي أقرب إلى اختبار ضغط أكثر منه توقف شامل.
ملاحظة: لا يكفي تقييم لا مركزية السلاسل عالية الأداء عبر عدد “رؤوس” المُحقّقين فحسب؛ يجب أيضًا النظر إلى مراكز البيانات وASN وآليات التحويل/النسخ الاحتياطي للتأكد أنها موزعة فعلًا. الاقتراب من عتبة 1/3 يعني أنك وضِعت الشبكة على “درس” للجميع.
سلسلة ZK من Miden تعلن رسمياً عن عملة مستقرة خصوصية USDCx بنسبة 1:1: مدعومة باحتياطي من Circle USDC عبر xReserve. المعاملات لا تكون افتراضياً عامة من حيث الرصيد أو الطرف المقابل أو سجل التدفقات، لكن يمكن اختيارياً الكشف عنها للجهات المعنية بالتدقيق/الجهات التنظيمية.
النقاط التقنية البارزة هي الإثبات من طرف العميل (client-side proving) — تُنفَّذ المعاملة على جهاز المستخدم لتوليد إثبات، ثم يتم التحقق منها على السلسلة، في محاولة لدمج السرية المطلوبة من المؤسسات مع قابلية التحقق على البلوك تشين. وتقول الجهة الرسمية إن الهدف هو الإطلاق المتزامن مع mainnet (في أواخر هذا الشهر تقريباً)، وتغطي السيناريوهات المدفوعات والتداول وصرف الرواتب وإدارة أموال الشركات.
تم فصل Miden عن Polygon ليصبح كيانا مستقلاً؛ ومن ناحية الأكواد المفتوحة، لا تزال مستودعات Rust مثل miden-vm / protocol / node وغيرها تشهد مساهمات مستمرة مؤخراً. أما التوقيت الدقيق للـ mainnet وUSDCx فيعتمد على ما تعلنه الجهة الرسمية.
تنسيق الأخبار: MoneyGram Ramps تم إطلاقه على Solana.
ببساطة، يمكن للمحافظ والبورصات والتطبيقات عبر مجموعة API واحدة ربط شبكة MoneyGram النقدية العالمية بالسلسلة: الإيداع النقدي يغطي 25+ دولة، والسحب النقدي يغطي 170+ دولة ومنطقة. لا يحتاج المستخدمون إلى توصيل بنوكهم يدويًا بكل تطبيق على حدة، كما لا يضطر المطورون لتحمّل طبقة إضافية من عبء البنية التحتية.
هذه خطوة واقعية نسبيًا في سرد مدفوعات Solana: فالعملات المستقرة ليست مجرد أزواج تداول، بل بوابات يمكن ربطها بنقاط الخدمات الصاعدة في العالم الحقيقي. سبق لـ MoneyGram أن شاركت على Solana كمدققين، وهذه المرة تعمل على تضمين منتج Ramps مباشرة داخل النظام البيئي (Rift وغيرها تُعد من أوائل الجهات المتصلة).
【تجميع الأخبار】 خريطة طريق إيثيريوم تتغير: الخصوصية ومقاومة الهجمات الكمية (antiquantum) تظهران في المقدمة
قارن فيتاليك مؤخرًا خريطة طريقه الكلاسيكية لعام 2023، مع Strawmap التي تقوم بها مؤسسة إيثيريوم بتحديثها باستمرار (مراجع لترقيات البروتوكول، ويمكن ملاحظة أنها تمتد تقريبًا حتى 2029).
قال إن أكثر ما يلفت الانتباه ليس “ما الذي ما زال موجودًا”، بل مجموعة من الاتجاهات التي لم تكن موجودة أصلًا على خريطة 2023، لكنها أصبحت الآن في قلب الخطة:
1) خصوصية قوية: مجمعات الخصوصية وwormholes وغيرها، بهدف تقليل كشف المسار الكامل للمعاملات قدر الإمكان؛ كما تظهر تصميمات مرتبطة بمقاومة الرقابة (مثل FOCIL) ضمن الخريطة 2) مقاومة الهجمات الكمية: دمج أمان التشفير طويل الأمد في north star (اتجاهات مثل hash-based) 3) Lean Ethereum: المواصفات أكثر اختصارًا؛ وعلى المدى البعيد ما يزال هناك نقاش حول تطور أشكال بيئة التنفيذ 4) بعد أن ينضج zk، يمكن أيضًا مناقشة مسارات مثل rollup الأصلي وغيرها بشكل أكبر
تدرج Strawmap نفسها خمسة اتجاهات رئيسية تقريبية: L1 أسرع، وتحسين الإنتاجية (gigagas L1 / teragas L2)، وL1 ما بعد الكمية، واعتبار الخصوصية مواطنًا من الدرجة الأولى.
هذه ليست مادة “للمناداة بالصفقات”، بل أقرب إلى تنسيق علني على مستوى البروتوكول: مع توسيع الأداء، يتم أيضًا تحمل الخصوصية ومقاومة الرقابة والأمان طويل الأمد معًا. كما تؤكد Strawmap نفسها أنها strawman / وثيقة حيّة وليست جدولًا زمنيًا واحدًا ثابتًا.
ملاحظات تقنية|محاولة تفرّع بيتكوين BIP-110: بعد كتلتين تقريبًا توقّف
يهدف BIP-110 (Reduced Data Temporary Softfork) إلى “تقييد سنة مؤقتة” على مستوى الإجماع لإدخال بيانات غير مالية يمكن تضمينها في المعاملات: تقليل scriptPubKey/بيانات الشاهد بشكل مبالغ فيه، وفرض حدود أكثر تشددًا لـ OP_RETURN، وغيرها. يعتقد المؤيدون أن بيانات نمط الـ inscriptions تزاحم الدفع وتكلف عقد الشبكة موارد؛ ويرى المعارضون أنه طالما تم دفع الرسوم فيجب أن يُسمح باستخدام مساحة الكتلة بحرية.
في نافذة التفعيل كانت إشارات عمال التعدين لا تتجاوز نحو 2.53% فقط، أي أقل بكثير من عتبة 55%. وعند بلوغ الكتلة 961,632، بدأت العقد التي تشغّل عملاء BIP-110 في رفض الكتل التي لم ترسل إشارات، فخرجت بذلك سلسلة تفرّع تمثل مسارًا لمجموعة قليلة.
أكثر ما يلفت الانتباه ميكانيكيًا هو الصعوبة (Difficulty): فالسلسلة المتفرعة ورثت صعوبة التعدين الحالية للشبكة الرئيسية، لكن نسبة القدرة الحاسوبية كانت ضئيلة جدًا، فتمددت مدة تكوين الكتل إلى عدة ساعات. وتُعاد حساب الصعوبة فقط بعد اكتمال 2016 كتلة. والنتيجة أنه على جانب التفرع لم يتم تعدين سوى نحو كتلتين تقريبًا ثم خمدت العملية، مع فجوة تقارب مقدار يوم في التقدم مقارنة بالسلسلة الرئيسية.
تنبيه عملي آخر: في المراحل الأولى قد تقبل السلسلتان معاملات بنفس الصيغة، ما يخلق خطر إعادة التشغيل (replay). فمعاملات البيع الموقعة على عملة التفرع قد تُعاد أيضًا إلى الشبكة الرئيسية. عند مراقبة حدث التفرع، تكون التفاصيل التقنية أهم من الشعارات.
سوّي أعلنت مؤخراً التقدّم في قدرات التوقيع المقاوم للكمّ، وتسير في مسار معتمد من NIST:
1) الحسابات اليومية: خطط لدعم أصلي لـ ML-DSA-65 (FIPS 204) 2) خزائن القيمة العالية: داخل عقود Move باستخدام مخطط SLH-DSA-SHA2-128s المعتمد على التجزئة
تقول الجهة الرسمية إن التنفيذ الأساسي قد اكتمل وتم إجراء اختبارات معيارية (Benchmarks). والخارطة الزمنية تقريباً هي: هدف خزائن آمنة مقاومة للكمّ هذا العام على الشبكة الرئيسية؛ إدخال الحسابات الأصلية لـ ML-DSA-65 إلى شبكة الاختبار قبل نهاية العام؛ وهدف مصادقة الحسابات على الشبكة الرئيسية هو 2027 الربع الأول. التصميم اختياري التفعيل، ويمكن الاشتقاق من عبارات التذكّر الحالية، دون إجبار الجميع على تغيير مفاتيحهم فوراً.
النقطة التقنية هي: نقل ما بعد التشفير من مرحلة النقاش إلى قدرات التطوّر ضمن البروتوكول/المحفظة، وليس سرداً حول الأسعار. التفاصيل وفقاً للمدونة الرسمية.
【ملاحظات تقنية】XRPL 3.3.0: «إخفاء المبالغ مع بقاء دفتر الأستاذ قابلاً للتحقق» للمؤسسات
أصدرت عميلة XRPL rippled هذا الأسبوع الإصدار 3.3.0 (GitHub XRPLF/rippled، نحو 6/8). من بين مجموعة التعديلات (amendment)، أكثر ما يستحق الاهتمام هو Confidential Transfers (التحويلات السرّية):
• موجهة إلى Multi-Purpose Token (MPT، تنسيق شائع لأصول مُرقمنة/مُؤسّسية) • عناوين الحساب وأنواع الرموز ما زالت ظاهرة • يمكن تشفير الرصيد ومبالغ التحويل؛ ويُستخدم الإثبات التشفيري لإثبات أن دفتر الأستاذ متوازن من حيث «دخول/خروج الأرصدة»، دون الحاجة إلى عرض الأرقام الدقيقة على كامل الشبكة • الإصدار الأول يتطلب موافقة مسبقة (opt-in) من الحامل، ويغطي بشكل أساسي المدفوعات المباشرة من حساب إلى آخر باستخدام MPT (لا يشمل مؤقتًا مسارات مثل التداول عبر DEX المدمج، أو الحفظ/التوكيل، إلخ)
وفي نفس الإصدار تم تجميع قدرات أكثر تركيزًا على تشغيل المؤسسات: Batch (تجميع حتى 8 عمليات، يمكن أن تكون كلها قابلة للنجاح أو لا تنجح كلها)، Sponsor (سداد رسوم/احتياطي بدلًا عن المستخدم، دون الحاجة إلى أن يقوم الحساب الجديد أولًا بتجميع XRP)، Permission Delegation (تفويض نوع معاملات محدد فقط)، Dynamic MPT وغيرها. ومن جانب رسمي/التشغيل، تمت الإشارة أيضًا إلى انخفاض استهلاك الذاكرة بنحو 10%–15%، وتسريع عملية التتبع/اللحاق بالكتل.
حدود مهمة: هذه التعديلات لم تدخل بعد حيز التنفيذ — يجب أن يحصل XRPL على موافقة من «المدققين» (validators) بشكل مستمر لمدة أسبوعين متتالين بنسبة ≥80% حتى يتم تفعيلها. واستشهدت CoinDesk ببيانات من RWA.xyz: بلغ حجم توزيع أصول RWA على XRPL نحو 1.38 مليار دولار أمريكي (يشمل RLUSD وغيرها)، ومن ذلك فإن الأصول المُرمّزة غير RLUSD تبلغ تقريبًا 530 مليون دولار+؛ وبعد إطلاق الوظيفة، تتمثل النقطة المحورية في ما إذا كان المُصدرون مثل Aviva وOndo سيقومون فعلًا بفتح وضع التشفير.
بكلمة واحدة: ترقيع على مستوى البروتوكول لـ «الخصوصية المتوافقة + تجربة تشغيل للمؤسسات»، وليس قصة تسعير.
【ملاحظات تقنية】Sui تعلن رسميًا التقدم نحو التوقيعات المقاومة للكم
قالت مدونة Sui الرسمية (6/8) إنه سيتم دمج مجموعتين من التوقيعات المقاومة للكم بعد توحيدهما ضمن معايير NIST: • حسابات الاستخدام اليومي: ML-DSA-65 (FIPS 204) كتوقيع بروتوكول أصلي • خزائن عالية القيمة: ضمن عقود Move استخدام SLH-DSA-SHA2-128s (FIPS 205)
أبرز النقاط القابلة للتطبيق: يمكن أن تظل المفاتيح مستخرجة من العبارات المساعدة الحالية (seed phrase)؛ وبالاستفادة من address aliases التي تم طرحها بالفعل، يمكن للحساب تحديث مفاتيح التفويض دون الحاجة إلى نقل الأصول أولًا. الخطة المبدئية هي أن هدف «خزائن مقاومة للكم» سيكون على الشبكة الرئيسية هذا العام، وأن حسابات ML-DSA الأصلية ستكون على شبكة الاختبار بنهاية العام، ثم شبكة رئيسية في الربع الأول من 2027 (قد يتغير الجدول الزمني وفقًا لتعديلات التدقيق وتغذية راجعة من شبكة الاختبار).
كما أن The Block وغيرها تتبعت المستجدات. جوهر الأمر هو أن التشفير قابل للإضافة (plug-and-play) — أي إضافة آلية توقيع جديدة دون تغيير الإجماع والحالة القائمة.
【ملاحظات تقنية】تحققٌ موازي يبدأ بالتشغيل أولاً: World Chain × EIP-7928
تحديثٌ مؤخّر يندرج بدرجةٍ أكبر تحت “طبقة البروتوكول”: أعلنت World Chain (OP Stack L2 ضمن بيئة World) أنها ستفعّل على الشبكة الرئيسية “قائمة وصول كاملة إلى الكتل” (Block Access Lists / BALs)، وستُدرجها بشكلٍ تدفّقي (streaming) داخل Flashblocks—بحيث تُرفَق شرائحٌ من قائمة الوصول ضمن الزيادات الخاصة بالكتل الفرعية كل نحو 200 مللي ثانية. وتقول الجهة الرسمية إن Sepolia قد فُتحت في 27/7، بينما الهدف للشبكة الرئيسية هو 17/8؛ مع تفعيل عبر مفاتيح runtime، دون الحاجة إلى انتظار hard fork.
لماذا يستحق المتابعة؟ • يتعين على التحقق التقليدي إعادة تشغيل (replay) الكتلة كاملة تسلسلياً بحسب ترتيب المعاملات، فتتعطل المعالجة المتوازية بسبب اعتماد الحالة (state dependencies) • يتيح EIP-7928 للكتلة أن تحمل سجلاً عمّا “تمت قراءته/كتابته” من حسابات وفتحات تخزين (storage slots) مع القيم “لاحقاً/بعدياً” (事后值) • يمكن لعُقد التحقق أن تتحقق بالتوازي استناداً إلى ذلك، وأن تُحضّر/تهيّئ الحالة (preheat state)، وتقسّم تكلفة التحقق على عملية إصدار الكتل نفسها بدل إنهائها مرةً واحدة في نهاية الكتلة • وصف الاختبارات الرسمية: عند إنتاجية أعلى (التقارير/المنشورات تذكر إجراء اختبارات تحميل باتجاه ~1 Ggas/s تقريباً)، يمكن الحفاظ على زمن التحقق بشكلٍ لا يزال مستقراً نسبياً—والتركيز هو: “رفع الإنتاجية لا يتطلب بالضرورة زيادة متناسبة في عتاد التحقق”
نظرة لما بعد ذلك: تُعد BALs أيضاً أحد الاتجاهات الرئيسية ضمن مناقشات ترقية Glamsterdam اللاحقة على Ethereum؛ أن يعمل L2 على “تجربة تشغيلية” ضمن مسار الإنتاج أولاً ثم تقديم تغذية راجعة لـ L1 هو إيقاع نموذجي لتعاون النظام البيئي.
على مستوى الكود: مستودع monorepo الخاص بـ worldcoin/world-chain (بالـ Rust) لا يزال يشهد خلال الأيام الأخيرة عمليات إرسال (commits) مرتبطة بـ flashblocks / proofs، وليست مجرد إطلاقٍ شكلي.
المصادر (يمكن التحقق منها): • The Block:https://www.theblock.co/post/410651/world-chain-first-production-l2-block-access-lists-via-flashblocks • مدونة World الخاصة بالهندسة:https://world.org/blog/engineering/world-chain-full-block-access-lists • EIP-7928:https://eips.ethereum.org/EIPS/eip-7928 • GitHub:https://github.com/worldcoin/world-chain
الخطاف التقني ليس معقّدًا، لكنه مهم للغاية: 1)الوضع الحالي: يتم احتساب الرسوم الأساسية تقريبًا حسب عدد التواقيع؛ وبعد التحقق من التواقيع، فإن مقدار الـ compute الذي يُستهلك لا يختلف كثيرًا من حيث رسوم القاعدة. 2)SIMD-0553: يتم تقسيم الرسوم إلى «رسوم إدراج في البلوك + رسوم موارد». تُحتسب رسوم الموارد وفق وحدات cost المطلوبة من المعاملة، ويتم تدميرها بالكامل؛ المعاملات الخفيفة (مثل التصويت أو تحديث oracle) قد تصبح أرخص، بينما المعاملات ذات الحسابات الثقيلة ستكون أغلى. 3)وبحسب تقدير تقريبي لنشاط السلسلة في الفترة الأخيرة، قد يرتفع مقدار الحرق اليومي من مستوى يقارب 650 SOL إلى نطاق 7500–9000 SOL. وحتى مع ذلك، يظل أقل بكثير من مستوى الزيادة اليومية في المعروض/الإصدار، لذلك وحده لا يمكن أن يجعل الشبكة انكماشية. 4)SIMD-0550: يضاعِف تقريبًا سرعة الانكماش، وينقل نقطة ما يقارب 1.5% من زمن التضخم عند الطرف (terminal) من حوالي 2032 إلى حوالي 2029.
حاليًا، تم دمج وثائق المشروعين في مسار SIMD على GitHub؛ أما ما إذا كانت ستسري على الشبكة الرئيسية فيعتمد على ما إذا كانت إشارات الرهن/الرهان يمكنها تجاوز العتبة، وكذلك التصويت الرسمي اللاحق (نافذة الإشارة حتى حوالي 8/18).
بجملة واحدة: إنها تستخدم تصميم آليات لكتابة «استخدام موارد الجدولة والتنفيذ» في الفاتورة، وليس الاكتفاء بالرسوم وفق عدد التواقيع.
معلومة باردة عن محافظ العتاد (Hardware Wallet): ثغرة في إنتروبيا (Entropy) بذور Coldcard — المشكلة ليست في أن “يتم أخذ الجهاز فعليًا”، بل في أن مسار الأرقام العشوائية في البرنامج الثابت (firmware) انحرف.
وفقًا لتوضيحات Coinkite الرسمية، عندما تم الاتصال بـ libsecp256k1 / libNgU في 2021، تم استخدام توليد بذرة المحفظة بشكل خاطئ عبر مولّد عشوائي برمجي (pseudo-random) في MicroPython؛ ولم يتم حقن الإنتروبيا من مُولّد العشوائية العتادي TRNG فعليًا في المسار الرئيسي. النتيجة: تم خفض الإنتروبيا الفعّالة (تقدير رسمي تقريبي لـ Mk2/Mk3 بحوالي 40 بت، ولـ Mk4/Mk5/Q قبل الإصلاح بحوالي 72 بت، وكلها أقل من المتوقع وهو 128 بت). يستطيع المهاجمون تعداد/تجربة المفاتيح الضعيفة دون اتصال (off-line)، دون الحاجة إلى لمس الجهاز.
تتبع مثل Galaxy Research أظهر أن حجم العناوين المتأثرة التي تم “مسحها” بلغ من حوالي 1000+ BTC / حوالي 70 مليون دولار، ثم تراكمت موجات لاحقة إلى حدود 1300+ BTC / ما يقارب 90 مليون دولار (لا تزال الإحصاءات تتحدّث). وقد أصدرت الشركة إصلاحات في البرنامج الثابت (مثل Mk3 4.2.0، وMk4/Mk5 5.6.0، وQ 1.5.0Q… إلخ)، وشددت على أن: التحديث لا يصلح البذور القديمة؛ يلزم توليد بذرة جديدة على البرنامج الثابت الجديد ثم ترحيلها (migration). كما أن استخدام ما لا يقل عن 50 مرة من “نرد” (Dice) مستقل للحصول على إنتروبيا يقلّل المخاطر بشكل واضح. المستودع مفتوح المصدر Coldcard/firmware شهد عمليات إرسال/توقيع مكثفة خلال الفترة 7/31–8/1.
ملاحظات تقنية ثلاث: 1) محافظ العتاد مفتوحة المصدر ما زالت بحاجة إلى التحقق الشامل من نهاية إلى نهاية لمسار “تحليل الإشارات/الرموز (symbol parsing) / الاستدعاء الفعلي لـ RNG”، فلا يكفي أن ترى أن كود TRNG موجود داخل الثنائي (binary) 2) تدقيق بمساعدة الذكاء الاصطناعي سلاح ذو حدين؛ الفريقان (الهجوم والدفاع) يمكنهما تسريع اكتشاف الثغرات والتجارب 3) الحوسبة الذاتية (self-custody) يجب أن تعامل مصادر الإنتروبيا والنسخ الاحتياطي وعبارة المرور (passphrase) وخطوات الترحيل البارد بهدوء (cold migration) كأولوية من الدرجة الأولى
【مراقبة البروتوكول】يستعد XRP Ledger لإعادة تفعيل ميزتين تم سحبهما مرتين بسبب مشكلات أمنية، وبعد إصلاحهما سيتم إعادة عرضهما للتصويت من قبل المدققين
وفقًا لتقرير CoinDesk، من المتوقع أن تصدر xrpld 3.3.0 الأسبوع المقبل، متضمنة 5 تعديلات (amendments) مقترحة. ومن بينها Batch (معاملات ذرّية عبر حسابات متعددة، بحد أقصى 8 عمليات) و Permission Delegation (يمكن للجهات تفويض صلاحيات توقيع دقيقة دون تسليم السيطرة الكاملة) تم إيقافهما بشكل عاجل سابقًا بسبب ثغرات خطيرة: فبالنسبة للأولى، قد يسمح خلل في التحقق من التوقيع للمهاجم بإصدار معاملات دون امتلاك مفاتيح. أما الثانية فقد ظهرت فيها مخاطر تتمثل في تحويل الرسوم وسحب الرصيد. في ذلك الوقت لم تُنشر الميزات على الشبكة الرئيسية ولم يحدث ضرر مالي، لكن الأمر جدير بالتوثيق—سحبها أولًا، ثم إصلاحها، ثم التصويت.
وبنفس الدفعة توجد ثلاث قدرات جديدة تميل أكثر إلى الاتجاه المؤسسي ومسار الأصول: • Confidential MPT: إثباتات معرفة صفرية + تشفير بمنحنيات بيضاوية، لإخفاء أرصدة الرموز متعددة الأغراض/مبالغ التحويل عن العامة مع الحفاظ على مسارات التحقق من التدقيق والامتثال • Sponsored Fees and Reserves: يمكن للبنوك أو المنصات دفع رسوم XRP ومخصصات الاحتياطي نيابةً عن المستخدمين، ما يقلل عتبة “ضرورة امتلاك عملة الوقود (gas) أولًا لاستخدام الخدمة” • Dynamic MPT: عند الإصدار يمكن تحديد السمات التي يُسمح بتعديلها لاحقًا، ما يقلل من عمليات ترحيل كامل الرمز
على مستوى الحوكمة، لا يزال يتعين أن يحصل amendment على دعم من المدققين بشكل موثوق بنسبة لا تقل عن 80% لمدة أسبوعين متتاليتين حتى يتم تفعيله؛ فالشبكة لا شركة واحدة هي من تتخذ القرار. لا يزال المستودع الرئيسي XRPLF/rippled (مفتوح المصدر بلغة C++) نشطًا مع عمليات إرسال حديثة، وصدرت في 8/1 ترقية إصلاحية عاجلة 3.2.1، كما يجري أيضًا العمل على اختبارات Confidential MPT.
بكلمة واحدة: ليست “تكديسًا للميزات”، بل إعادة تفكيك افتراضات الأمان التي فشلت سابقًا وإجراءها من جديد، ثم المرور عبر عتبة التحقق الخاصة بالمدققين. ما إذا كان النهج المؤسسي والأصول الخاصة ستجد طريقها إلى التنفيذ على أرض الواقع يتوقف على التصويت وعلى النشر الفعلي.