Veridise Re-poster

If you are curious about how $27M can exit a system through a simple reward calculation, @FormallyJon provides a clear breakdown of the situation. The true vulnerability was an underlying flaw in the accounting logic, which caused identical tokens to be registered two separate times. The system recognized the funds first as a deposit that the protocol was obligated to return, and then separately as an earned reward. Crucially, both of these balances were made available for withdrawal. While a reentrancy exploit functioned as the delivery mechanism for the attack, the flawed accounting was the actual bug.

يمكن لترقيات الشبكة على Mina أن تجبر كل zkApp على تحديث مفتاح التحقق الخاص بها، وهي مطالبة تؤدي إلى فشل كامل لإعدادات الميسج القياسية (multisig) عند محاولة التكيف. ولحل هذه التحدية، طبّق Mina Multisig نهجًا يستخدم FROST. قبل أن يطرح @nori_zk هذا النظام على @MinaProtocol، أجرى Veridise مراجعة شاملة للحل، وتوثَّق هذه التقييمات حاليًا على AuditHub. والآن أصبحت البرمجية مفتوحة المصدر بالكامل، ما يجعلها موردًا ممتازًا لأي فريق Mina يعمل على تطبيقات المحافظ أو أدوات الحفظ الذاتي.

انهيار كامل لفكرة أن يكون المرء مسؤولاً عن حفظ أصوله بنفسه، بمجرد أن طُلب من الأفراد إيداع أصولهم في عقد الصرف الخاص بـ Rain. لقد شهدنا خسارة قدرها 500 ألف دولار في Avici، إلى جانب اختفاء 430 ألف دولار في Tria. وفي النهاية، تصبح أي ادعاءات بالاحتفاظ بالحفظ عديمة المعنى تمامًا إذا كان عقد التوجيه الذي تعتمد عليه يحتوي على ثغرة.

أصبح بإمكان مديري الأصول وقيّمي المخاطر الآن توفير عائد من إيداع واحد فقط، وذلك لأن العقود من @Lombard_Finance تقوم بتسعير إيداعات البيتكوين بدقة عبر مختلف الشرائح والمحولات. تتيح هذه الإعدادات عمليات ترحيل سلسة للأقبية تنجح في نقل سعر السهم الصحيح إلى المرحلة التالية. وقبل أن تقوم المنصة بالتحجيم باستخدام إيداعات فعلية، أجرت Veridise مراجعة شاملة للنظام.

من الممكن تمامًا بناء دائرة ZK تجتاز جميع اختبارات التحقق الخاصة بك بينما تقوم في الواقع بحساب نتيجة غير مقصودة تمامًا. تم إنشاء مُتحقق جديد مفتوح المصدر باسم LLEQ خصيصًا لاكتشاف هذه المشكلة بعينها، وهو متاح رسميًا الآن.

لتحديد الأخطاء التي يمكن اكتشافها بواسطة الذكاء الاصطناعي، قام فريق تطوع من «الفرقة الحمراء» يتألف من 20 إلى 25 مطورًا بالفعل بفحص أغلب البرمجيات مفتوحة المصدر الخاصة ببيتكوين. والواقع اليوم هو أن المهاجمين لم يعودوا بحاجة إلى سنوات من الخبرة؛ إذ يكفيهم الآن نموذج رخيص واحد. وبسبب هذا التحول السريع، فإن نهج المراجعة المخصص (العشوائي) لن يكون كافيًا لمواكبة التطورات. ومن هنا فصاعدًا، يجب أن تكون هناك ضمانات قابلة للإثبات تمامًا.

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

في عدد هذا الأسبوع من «Auditor's Take»، يسلّط @FormallyJon الضوء على مبدأ أساسي وراء كل تجمع (pool) ذي المنتج الثابت (constant-product). تعمل هذه التجمعات بأمان ضمن شرط حاسم واحد، وهو أن القوى الخارجية يجب ألا تتفاعل أبدًا مع احتياطياتها. وفي اللحظة التي يتم فيها المساس بالافتراض الأساسي، تنهار الضمانات التي يقدمها التجمع إلى جانب ذلك الافتراض.

بينما يستعد مطورو إيثريوم لترقية هوجوتا لعام 2027، فإنهم يضيقون بنشاط قائمة من 66 اقتراحًا. في حين أن FOCIL قد حجزت بالفعل مكانها في التحديث القادم، فإن أبرز الجدل يتمحور حول EIPs محددة. تهدف هذه المقترحات إلى تزويد تطبيقات الخصوصية بطبقة أساسية تقضي تمامًا على الحاجة إلى وسطاء موثوقين. وفي النهاية، ستحدد الحلول المختارة بالضبط سطح الهجوم الذي سيُكلَّف كل مُدقِّق ZK لاحقًا بالتعامل معه.

في عدد هذا الأسبوع من "Auditor's Take"، يوضح @FormallyJon بالتفصيل الخلل المحدد في التسلسل الذي تم مؤخرًا استنزاف "Future Protocol" بسببه. يكمن جوهر المشكلة في ثلاث عمليات قياسية فقط: تحويل، واستدعاء مزامنة، وعملية حرق. وعندما يتم تنفيذ هذه الأوامر بالترتيب الصحيح، تعمل كل الأمور تمامًا كما هو متوقع ولا يحدث أي شيء غير معتاد. ومع ذلك، فإن مجرد تشغيل الخطوات نفسها بالترتيب الخاطئ أدى إلى تفريغ مبلغ 4.6 مليون دولار من المسبح.

إن تنفيذ عملية حرق (burn)، ثم استدعاء مزامنة (sync)، ثم إجراء عملية نقل (transfer) بالترتيب الصحيح يضمن أن كل شيء يعمل بشكل طبيعي دون وقوع أي حادث. لكن يؤدي تشغيل الإجراءات الثلاثة نفسها بالضبط بترتيب غير صحيح إلى عواقب وخيمة. هذه الحالة المحددة هي بالضبط الطريقة التي تم بها سحب 4.6 مليون دولار من المجمع (pool). في أحدث إصدار من Auditor's Take، يقدم @FormallyJon تفصيلًا دقيقًا لخطأ التسلسل الذي استنزف Future Protocol.

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

حدس رياضي استمر لمدة 87 عامًا وتَمَّ دحضه مؤخرًا على يد كلود فابل 5. وبشكلٍ مُثير للاهتمام، نجح مثالٌ مضادٌ مكتشف في اجتياز فحص القابلية للعكس (invertibility) القياسي بنجاح. غير أنه نظرًا لأنه يوجّه ثلاثة مدخلات مختلفة إلى مخرجٍ واحد مطابق، فإنه يظل من المستحيل عكسه.

تُظهر هذه الحالة بوضوح أن مجرد اجتياز فحص التحقق لا يُعدّ برهانًا فعليًا. تكمن المشكلة بالضبط ضمن هذه الفجوة المنطقية التي توجد فيها أخطاء ZK غير مُقيدة بما يكفي.

تاريخياً، كانت أبحاث الأمان في مجال ZK مُجزأة بشكل كبير. إذا قمت بتطوير أداة معينة لـ Circom، فإن تلك المورد بالضبط لا تقدم أي قيمة لفرق Halo2. وبالمثل، يعني اختيار العمل مع Noir أن مطوري Circom مُستبعدين تمامًا. نظرًا لأن الصناعة تفتقر إلى أساس مشترك للبناء عليه، فإن الأبحاث الممتازة تبقى محبوسة داخل بيئات فردية. لحسن الحظ، فإن تقديم LLZK يُحدث تحولًا كاملًا في هذه الديناميكية.

LLZK الآن لديها منظمتها الخاصة على GitHub، منفصلة عن Veridise.

مؤسسة Ethereum قامت بتمويل جولتين. غالوايس قد ساهمت بالفعل في تطوير الواجهة الخلفية بشكل مستقل.

يمكن أن تعيش المشاريع المجتمعية المبنية على IR هناك. ماذا تود أن ترى؟

إليك منظور جريء عن المشهد الحالي. التحدي الأكبر غير المحلول الذي يواجه أدوات ZK في الواقع ليس له علاقة بالأداء. بل، المسألة الأساسية هي نقص الأساس المشترك. لأنه لا يوجد طبقة أساسية عالمية، يُجبر كل نظام بيئي على بناء إطاره الأمني الخاص من الصفر. أود أن أسمع آرائك حول هذا الوضع. هل تشارك هذا الرأي، أم تعتقد أن المخاوف بشأن التجزئة قد تكون مبالغًا فيها؟

نحن متحمسون لمشاركة أن LLZK V1.0 متاحة رسميًا للجمهور. تم تصميمها كنموذج تمثيلي مشترك، ويدعم هذا الإطار أدوات أمان ZK بشكل خاص. سيجد المطورون أن أي لغة برمجة تم تجميعها إلى LLZK تفتح على الفور إمكانيات ZK Vanguard للتحليل الثابت وPicus للتحقق الرسمي. الميزة الرئيسية هنا هي أنه يمكنك استخدام هذه الموارد بسلاسة، مما يجنبك تمامًا الحاجة إلى إعادة بناء أي أداة من الصفر. اعتبارًا من هذا الإطلاق، تحتوي واجهاتنا الأمامية النشطة حاليًا على Halo2 وCircom. للغوص أعمق في هذا الإصدار، يرجى زيارة الإعلان الكامل على https://veridise.com/blog/veridise-announcements/llzk-v1-0-a-new-phase-for-zk-shared-infrastructure/

بينما كنت في EthCC، كان السؤال الأكثر شيوعًا الذي طرحه الناس هو كيف يقارن التحقق الرسمي بتدقيق AI.

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

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

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