كلما حسّنت دائرة ZK لتقليل القيود، عليك التأكد من أن الإصدار الجديد ينفّذ الحساب نفسه تمامًا الذي ينفّذه تصميمك الأولي. في حين أن الاختبارات التقليدية لا تتحقق إلا من المدخلات المحددة التي تتوقعها، يتبع LLEQ نهجًا أشمل بكثير. فهو يُسند عملية التحقق إلى محلّل SMT، الذي يقيّم منطقيًا كل سيناريو إدخال ممكن. ويقدّم @RaghavMalik15 دليلًا عمليًا كاملًا خطوة بخطوة حول كيفية تنفيذ سير العمل هذا.
كشف فريق @aztecnetwork عن خارطة طريق شاملة لما بعد عصر الحوسبة الكمومية، تهدف إلى إنجازها بحلول عام 2030. وما يجعل هذا الجدول الزمني مثيرًا للاهتمام على نحو خاص هو ترتيب الترقيات المخطط لها. إذ يضع الفريق أولوية لمعالجة خطر هجوم «اجمع الآن وفك التشفير لاحقًا» منذ البداية. وبناءً على هذا النهج، ستُطرح مكتبات معززة لحماية البيانات الخاصة في أوائل عام 2027، قبل وقت طويل من إجراء أي تغييرات على نظام الإثبات.
عند التفكير في ترحيل بيتكوين، يُعد اختيار مخطط توقيع مقاوم للحوسبة الكمومية في الواقع أبسط خطوة. وتسلط ورقة بحثية حديثة حول التشفير ما بعد الكمومي، نشرتها كوينبيس، الضوء على مسألة أصعب بكثير. إذ يجب على المحافظ التي تستخدم مخططات ذات حالة أن تتابع بعناية المفاتيح أحادية الاستخدام التي سبق استخدامها. فإذا استعاد مستخدم نسخة احتياطية قديمة ثم أعاد استخدام أحد المفاتيح، فسيتمكن المهاجم عندئذ من تزوير توقيع صالح.
كان لوكلاء الذكاء الاصطناعي حضور بارز في جميع أرجاء فعالية @token2049، حيث استُعرضت قدرتهم على تنفيذ مهام معقدة، مثل إدارة الخزائن وتنفيذ الصفقات وصياغة العقود. لكن وسط كل هذا الحماس، أُغفلت إلى حد كبير مسألة جوهرية: فلم يتطرق أحد تقريبًا إلى ضرورة التحقق من المخرجات الفعلية التي ينتجها هؤلاء الوكلاء. وقد ركز فريقنا على معالجة هذه الفجوة تحديدًا في عملية التحقق. نتطلع إلى مشاركة المزيد من التفاصيل معكم قريبًا جدًا.
خلال يوم كامل قضاه فريق Veridise في سنغافورة، أتيحت لنا فرصة التحدث على ثلاث منصات مختلفة. سواء كنا في قمة @solana، أو نشارك في @gammaprime، أو نحضر يوم تعدد السلاسل، فقد تمحورت أحاديثنا كثيرًا حول المعرفة الصفرية (ZK)، وعمليات التدقيق الأمني، والتحقق الرسمي. وعلى الرغم من اختلاف الفعاليات، ظل الحضور يطرحون موضوعًا مشتركًا. فقد تكرر السؤال عن كيفية إيجاد طريقة موثوقة للتحقق من أن جزءًا معينًا من الشيفرة البرمجية ينفذ بالفعل ما تنص عليه مواصفاته بدقة.
إذا كانت خريطة طريقك تتضمن تدقيقًا قادمًا في الربع الرابع أو في بداية العام المقبل، فإن @kulm1nski هو الشخص المثالي للتشاور معه بخصوص نطاق مشروعك والجدول الزمني. سيسافر إلى سنغافورة لحضور @token2049 من 5 إلى 9 أكتوبر. يُرجى إرسال رسالة مباشرة إليه لترتيب وقت للاجتماع.
إذا كانت خريطة الطريق القادمة لديك تشمل الأمن، وتبحث عن نقاش مباشر حوله، فإن الأسبوع المقبل يوفر فرصة مثالية للتواصل. يتجه @FormallyJon إلى سنغافورة، حيث سيحضر @token2049 ويستكشف الفعاليات الجانبية المحيطة من 5 إلى 9 أكتوبر. لا تتردد في إرسال رسالة مباشرة (DM) لحجز وقت للاجتماع.
مع إدخال معاملات الإطارات (Frame Transactions)، ستتمتع الحسابات بمرونة تحديد إرشادات التفويض الخاصة بها. وهذا يعني أنه يمكن للمستخدمين إعداد قواعد مخصصة لأنظمة التوقيع البديلة، واسترداد الحساب، والموافقات المتعددة. ونتيجة لهذا التحول، سيتم نقل منطق التشغيل الذي يوجد حاليًا داخل كود المحفظة الفردي مباشرةً إلى البروتوكول الأساسي. ومن المهم أن نأخذ في الحسبان أنه مع انتقال هذا المنطق، فإن سطحه المقابل للفشل ينتقل أيضًا إلى طبقة البروتوكول.
قبل مشاركة تقدير 63 دولارًا لمعاملة بيتكوين مقاومة للكمّ، يُنصح بشدة بمراجعة المنهجية الأساسية. كما توضح <t-2/> بشكلٍ واضح، فإن هذا المبلغ هو مجرد نموذج نظري وليس فاتورة فعلية، ما يعني أنه لا يتم إنشاء أي معاملات حقيقية. علاوة على ذلك، بينما تم تنفيذ اختبارات الأداء باستخدام RTX 4090، فإن إسقاط التكلفة الإجمالي يفترض شبكةً افتراضية تتكون من 100 جهاز RTX 3090.
يُعدّ تأمين معاملة بيتكوين ضد تهديدات الحوسبة الكمية الآن أسرع 6 مرات، وذلك بفضل كود تشفير تم تحسينه بواسطة الذكاء الاصطناعي. ورغم أن السرعة مقياس يمكننا قياسه بسهولة، فإن إثبات أن طريقتين متكافئتين حقًا أمر مستحيل دون وجود دليل قابل للتحقق.
يتم حاليًا اختبار ترقية Alpenglow على شبكة Solana التجريبية، ما يحقق انخفاضًا لافتًا في زمن الإنهاء النهائي من 12.8 ثانية إلى 150 ميلي ثانية فقط. ورغم أن هذه المرحلة تضمن خضوع المدققين لتقييم شامل، إلا أنها تترك عمليات التكامل دون فحص. ونتيجة لذلك، أي تدفق إيداع أو جسر يحافظ على تأكيد ثابت مُعاير خصيصًا لـ 32 مقطعًا (slot) يعمل على افتراض بأن أحدًا لم يُعد اشتقاقه من جديد.
في أحدث إصدار من Auditor's Take، يستكشف @FormallyJon فئةً مميزةً من الثغرات. تتمثل المشكلة الأساسية في أنه كلما قامت دالة بأخذ calldata مقدم من المتصل ثم تمريره مباشرةً إلى استدعاء منخفض المستوى. يتيح هذا السيناريو إمكانية تشغيل أي إجراء متاح يمكن الوصول إليه عبر واجهة الهدف. وهذا يخلق موقفًا خطيرًا لأن مجموعة العمليات تلك لم تُصمم عمدًا بواسطة أي شخص، كما لم يتم فحصها أبدًا بواسطة مُدقق تدقيق. يمكنك استكشاف التحليل الكامل عبر زيارة الرابط أدناه.
على الرغم من أن التحقق الرسمي يُعد فعّالاً للغاية في الإشارة إلى أن خاصية ما قد فشلت، فإنه يتوقف قبل شرح السبب الكامن وراء ذلك. تعلّم المزيد من @ShankaraPailoo2 حول عملية تحويل مثال معاكس بسيط إلى سبب جذري واضح.
للحصول على شرح خطوة بخطوة لكيفية عمل ذلك، يُرجى الاطلاع على العرض التوضيحي المقدم بواسطة @RaghavMalik15 أدناه. ستلاحظ أن Z3 يحل بنجاح التزام الإثبات الخاص بـ LLZK في أقل من ثانية واحدة. وفي النهاية، وبما أنه لا يمكن استيفاء المقدم، فلا يلزم إثبات إضافي.
تم تحديد تاريخ نهائي صارم في ديسمبر 2029 رسميًا من قبل Ethereum لتحقيق مقاومة الكم. ومن المثير للاهتمام أن هذا الجدول الزمني مدفوع بالكامل بجدول نشر التحديثات الحماية، وليس بالانتظار حتى ظهور أجهزة كمومية وظيفية فعليًا. سيتطلب الوصول إلى هذا المعلم خمس عمليات انقسام (فوركس) متميزة للشبكة، مع تخصيص كل مرحلة بالضبط 7.2 أشهر. جدول التطوير شديد الضيق ولا يترك على الإطلاق أي مجال للتأخيرات. يمكنك الاطلاع على التفاصيل الكاملة في https://blog.ethereum.org/2026/09/07/protocol-priorities
تعمل المكالمات الخارجية كعنصرٍ أساسيّ في برمجة السلسلة على السلسلة، ما يعني أن مجرد وجودها لا ينبغي أبدًا اعتباره علامة تحذير تلقائية. ومع ذلك، توجد بالضبط حالتان محددتان تشيران فعلًا إلى الخطر. تتمثل المشكلة الرئيسية الأولى في أنه عندما يحدث تحديث للحالة فقط بعد أن تكون المكالمة قد اكتملت بالفعل. ويحدث الخطر الثاني عندما يتم التنازل عن التحكم في التنفيذ إلى كود لم يقم أحد بمراجعته بشكل صحيح.
بمجرد أن تثبت التكافؤ مرة واحدة، فإن تحليل أي تفاصيل إضافية للدائرة لم يعد مشكلة ZK. تنتقل العملية بسلاسة إلى مهمة تحقق قياسية من البرنامج. يتيح لنا هذا التحول إعادة استخدام عقود من التقنيات الكلاسيكية فورًا. انضم إلى @RaghavMalik15 بينما يتعمق في هذا العنصر غير المتوقع تمامًا من LLEQ.
إذا كنت تتساءل عن كيفية خروج 27 مليون دولار من نظامٍ ما عبر حساب مكافأة بسيط، يقدم @FormallyJon شرحًا واضحًا لما حدث. كانت نقطة الضعف الحقيقية كامنة في خللٍ أساسي في منطق المحاسبة، مما أدى إلى تسجيل الرموز المتطابقة مرتين بشكل منفصل. تعرف النظام على الأموال أولًا على أنها إيداع كان البروتوكول ملزمًا بإعادته، ثم بشكلٍ منفصل كَمكافأة مُستحقة. والأهم من ذلك أن كلا الرصيدين جرى إتاحتهما للسحب. وبينما كانت دالة استغلال إعادة الدخول هي آلية التسليم للهجوم، فإن الخلل في المحاسبة هو في الواقع هو البقعة.
يمكن لترقيات الشبكة على Mina أن تجبر كل zkApp على تحديث مفتاح التحقق الخاص بها، وهي مطالبة تؤدي إلى فشل كامل لإعدادات الميسج القياسية (multisig) عند محاولة التكيف. ولحل هذه التحدية، طبّق Mina Multisig نهجًا يستخدم FROST. قبل أن يطرح @nori_zk هذا النظام على @MinaProtocol، أجرى Veridise مراجعة شاملة للحل، وتوثَّق هذه التقييمات حاليًا على AuditHub. والآن أصبحت البرمجية مفتوحة المصدر بالكامل، ما يجعلها موردًا ممتازًا لأي فريق Mina يعمل على تطبيقات المحافظ أو أدوات الحفظ الذاتي.
انهيار كامل لفكرة أن يكون المرء مسؤولاً عن حفظ أصوله بنفسه، بمجرد أن طُلب من الأفراد إيداع أصولهم في عقد الصرف الخاص بـ Rain. لقد شهدنا خسارة قدرها 500 ألف دولار في Avici، إلى جانب اختفاء 430 ألف دولار في Tria. وفي النهاية، تصبح أي ادعاءات بالاحتفاظ بالحفظ عديمة المعنى تمامًا إذا كان عقد التوجيه الذي تعتمد عليه يحتوي على ثغرة.