EN
→ بازگشت به خبرخوان
شمارهٔ ۰۴۲۳ZK Tech۲ دقیقه۲ منبع

zkTLS ادعای قوی‌تری می‌سازد: اثبات تعامل وب، نه فقط پاسخ

یک پیش‌چاپ جدید در حوزه zkTLS پیشنهاد می‌کند به‌جای اثبات صرفِ دانستن یک جفت ورودی و پاسخ، واقعی‌بودن اجرای پروتکل و دریافت پاسخ از طرف مقابل نیز اثبات شود؛ تمایزی مهم برای برنامه‌هایی که داده‌های وب را به ICP می‌آورند.

اشتراک‌گذاری
فناوری صفر-دانش (ZK)
zkTLS ادعای قوی‌تری می‌سازد: اثبات تعامل وب، نه فقط پاسخ
تصویر: تولید هوش مصنوعی

مهم‌ترین تغییر تازه در zkTLS بیشتر معنایی است تا صرفاً مربوط به سرعت تولید proof. مقاله‌ای در Cryptology ePrint در سپتامبر ۲۰۲۶ مفهوم «اثبات دانش صفرِ اجرای پروتکل» یا zkPoPE را معرفی می‌کند. بر اساس این مفهوم، verifier باید بداند که کاربر واقعاً با یک طرف مشخص تعامل کرده و پاسخی مطابق یک گزاره دریافت کرده است، بدون آن‌که ورودی خصوصی یا کل پاسخ را ببیند.

این ایده یک ضعف ظریف در طراحی‌های ساده‌تر را هدف می‌گیرد. اثبات این‌که یک ورودی و پاسخ با رابطه‌ای مشخص سازگارند، به‌تنهایی نشان نمی‌دهد پاسخ از وب‌سایت واقعی یا از یک اجرای زنده آمده است. zkPoPE هدف امنیتی را از لایه انتقال TLS به سطح پروتکل کاربردی می‌برد. نویسندگان این هدف را به‌صورت یک functionality ایده‌آل UC صورت‌بندی کرده‌اند و Reclaim را پروتکلی معرفی می‌کنند که تحت یک مدل اعتماد منطبق با استقرار، برای تحقق آن طراحی شده است.

این تغییر برای توسعه‌دهندگان ICP که می‌خواهند factهای احراز‌شده وب را به canister یا رابط کاربری خود وارد کنند، پیام عملی دارد. یک integration مناسب باید predicate دقیق—برای مثال وضعیت حساب، صلاحیت یا یک بازه عددی—را تعریف کند، آن را به سرویس وب و context درخواست موردنظر گره بزند و داده کافی برای verification مستقل نگه دارد. مستندات Reclaim مرز پیاده‌سازی را روشن می‌کند: گزینه‌های عمومی و خصوصی درخواست جدا می‌شوند، proof با SDK قابل بررسی است و داده proof برای استفاده on-chain قابل تبدیل است.

معیار گزارش‌شده نیز مشخص است: مقاله می‌گوید Reclaim روی یک گوشی رده‌متوسط پایین، پاسخی ۱۲۰۰ کیلوبایتی را در ۷٫۲۸ ثانیه attest کرده است. این عدد به‌معنای تضمین همین عملکرد در هر deployment روی ICP نیست؛ بلکه نشان می‌دهد attestation پاسخ‌های بزرگ به‌عنوان یک مسئله سیستمی سنجیده می‌شود، نه صرفاً یک دموی کوچک.

برای ICP، اصل طراحی پیشنهادی ساده است: canister باید یک claim محدود و context آن را بررسی کند، نه این‌که یک گواهی عمومی با عنوان «این داده معتبر است» را بپذیرد. منبع، درخواست، تازگی داده، اتصال به subject و سیاست verifier را صریح نگه دارید. اگر سامانه فقط یک جفت ارضاکننده را اثبات کند، هنوز provenance را اثبات نکرده است.

ملاحظه: مقاله اصلی zkTLS یک پیش‌چاپ منتشرشده در سپتامبر ۲۰۲۶ است و شواهد داوری‌شده‌ای درباره امنیت تولیدی ارائه نمی‌کند. ملاحظه: طراحی Reclaim به یک مدل اعتماد منطبق با استقرار و credentials برنامه وابسته است؛ بنابراین ادغام آن با canisterهای ICP، فرض‌های اعتماد عملیاتی را حذف نمی‌کند.

برچسب‌هافناوری ZKzkTLSICPپروتکل Reclaim
منابع مستند۲ مرجع
  1. [۰۱]Rethinking Zero-Knowledge TLS: Proof of Protocol Execution and the Reclaim Protocoleprint.iacr.org ↗
  2. [۰۲]Reclaim Protocol zkFetch Usage Documentationdocs.reclaimprotocol.org ↗
خواندنی بعدی

خبرخوان را در ایمیل بگیرید

هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.

خوراک RSS در دسترس · بدون هرزنامه