#dusk $DUSK @Dusk
كنت أجري توليد إثبات محليًا لأقارن أداء الدارات، ولاحظت شيئًا جعلني أعود وأقرأ كتابات فريق التشفير الخاصة بهم بدلًا من صفحات التسويق.
الأرقام الفعلية لدى PLONK هي ما يجعل ملف الامتثال يعمل، وليس مجرد زاوية الخصوصية. يبقى زمن التحقق حوالي 6-9 ميلي ثانية بغضّ النظر عن حجم الدارة — بينما يزداد زمن الإثبات تبعًا لتعقيد الدارة (تقريبًا 5.46 ثانية لدارة بعدد بوابات 2^16 على عتاد متواضع)، لكن يبقى جانب المُتحقق سريعًا وثابتًا. هذه المفارقة تهم أكثر في التمويل المُنظّم مما يظن الناس: فالمُدقق أو الطرف المقابل الذي يتحقق من الإثبات لا يحرق حوسبةً كبيرة كل مرة، حتى مع ازدياد تعقيد منطق المعاملة الأساسي.
وما لم أتوقعه أن أكتشف أن PLONK نفسه كان يحتوي على ثغرة مُفصَح عنها فعليًا، لا مجرد مخاطرة نظرية. وجد فريق أبحاث Dusk مشكلةً حرجة في كيفية تنفيذ تحويل Fiat-Shamir — الجزء الذي يحوّل البرهان التفاعلي إلى برهان غير تفاعلي عبر تجزئة التحديات بدلًا من قيام مُتحقق حي بإرسالها. لم تقم الإضافة الأصلية بتجزئة المُدخلات العامة في وقت مبكر بما يكفي، ما أضعف ضمانات السلامة (soundness). تنسّق Trail of Bits مع الإفصاح، وقام Dusk بإصلاحها قبل mainnet، ثم نشر الإصلاح علنًا بدلًا من تركه.
التفصيلة التي لا تزال عالقة في ذهني هي هذه — سلسلة مركّزة على الامتثال مبنية على نظام إثبات تشفير كانت لديها بالفعل علة سلامة في كود أقرب للإنتاج، تم رصدها وإصلاحها قبل أن تصبح مهمة. لا أعرف كم عدد التطبيقات الأخرى التي تستخدم PLONK في أماكن أخرى كانت ما تزال عرضة للخطر عندما أصبح ذلك معروفًا للعامة، أو كم استمر الفاصل الزمني بين الإفصاح ومشاريع أخرى تقوم بتحديث فروعها (forks) الخاصة بها.
كنت أجري توليد إثبات محليًا لأقارن أداء الدارات، ولاحظت شيئًا جعلني أعود وأقرأ كتابات فريق التشفير الخاصة بهم بدلًا من صفحات التسويق.
الأرقام الفعلية لدى PLONK هي ما يجعل ملف الامتثال يعمل، وليس مجرد زاوية الخصوصية. يبقى زمن التحقق حوالي 6-9 ميلي ثانية بغضّ النظر عن حجم الدارة — بينما يزداد زمن الإثبات تبعًا لتعقيد الدارة (تقريبًا 5.46 ثانية لدارة بعدد بوابات 2^16 على عتاد متواضع)، لكن يبقى جانب المُتحقق سريعًا وثابتًا. هذه المفارقة تهم أكثر في التمويل المُنظّم مما يظن الناس: فالمُدقق أو الطرف المقابل الذي يتحقق من الإثبات لا يحرق حوسبةً كبيرة كل مرة، حتى مع ازدياد تعقيد منطق المعاملة الأساسي.
وما لم أتوقعه أن أكتشف أن PLONK نفسه كان يحتوي على ثغرة مُفصَح عنها فعليًا، لا مجرد مخاطرة نظرية. وجد فريق أبحاث Dusk مشكلةً حرجة في كيفية تنفيذ تحويل Fiat-Shamir — الجزء الذي يحوّل البرهان التفاعلي إلى برهان غير تفاعلي عبر تجزئة التحديات بدلًا من قيام مُتحقق حي بإرسالها. لم تقم الإضافة الأصلية بتجزئة المُدخلات العامة في وقت مبكر بما يكفي، ما أضعف ضمانات السلامة (soundness). تنسّق Trail of Bits مع الإفصاح، وقام Dusk بإصلاحها قبل mainnet، ثم نشر الإصلاح علنًا بدلًا من تركه.
التفصيلة التي لا تزال عالقة في ذهني هي هذه — سلسلة مركّزة على الامتثال مبنية على نظام إثبات تشفير كانت لديها بالفعل علة سلامة في كود أقرب للإنتاج، تم رصدها وإصلاحها قبل أن تصبح مهمة. لا أعرف كم عدد التطبيقات الأخرى التي تستخدم PLONK في أماكن أخرى كانت ما تزال عرضة للخطر عندما أصبح ذلك معروفًا للعامة، أو كم استمر الفاصل الزمني بين الإفصاح ومشاريع أخرى تقوم بتحديث فروعها (forks) الخاصة بها.