#dusk $DUSK
خلال اليومين الماضيين، كنت أتابع @Dusk أحدث موجة من Developer Update، ويوجد تحديث أظنّه يستحق المشاهدة أكثر من عبارة “تمت إضافة ميزة ZK أخرى”.
zk-tools بدأت الآن في استكمال أدوات توليد والتحقق الخاصة بـ Groth16 Solidity verifier.
للوهلة الأولى يبدو الأمر صغيرًا.
لكن إذا كنت قد عملت فعلًا على تطبيقات ZK، فستعرف أن إعداد proof هو نصف الطريق فقط.
بعد ذلك تأتي مشكلة أكثر واقعية: كيف يتعرّف عقد Solidity على هذا الـ proof؟
وفقًا لقواعد تعريف الـ circuit: يقوم الـ prover بتوليد الـ proof، وعلى جهة EVM، يلزم وجود عقد verifier للتحقق من أن الـ proof والـ public inputs يطابقان القيود الأصلية.
إذا لم تُنجَز هذه الواجهة على نحو جيد، فحتى لو كانت التشفير قويًا جدًا، ستظل بعيدة عن معظم مطوري Solidity العاديين.
لذلك، وأنا أنظر إلى تحديث Dusk هذه المرة، فإن التركيز ليس على اسم Groth16 نفسه.
بل على أنه يكمل سلسلة:
proof → verifier → Solidity application
ضمن هذا الجزء الوسيط من السلسلة الهندسية.
وبالطبع، الـ verifier ليس سحريًا.
يمكنه التأكد مما إذا كان الـ proof يطابق الـ circuit المكتوب مسبقًا، لكن من أين تأتي البيانات، وهل لهذه القواعد معنى تجاريًا، وما إذا كانت الصلاحية ما تزال سارية الآن—كل ذلك يجب أن تحدده التطبيقات نفسها.
وأعتبر هذه الأمور طبيعية.
التشفير مهمته أن يجعل “البرهان” مُثبتًا بشكل صحيح، بينما المنتج مسؤول عن تحديد ما الذي سيفعله بهذا البرهان.
لا يزال DuskEVM في مرحلة Testnet، ولن أقول إن كامل سير عمل ZK أصبح ناضجًا لمجرد إضافة أداة verifier.
لكن مثل هذا التحديث على الأقل يكون أكثر واقعية من مجرد عبارة “يدعم ZK”.
وعادةً ما تكون الأشياء التي تجعل المطورين قادرين على استخدامها فعليًا هي تلك الواجهات التي تبدو غير مثيرة للانتباه.
خلال اليومين الماضيين، كنت أتابع @Dusk أحدث موجة من Developer Update، ويوجد تحديث أظنّه يستحق المشاهدة أكثر من عبارة “تمت إضافة ميزة ZK أخرى”.
zk-tools بدأت الآن في استكمال أدوات توليد والتحقق الخاصة بـ Groth16 Solidity verifier.
للوهلة الأولى يبدو الأمر صغيرًا.
لكن إذا كنت قد عملت فعلًا على تطبيقات ZK، فستعرف أن إعداد proof هو نصف الطريق فقط.
بعد ذلك تأتي مشكلة أكثر واقعية: كيف يتعرّف عقد Solidity على هذا الـ proof؟
وفقًا لقواعد تعريف الـ circuit: يقوم الـ prover بتوليد الـ proof، وعلى جهة EVM، يلزم وجود عقد verifier للتحقق من أن الـ proof والـ public inputs يطابقان القيود الأصلية.
إذا لم تُنجَز هذه الواجهة على نحو جيد، فحتى لو كانت التشفير قويًا جدًا، ستظل بعيدة عن معظم مطوري Solidity العاديين.
لذلك، وأنا أنظر إلى تحديث Dusk هذه المرة، فإن التركيز ليس على اسم Groth16 نفسه.
بل على أنه يكمل سلسلة:
proof → verifier → Solidity application
ضمن هذا الجزء الوسيط من السلسلة الهندسية.
وبالطبع، الـ verifier ليس سحريًا.
يمكنه التأكد مما إذا كان الـ proof يطابق الـ circuit المكتوب مسبقًا، لكن من أين تأتي البيانات، وهل لهذه القواعد معنى تجاريًا، وما إذا كانت الصلاحية ما تزال سارية الآن—كل ذلك يجب أن تحدده التطبيقات نفسها.
وأعتبر هذه الأمور طبيعية.
التشفير مهمته أن يجعل “البرهان” مُثبتًا بشكل صحيح، بينما المنتج مسؤول عن تحديد ما الذي سيفعله بهذا البرهان.
لا يزال DuskEVM في مرحلة Testnet، ولن أقول إن كامل سير عمل ZK أصبح ناضجًا لمجرد إضافة أداة verifier.
لكن مثل هذا التحديث على الأقل يكون أكثر واقعية من مجرد عبارة “يدعم ZK”.
وعادةً ما تكون الأشياء التي تجعل المطورين قادرين على استخدامها فعليًا هي تلك الواجهات التي تبدو غير مثيرة للانتباه.