لانگ‌فلو ZK وارد فرایند پذیرش IETF شد؛ با این پیش‌نویس مانند یک رابط در حال تغییر رفتار کنید

پیشنهاد لانگ‌فلو ZK گوگل از مرحله یک به‌روزرسانی معمولی مخزن فراتر رفته است: پیش‌نویس draft-google-cfrg-libzk-03 در ۲۵ سپتامبر وارد فراخوان دوهفته‌ای پذیرش گروه Crypto Forum Research Group در IETF شد و این فراخوان قرار است ۹ اکتبر ۲۰۲۶ پایان یابد.

این پیشنهاد یک استدلال دانایی صفرِ غیرتعاملی و فشرده را توصیف می‌کند که تکنیک‌های MPC-in-the-head از Ligero را با پروتکل محاسبه قابل‌راستی‌آزمایی مبتنی بر sumcheck ترکیب می‌کند. پیش‌نویس بر مدلی بدون راه‌اندازی مورداعتماد و بر ساختارهایی تمرکز دارد که می‌توان آن‌ها را از یک تابع هش مقاوم در برابر برخورد ساخت. همچنین رفتار transcript و سریال‌سازی، قیود مدار، استخراج چالش‌های Fiat–Shamir و کدگذاری اثبات را تعریف می‌کند؛ یعنی دقیقاً جزئیاتی که برای توسعه‌دهندگان به مرزهای ادغام تبدیل می‌شوند.

پیام فراخوان، لانگ‌فلو را برای دستگاه‌های محدود از نظر منابع معرفی می‌کند و نمونه‌هایی مانند راستی‌آزمایی امضای ECDSA، SHA-256 و ML-DSA، به‌علاوه مقایسه رشته، عدد صحیح و تاریخ و برخی پردازش‌های پایه را نام می‌برد. مخزن عمومی نیز این پروژه را یک کتابخانه C++ برای پروتکل‌های دانایی صفر پیرامون قالب‌های هویتی مانند ISO mDOC، JWT و اعتبارنامه‌های W3C معرفی می‌کند. این ترکیب پروژه را برای اعتبارنامه‌های حفظ‌کننده حریم خصوصی مهم می‌کند، اما به این معنا نیست که پیش‌نویس، استانداردی آماده برای کانسترهای ICP است.

برای سازندگان ICP، نتیجه فوری در مهندسی، انضباط در رابط است. اگر یک کانستر یا سرویس خارج از زنجیره با لانگ‌فلو آزمایش می‌کند، verifier را پشت یک adapter نسخه‌گذاری‌شده قرار دهید؛ نسخه دقیق پیش‌نویس، تعریف مدار، پروفایل هش و کدگذاری اثبات را ثابت کنید؛ و شناسه گزاره یا مدار را همراه هر اثبات ذخیره کنید. تصور نکنید اثباتی که بر اساس پیش‌نویس -03 تولید شده، با سندی که بعداً پذیرفته می‌شود سازگار خواهد ماند. کانستر باید ترتیب ورودی‌های عمومی و سریال‌سازی بایت‌ها را نیز داده‌ای حساس به اجماع بداند، چون یک اثبات از نظر رمزنگاری معتبر ممکن است در مرز برنامه شکست بخورد اگر دو پیاده‌سازی یک گزاره را متفاوت کدگذاری کنند.

ملاحظه سردبیری: لانگ‌فلو ZK هنوز یک Internet-Draft مستقل و فاقد جایگاه رسمی در فرایند استانداردسازی IETF است و فراخوان فعلی پذیرش قرار است ۹ اکتبر ۲۰۲۶ پایان یابد. بنابراین پیشنهاد و رابط‌های آن ممکن است تغییر کنند. ادعاهای پیام فراخوان درباره استقرارهای فعلی و پیاده‌سازی‌های خارجی در همان پیام گزارش شده‌اند و باید پیش از تصمیم‌های تولیدی جداگانه ارزیابی شوند.

توسعه مهم امروز، تکمیل استانداردسازی نیست؛ بلکه تبدیل‌شدن استانداردسازی به یک ریسک فعال سازگاری است. سازندگان می‌توانند اکنون طراحی را ارزیابی کنند، اما معماری تولیدی باید برای تغییر رابط اثبات جا باقی بگذارد.