اكتشفت أن هناك تغييرًا تقنيًا تم دمجه في الفرع الرئيسي لـDusk من PLONK. يتمثل التعديل في مسار إلغاء تسلسل ملف الدائرة المضغوطة: بعد أن يتم تحليل نص الرسالة بالكامل، إذا بقيت بايتات زائدة، فإن compile_with_compressed سيرجع InvalidCompressedCircuit. وأضافت اختبارات الرجوع الرسمية تحديدًا قيمة ذيلية شرعية لـ MessagePack للتحقق من أنه قبل الإصلاح كان يُقبَل، وبعد الإصلاح سيتم رفضه.
لنفس الدائرة المضغوطة، يكون نص الرسالة مطابقًا تمامًا، وفي النهاية يتم إدخال بايت غير ذي صلة واحد فقط. أي نظام رقابة أو تخزين مؤقت يحسب التجزئة اعتمادًا على البايتات الأصلية سيعتبرها ملفًا آخر؛ بينما قد يظل الإصدار القديم من PLONK قادرًا على قراءتها بشكل طبيعي.
عندما وصلت إلى هنا، شعرت بقلق قليلًا. الملف تغيّر بالفعل، ومع ذلك تقول أداة التحقق: “لم يتغير”. بالنسبة للأنظمة المالية، هذا مزعج أكثر من مجرد ظهور خطأ مباشر: يوجد لشيء واحد، في الوقت نفسه، بطاقتا هوية.
سأوضح نقطة الهدف أولًا. التغيير هذه المرة يتعلق بملف الدائرة المضغوطة المستخدم في توليد الإثباتات، وليس ضمن نطاق الإثباتات التي تم توليدها بالفعل على السلسلة. المعالجة الجديدة التي دمجها Dusk كانت حاسمة جدًا: بعد قراءة جسم الدائرة، إذا وُجدت بايتات زائدة في الخلف، فإن كامل الملف يُحكم عليه بأنه غير صالح.
بصراحة، كان لدي في البداية انطباع أنها تضع تدقيقًا زائدًا. طالما أن الأداة القديمة تعمل، فلماذا نقطع التوافق لأجل بضعة بايتات ذيلية؟ لكن حين وضعتها في سياق نظام المعاملات، تغيرت الفكرة. إذا تم التعرف على الملف الأصلي عبر التدقيق أو التخزين المؤقت أو مستودع الإصدارات وفقًا للبايتات، بينما يقوم المترجم بمعاملة ملفين مختلفين كحزمة واحدة من القواعد، فحين تنشأ مشكلة يصعب جدًا توضيح أي نسخة تم استخدامها بالفعل.
وهذا يمنحني معيارًا عمليًا جدًا: بعد الترقية، إذا فشلت بعض تطبيقات ZK فجأة، فابدأ بالتحقق من InvalidCompressedCircuit، وإصدار الأداة، وما إذا كان يمكن الاستعادة بعد إعادة التصدير. إذا فشل الملف القديم ونجح الملف الجديد، فهذا غالبًا يشير إلى انتقال صيغ؛ أما إذا فشلت الملفات المعيارية على نطاق واسع، فحينها يلزم تعميق البحث في منطق الإثبات أو أعطال الشبكة. لا تخلط بين نوعي المخاطر على نفس الخط.
بالنسبة لـ$DUSK ، فإن هذا التشديد على المدى القصير قد يقلل من نجاح الاستدعاءات، وربما يجعل الأدوات القديمة تتوقف لفترة. أما على المدى الطويل، فالقيمة تعتمد على ما إذا كانت عمليات انتقال المنبع قد خفضت تكاليف فشل الإثبات أو الجدل حول الإصدارات أو مراجعة المؤسسات. لن يقوم المُحلِّل مباشرةً بإنشاء مشترين. كل ما يمكنه فعله هو أن تجعل كل دائرة تُعترف بهوية واحدة فقط.
في المعاملات، لن أعتبر “قابلية القراءة قدر الإمكان” أمرًا ودودًا؛ فأنا أعتقد أن الدفاتر المالية تحتاج إلى تفرد قانوني. DYOR！
#dusk $DUSK @Dusk
لنفس الدائرة المضغوطة، يكون نص الرسالة مطابقًا تمامًا، وفي النهاية يتم إدخال بايت غير ذي صلة واحد فقط. أي نظام رقابة أو تخزين مؤقت يحسب التجزئة اعتمادًا على البايتات الأصلية سيعتبرها ملفًا آخر؛ بينما قد يظل الإصدار القديم من PLONK قادرًا على قراءتها بشكل طبيعي.
عندما وصلت إلى هنا، شعرت بقلق قليلًا. الملف تغيّر بالفعل، ومع ذلك تقول أداة التحقق: “لم يتغير”. بالنسبة للأنظمة المالية، هذا مزعج أكثر من مجرد ظهور خطأ مباشر: يوجد لشيء واحد، في الوقت نفسه، بطاقتا هوية.
سأوضح نقطة الهدف أولًا. التغيير هذه المرة يتعلق بملف الدائرة المضغوطة المستخدم في توليد الإثباتات، وليس ضمن نطاق الإثباتات التي تم توليدها بالفعل على السلسلة. المعالجة الجديدة التي دمجها Dusk كانت حاسمة جدًا: بعد قراءة جسم الدائرة، إذا وُجدت بايتات زائدة في الخلف، فإن كامل الملف يُحكم عليه بأنه غير صالح.
بصراحة، كان لدي في البداية انطباع أنها تضع تدقيقًا زائدًا. طالما أن الأداة القديمة تعمل، فلماذا نقطع التوافق لأجل بضعة بايتات ذيلية؟ لكن حين وضعتها في سياق نظام المعاملات، تغيرت الفكرة. إذا تم التعرف على الملف الأصلي عبر التدقيق أو التخزين المؤقت أو مستودع الإصدارات وفقًا للبايتات، بينما يقوم المترجم بمعاملة ملفين مختلفين كحزمة واحدة من القواعد، فحين تنشأ مشكلة يصعب جدًا توضيح أي نسخة تم استخدامها بالفعل.
وهذا يمنحني معيارًا عمليًا جدًا: بعد الترقية، إذا فشلت بعض تطبيقات ZK فجأة، فابدأ بالتحقق من InvalidCompressedCircuit، وإصدار الأداة، وما إذا كان يمكن الاستعادة بعد إعادة التصدير. إذا فشل الملف القديم ونجح الملف الجديد، فهذا غالبًا يشير إلى انتقال صيغ؛ أما إذا فشلت الملفات المعيارية على نطاق واسع، فحينها يلزم تعميق البحث في منطق الإثبات أو أعطال الشبكة. لا تخلط بين نوعي المخاطر على نفس الخط.
بالنسبة لـ$DUSK ، فإن هذا التشديد على المدى القصير قد يقلل من نجاح الاستدعاءات، وربما يجعل الأدوات القديمة تتوقف لفترة. أما على المدى الطويل، فالقيمة تعتمد على ما إذا كانت عمليات انتقال المنبع قد خفضت تكاليف فشل الإثبات أو الجدل حول الإصدارات أو مراجعة المؤسسات. لن يقوم المُحلِّل مباشرةً بإنشاء مشترين. كل ما يمكنه فعله هو أن تجعل كل دائرة تُعترف بهوية واحدة فقط.
في المعاملات، لن أعتبر “قابلية القراءة قدر الإمكان” أمرًا ودودًا؛ فأنا أعتقد أن الدفاتر المالية تحتاج إلى تفرد قانوني. DYOR！
#dusk $DUSK @Dusk