#dusk $DUSK @Dusk لن أوْجِدُ لنفسي كذبة: كنتُ أبحث عن زاوية لائقة في نموذج الخصوصية لدى dusk عندما أشارت أختي إلى شيءٍ ما هناك، فوجدتُ أفضل—كتابة أمنية حقيقية
اكتشفت OtterSec خللًا في سلامة (soundness) dusk-plonk، نظام الإثبات وراء phoenix لحجب المعاملات المؤمّنة. كان المُتحقِّق يفترض أن يَفحص أربع قيم محددة من كل إثبات، لكنه لم يكن يفعل ذلك على الإطلاق—كان يستخدمها فقط في الحساب النهائي دون التحقق منها مقابل الالتزامات الموثوقة
ما الذي قد يترتب نظريًا على ذلك؟ أمرٌ مجنون: يمكن لشخص أن يبني إثباتًا يبدو صحيحًا تمامًا بينما يكذب بشأن ما يمثله. سكّ dusk من لا شيء، أو دفع إنفاقٍ shielded مزيف عبره. وبما أن الأمر يتعلق بـ phoenix، فإن المخرجات المُزوّرة داخل مجموعة الـ shielded كانت ستكون شبه مستحيلة الملاحظة—لا يمكنك التفرّس في ملاحظة خاصة مثلما تفعل مع رصيد عام
تم إصدار الإصلاح في الالتزام (commit) 645265b7 بتاريخ 14 فبراير 2026. ملاحظة مهمة: هذا إفصاح من OtterSec، ولم أجد كتابةً مطابقة من فريق dusk نفسه—إذا كان أي شخص قد رأى واحدة، أخبرني
الجزء الذي يتخطّاه الناس عندما يتحدثون عن سلاسل خصوصية zk: الخصوصية ليست هي الجزء الخطِر، بل المُتحقِّق. معاملات moonlight العامة محكومة بفحص توقيع بسيط، سهل الفهم. معاملات phoenix المؤمّنة بالكامل تعتمد على فحص واحد للإثبات يكون محكمًا إلى أقصى حد. مساحة ثقة أكبر، لكن غير مرئية لأن الأمر رياضيات وليس واجهة مستخدم
وليس هذا مشكلة dusk وحدها أيضًا—هناك تطبيق plonk مستقل ثاني (ultraplonk الخاص بـ jellyfish) كان لديه الفئة نفسها من الخلل، وتمت معالجته بعد شهر في 18 مارس. نفس الغلطة، فريقان مختلفان، بفارق شهور
كان لدى dusk أيضًا مشكلة أخرى تتعلق بسلامة plonk في 2022، تم رصدها عبر Trail of Bits، وتم الإفصاح عنها علنًا ومعالجتها. مشكلتان منفصلتان، بينهما سنوات، وأنماط فشل مختلفة، تم اكتشافهما بواسطة شركتين مختلفتين
يجعلني أفكر بأن السؤال الحقيقي ليس "هل يمكنه إخفاء المعاملات؟" بل: كم عدد العيون المستقلة التي يحتاجها نظام إثبات قبل أن تثق به المؤسسات في أوراق مالية حقيقية.
#Web3Security