

عقد يظل قيد التشغيل بعد مكالمة فاشلة لا يمتلك اليوم وسيلة موثوقة لتحديد ما إذا كان المُستَدْعَى قد ألغى العملية عمداً أو ببساطة نفد منه الغاز الذي حدد المرسل. هذا الفجوة هي جذر هجوم "إجهاد الغاز غير الكافي"، وتحاول مقترح مسودة جديد إغلاقها على مستوى EVM. EIP-8456، المفتوح للنقاش على Ethereum Magicians يوم الاثنين، يضيف تعليمة تُسمى CALLSTATUS، مؤقتاً عند opcode 0xA5 بتكلفة غاز 2. تُدفع حالة اكتمال أحدث مكالمة أو عملية إنشاء في الإطار الحالي كثلاثة بتات. البت 0 يعني إلغاء، والبت 1 يعني توقف استثنائي مثل نفاد الغاز، والبت 2 يعني أن شيئاً ما في إطار أدنى قد توقف. يشير المؤلف إلى أن الدليل الوحيد المتاح اليوم هو حساب gasleft() بعد المكالمة، وأن كل مراجعة لأسعار الغاز قد كسرت هذه العتبات. سيجعل الغاز ثنائي الأبعاد المقترح في EIP-8037 هذا الحساب أضعف حتى، لأن خزانه غير مرئي عبر تعليمة GAS. إذن لماذا البت الثالث؟ تمر معظم المكالمات الحقيقية عبر وسطاء مثل البروكسيات، أو مُلفّ functionCall من OpenZeppelin، أو Multicall3، أو مُحققين للتوقيع ERC-1271. إذا تم الإبلاغ عن حالة المُستَدْعَى المباشر فقط، فستبدو المُلفّات التي تلتقط توقف نفاد الغاز ثم تُلغي بسبب محدد وكأنها إلغاء متعمد. تحافظ المسودة على علم لاصق ينتقل عبر كل إطار، بحيث لا يمكن لأي مرسل يتحكم فقط في الغاز أن يجعل المُستدعي يقرأ إلغاءً بسيطاً. تُبلغ عن النتائج بدلاً من الأسباب، ولا يزال بإمكان المُستَدْعَى إنتاج توقف متعمد باستخدام INVALID. إنها تحمي فقط الكود المكتوب بعد نشرها، لأن العقود المُنشرة لن تقرأها. لا توجد مراجعات خارجية بعد، ورقم opcode لا يزال مفتوحاً، ونموذج أولي واختبارات لـ 58 حالة مدرجة لا تزال معلقة. الرابط - https://t.co/KnByUBgWrY

ما زالت معظم محافظ Ethereum تُظهر تاريخك المالي الكامل لأي شخص يمتلك عنوانك، والآن تُصنف مؤسسة Ethereum هذا الأمر كثغرة أمنية وليس كميزة خصوصية إضافية. في الاثنين، نشرت المؤسسة أن الهجمات والاستغلالات التي وقعت خلال الأسبوع الماضي جعلت نقطة واحدة أكثر وضوحًا بالنسبة لهم، وهي أن الخصوصية والأمان لا يمكن اعتبارهما أهدافًا منفصلة. وأشاروا إلى أنه يمكنك القلق أقل بشأن استخدام المهاجم لتاريخك على السلسلة ضدك عندما تكون الخصوصية هي الوضع الافتراضي. وأشار المنشور إلى تحديث حول Kohaku، وهو مشروع أدوات خصوصية أولية تتبناه المؤسسة. يُقسّم مستودع JavaScript هذا المشروع إلى حزم يمكن لفريق المحافظ اختيارها واحدة تلو الأخرى. توجد مكتبات لـ Privacy Pools وTornado Cash، بالإضافة إلى مكتبة Railgun التي يُشار إليها حاليًا في ملف README بأنها قيد الصيانة. يُعرّف حزمة الإضافات واجهة موحدة لبروتوكولات المجموعات المحمية، بحيث يمكن للمحفظة التحدث مع جميعها بنفس الطريقة. أما حزمة المزود فتُجرّد ethers وviem وHelios وColibri. كما يحتوي المستودع على حساب ERC-4337 مقاوم للحوسبة الكمية. توجد حزم Rust في مستودع أخٍ منفصل. أنا أحب أن هذا المشروع مصمم كـ SDK وليس كمحفظة خصوصية أخرى تطلب من المستخدمين نقل أموالهم. الفكرة هي أن المحافظ الحالية يمكنها إضافة سير عمل محمية دون الحاجة إلى أن يعيد كل فريق تنفيذ ثلاثة بروتوكولات. يكون ملف README صريحًا بشأن الحالة الحالية. تم وضع بعض الأجزاء على أنها غير جاهزة للإنتاج، وتحتوي الحزم على كود غير مُراجَع. قال جوردن إينيف من Ambire يوم الجمعة الماضي إن الفريق قضى أشهرًا في اختبار التكاملات، ولم يُعلن عن أي تاريخ إصدار عام حتى الآن. من المقرر أن يُجري فيتاليك ونيكولاس كونسيني عرضًا توضيحيًا لـ Kohaku مع Ambire على شبكة Ethereum الرئيسية يوم الثلاثاء القادم في @EFDevcon، وفقًا لقائمة الجلسات. هنا المستودع - https://t.co/egNbLgAo0J

يمكن الآن لواجهة الأوامر الخاصة بك أن ترد عليك، والمضحك أن ذلك يحدث دون الاتصال بأي واجهة برمجة تطبيقات سحابية. في السبت، أصدرت Ollama الإصدار 0.40.11 مع ميزة تحويل النص إلى كلام على macOS. أول نموذج للكلام هو Phonon، وهو عائلة من نماذج TTS الصغيرة من Gradium. تقوم بجلبه باستخدام ollama pull phonon وتشغيله مثل أي نموذج آخر. الجانب الذي سيهتم به المطورون حقًا هو واجهة برمجة التطبيقات. يعمل Phonon مع نقطة النهاية /v1/audio/speech المتوافقة مع OpenAI على localhost. إذا كان كودك يستخدم بالفعل مكتبة OpenAI للكلام، فتقول الوثائق إنك تحتاج فقط إلى عنوان URL أساسي جديد. يتم تدفق الاستجابة أثناء توليد الصوت، لذا يمكن بدء التشغيل قبل اكتمال النص بالكامل. يمكنك حتى توصيل رد نموذج المحادثة مباشرة إلى Phonon، ويبدأ في التحدث بعد الجملة الأولى. الإخراج هو 24 كيلو هرتز أحادي، كـ WAV افتراضيًا أو PCM خام 16 بت إذا طلبت ذلك. تسرد الوثائق بعض القيود التي يسهل تجاوزها. كل طلب يأخذ ما يصل إلى 4,096 حرفًا، على الرغم من أن ollama run يقسم النصوص الأطول لك. يتم تهجئة الرموز والأسعار والبريد الإلكتروني والعناوين URL، بينما تُقرأ التواريخ الرقمية كما هي مكتوبة، لذا تقترح الوثائق كتابة التواريخ بالكلمات. تعيد الخيارات غير المدعومة مثل السرعة أو التعليمات خطأ 400 بدلاً من تجاهلها بهدوء. تستحق الترخيص قراءة دقيقة قبل إصدار أي شيء. نموذج Phonon الإنجليزي الافتراضي هو Apache 2.0. النسخ المتنوعة الفرنسية والألمانية والإسبانية والبرتغالية ومتعددة اللغات بحجم 40M هي CC BY-NC 4.0، والتي تستبعد الاستخدام التجاري. كما تقول Ollama أنه على MacBook Pro M5 Max، عمل بسرعة 35 بالمائة أسرع من وقت التشغيل الخاص بـ Gradium، وهو معيارهم وليس معيارًا مستقلًا. الكلام مدعوم فقط على Apple Silicon حاليًا، مع دعم Windows وLinux مدرج كمُقبل قريبًا.

منصة Ethereum L2 تقبل توقيعات صفرية تبدو وكأنها ثغرة أمنية، لكن BB84 تفعل ذلك عن قصد لتجنب الهجمات الكمية. في عطلة نهاية الأسبوع الماضية، نشر مؤسسها، الذي ينشر باسم Hadamard، التصميم على Ethereum Research وطلب ملاحظات نقدية. BB84 هو rollup على أساس OP Stack على الشبكة الرئيسية، ويعمل منذ 30 سبتمبر، حيث لا تحتوي معاملات L2 على أي ECDSA على الإطلاق. كل حساب هو نهاية سلسلة تجزئة keccak-256 مبنية من سر، بـ 1000 خطوة افتراضيًا. لإنفاق الأموال، يكشف محفظتك عن القيمة السابقة في السلسلة، والتي يمكن لأي شخص التحقق منها بتجزئة واحدة. داخل L2، الافتراض الوحيد المتبقي هو مقاومة الصورة المسبقة لـ keccak-256، والتي تخفض خوارزمية غروفر العمل إلى حوالي 2^128. كشف السر يجعله عامًا، لذا يضيف البروتوكول خطوة التزام وكشف لربط كل صورة مسبقة بمعاملة واحدة أولاً. يتعامل نوعان جديدان من المعاملات في op-geth مع هذا، ويستبدل فحص المرسل ecrecover. يُستهلك التفويض حتى عند رفض الاستدعاء، وإذا فاتت المحفظة خطوة التجديد على الرابط الأخير، فإن هذا العنوان يصبح ميتًا. يتضمن المنشور ثغرة في التقدم السريع وجد الفريق أثناء كتابته. الالتزامات لا تحمل توقيعًا، لذا كان يمكن لالتزام جديد أن يستبدل التزامًا معلقًا، ويمكن للمهاجم إعادة ربط سر مكشوف بدفعه الخاص. قاعدة دخلت حيز التنفيذ في 21 أكتوبر تجعل أول التزامات تفوز. الحدود مذكورة بوضوح. لا تزال إيداعات وسحبات L1 تستخدم ECDSA. لا توجد أدلة خطأ بعد، ووفقًا لوصف المنشور نفسه، فلن تصل السلسلة حتى إلى المرحلة 0 على L2BEAT. يدير المُرتب مجموعته، وعناوين 160 بت تترك مقاومة كمية ثانوية للصورة المسبقة حوالي 2^80. كما يسأل المنشور عما إذا كان يمكن لحسابات سلسلة التجزئة أن تصبح نمط تحقق EIP-7702 أو تجريد حساب أصيل على L2s العامة.

أصبح Chainlink الافتراضي للربط بين السلاسل والامتثال في أدوات الرموز الخاصة بـ OpenZeppelin، وإذا قمت بتحديد مربع الامتثال، يتغير ترخيص رمزك. قبل أسبوع، أعلنت OpenZeppelin عن شراكة استراتيجية مع Chainlink. تم دمج CCIP وACE، بروتوكول الربط بين السلاسل ومحرك الامتثال التلقائي الخاص بـ Chainlink، مباشرة في Contracts Wizard، أداة OpenZeppelin القائمة على الذكاء الاصطناعي ووثائقها. جميع مولدات ERC20 و Stablecoin و RWA تقدم الخيارين. اختيار خيار CCIP يجعل الرمز يُظهر مكالمات الصك والحرق التي يحتاجها حوض الحرقة والصك الخاص بـ Chainlink، خلف أذونات الرمز الخاصة به. كما يُعين مسؤولًا لتسجيل CCIP. هذا الجزء يحافظ على الترخيص الذي اخترته، لأن كود Chainlink لا يُدرج داخله. أما خيار ACE فهو مختلف. فهو يُحوّل التحويلات والصكوك والحرق إلى محرك سياسات تقوم أنت بتنفيذها وتكوينها. تقول وثائق OpenZeppelin نفسها إن الرموز التي تستخدم ACE تخضع لترخيص BUSL-1.1، ويجب أن يستوفي الاستخدام الإنتاجي ترخيص ACE ومنح الاستخدام الإضافية الخاصة به. لسنوات، كان رمز OpenZeppelin المُنشأ يحمل الترخيص الذي اخترته، عادةً MIT. الآن، مربع اختيار واحد فقط يغيّر ذلك، وقد لا يلاحظه مطور مبتدئ في عجلة. المولد لا يسجل حوضك، ولا يضبط الأذونات، ولا يكتب سياساتك. ربط محرك سياسات لا يُكوّن أي سياسة، وأنت تبقى مسؤولًا عن الامتثال لأي قواعد تنطبق عليك. كما تذكر الإعلان أيضًا مسارًا للانتقال من OpenZeppelin Defender إلى بيئة Chainlink التشغيلية. لا شيء من هذا مخفي، وبالنسبة لفريق RWA الذي يريد بالفعل Chainlink، فهو يوفر جهدًا حقيقيًا في التكامل. أريد فقط أن يختار المطورون هذا الخيار عن قصد، وليس لأن المعجزة وضعته هناك.

مُطوري العقود الذكية، قد يكون مُجمّع Solidity الخاص بك قد حذف بشكل هادئ مخزنًا كنت بحاجة إليه، ولم تره أبدًا في الكود المصدر. صدرت Solidity 0.8.38 يوم الخميس الماضي. وهي تصلح خطأ في مُحسّن Yul كان موجودًا في كل إصدار من 0.8.19 إلى 0.8.37. يُحافظ المُحسّن على ملاحظات حول ما هو موجود في الذاكرة والتخزين. ويستخدم هذه الملاحظات لاستبدال عملية تحميل بقيمة يعرفها مسبقًا، ولتجاوز عملية تخزين تكتب ما هو موجود بالفعل. لتحديد ما إذا كان يمكن أن تتداخل عنوانان، فإنه يصف كل منهما كمتغير أساسي زائد إزاحة. نفس المتغير الأساسي، وإزاحة مختلفة، إذًا يجب أن يكونا في فتحتين مختلفتين. كانت هذه الوصفات مخزنة مؤقتًا. ثم قام أحدهم بإعادة تعيين المتغير الأساسي. ولا يلاحظ المُحسّن دائمًا ذلك. الآن، يقارن عنوانًا مبنيًا من القيمة القديمة مع آخر مبني من القيمة الجديدة كأنهما يشتركان في متغير أساسي. فيقرر أنهما مختلفان، لكن في وقت التشغيل يشيران إلى نفس المكان. النتيجة هي ملاحظة قديمة. يمكن لعملية تحميل لاحقة أن تعيد قيمة قديمة. يمكن أن تُحذف عملية تخزين كنت بحاجة إليها. يمكن لـ keccak256 على هذا الموقع أن يُنشئ هاشًا لبيانات قديمة. فقط الكود المُجمّع مع تفعيل المُحسّن معرّض لهذا الخطأ. باستخدام via-IR، يمكن لأي كود أن يتأثر به، حتى بدون تجميع مباشر. باستخدام خط أنابيب التراث الافتراضي، فقط بعض التجميع المباشر والمساعدات التي ينشئها المُجمّع. البناءات غير المُحسّنة آمنة. فريق Solidity صنّفه كخطورة منخفضة، وفعلوا شيئًا أتمنى أن يفعله كل فريق مُجمّع: أعادوا تجميع كل عقدة موثقة في قاعدة بيانات Sourcify باستخدام الإصلاح وبدونه، وكانت البايت كود متطابقة لكل منها. إذًا، إنه نادر. لكن الندرة لا تعني أبدًا عدم الحدوث، خاصة إذا كان كودك حديثًا ولم يُنشر بعد. ظهر هذا الخطأ من خلال مكافأة الأخطاء التابعة لمؤسسة Ethereum، وظهر تقرير ثانٍ يُظهر أن Solidity العادية دون تجميع مباشر يمكن أن تُفعّله.


