Zk-SNARKها – یک نمونه واقعی و بررسی عمیق دانش صفر

خوش آمدید! بیایید کمی عمیق‌‌تر به zk-SNARKها بپردازیم.

یادآوری سریع: در یک zk-SNARK دو طرف اصلی وجود دارند، یکی اثبات‌‌کننده و دیگری تایید‌‌کننده. اثبات‌‌کننده با استفاده از یک zk-SNARK می‌‌خواهد به تایید‌‌کننده درباره‌‌ یک اعلامیه‌‌ دانش، بدون اینکه نوع دقیق آن را برای او شفاف کند، تضمین بدهد.

zk-SNARK چیست؟

پیش از پرداختن به نمونه‌‌ی فنی‌‌تر، بیایید اول درباره ویژگی‌‌های لازم برای یک zk-SNARK صحبت کنیم:

کامل بودن: اگر اعلامیه صحیح باشد و تاییدکننده و اثبات‌‌کننده صادق باشد، اثبات پذیرفته می‌‌شود.

صحت: اگر اعلامیه درست نباشد، یک اثبات‌‌کننده‌‌ متقلب نمی‌‌تواند تایید‌‌کننده‌‌ صادق را قانع کند که اعلامیه درست است (مگر به احتمال بسیار کم).

یک zk-SNARK علاوه بر موارد بالا باید شرایط زیر را هم داشته باشد:

دانش صفر: اگر اعلامیه درست باشد، تاییدکننده چیزی غیر از صحت اعلامیه نخواهد دانست.

مختصر: اندازه اثبات باید آنقدر کوچک باشد که بتواند طی چند میلی‌‌ثانیه تایید شود.

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

استدلال: یک اثبات صحیح و درست از نظر رایانشی: صحت اعلامیه علیه اثبات‌‌کننده‌‌ی که قصد تقلب در زمان و رایانش را داشته باشد می‌‌ایستد.

دانش: اثبات باید بدون دسترسی به شاهد ایجاد شده باشد (ورودی خصوصی موردنیاز برای اثبات اعلامیه).

حالا که شرایط بالا را دانستیم بیایید نمونه‌‌ای از zk-SNARK را بررسی کنیم و بفهمیم که چطور با ترکیب با یک بلاک چین به کارگرفته می‌‌شود. با استفاده از اولین مثال بین باب و آلیس در مطلب #۱: آلیس می‌‌خواهد از حساب بانکی خود به حساب دیگری پول انتقال دهد و به باب برای شروع انتقال نیاز دارد. بیایید نحوه اجرای این سناریو با استفاده از zk-SNARK و یک بلاک چین را توصیف کنیم.

نکته: مثال پایین مقیاس‌‌پذیر نیست اما دید کلی خوبی از نحوه رجوع به یک zk-SNARK به ما می‌‌دهد.

چهار بازیگر سناریوی ما:

۱. آلیس: اثبات‌‌کننده

۲. بانک Acme: تاییدکننده به این واسطه برای انجام تراکنش حساب بانکی و یک واسط دیگر برای راه‌‌اندازی zk-SNARK اعتماد کرده است.

۳. باب: نماینده مرکز تماس بانک Acme

۴. سرویس هویت خودمدیریتی: ارائه‌‌کننده داده‌‌ی اطلاعات دیجیتال هویت به اپلیکیشن بانک Acme و یک واسطه ثالث برای راه‌‌اندازی zk-SNARK.

در پایین نموداری می‌‌بینید که چگونگی انتقال پول توسط آلیس از یک حساب بانکی به حساب بانکی دیگر، بدون دادن اطلاعات هویتی او به باب در بانک را توضیح می‌‌دهد:

۱. بلاک چینی بسازید که قابلیت قرارداد هوشمند در آن وجود داشته باشد، برای این مثال بیایید از نمونه اتریوم استفاده کنیم.

برنامه‌‌ای ساخته می‌‌شود که اگر برنامه به مورد صحیحی بربخورد «۱» را ارسال خواهد کرد.

۲ الف. ورودی شامل ورودی‌‌های عمومی است که توسط چندین طرف استفاده می‌‌شود (آلیس، بانک، سرویس هویت) و ورودی‌‌های خصوصی (رازها و شواهد) ک تنها اثبات‌‌کننده (آلیس) آنان را ارائه می‌‌کند.

۲ الف (۱): عمومی: نام، شماره تلفن، آدرس دیجیتال هویتی بلاک چین، گواهی بانکی مبنی بر اینکه آلیس صاحب حساب است (با تایم‌‌آوت ۱ ساعته).

۲ الف (۲): خصوصی (آلیس یا سرویس هویتی): شمار امنیت اجتماعی (SSN)، تاریخ دولت (DOB).

۲ الف (۳): (فقط آلیس): رمز سری

ب. پارامترهای zk-SNARK را تنظیم کرده و کلیدهای اثبات‌‌کننده و تاییدکننده را ایجاد کنید.

۲ ب. از رایانش چندطرفی (MPC) بین سرویس هویتی و بانک Acme برای تولید پارامترهای عمومی و نصب zk-SNARK استفاده کنید. MPC امکان شرکت طرفین متععدی را در فرایند راه‌‌اندازی برای تولید پارامترهای zk-SNARK را فراهم می‌‌کند که خود همین باعث به حداقل رساندن ریسک می‌‌شود. اگر یکی از کاربرانی که در مرحله راه‌‌اندازی شرکت می‌‌کند سازش نکند، پارامترهای تولیدشده امن هستند. اگر همه‌‌ی کاربرانی که در فرایند راه‌‌اندازی شرکت دارند سازش کنند، پارامترها می‌‌توانند برای ایجاد اثبات‌‌های غلط به کار گرفته شوند و ارزش فرایند zk-SNARK از بین می‌‌رود.

۲ ج: کلیدهای تاییدکننده و برنامه تاییدکننده در قرارداد هوشمندی که در نمونه‌‌ی بلاک چین اتریوم به عنوان نمونه وارد شده است، ادغام می‌‌شوند.

۳. آلیس اپلیکیشن بانک Acme را باز می‌‌کند، از اثر انگشت خود برای تایید هویت خود استفاده کرده و سپس به آن وارد می‌‌شود.

۳ الف: او به قسمت «تماس با ما» در اپلیکیشن می‌‌رود و دکمه‌‌ی «تماس با Acme با قرار قبلی» را می‌‌زند.

۳ الف (۱): پس از اینکه آلیس این دکمه را زد در پشت پرده اتفاقاتی می‌‌افتد: ۱) درخواستی از اپلیکیشن بانک آلیس به خود بانک ارسال می‌‌شود و می‌‌پرسد که آیا آلیس هنوز مشتری بانک است. ۲) بانک Acme هم تراکنشی با ذکر اینکه آلیس هنوز مشتری بانک است به بلاک چین می‌‌فرستند.

۳ الف (۲): در اپلیکیشن از آلیس سوالاتی پرسیده می‌‌شود (شماره امنیت اجتماعی و تاریخ تولد) و برخی از این سوال‌‌ها هم با ارائه‌‌ی داده به اپلیکیشن بانک مانند سرویس هویت، از طریق هویت دیجیتال قابل پاسخ‌‌گویی است:

۳ الف (۲) ۱: شماره امنیت ملی شما چیست؟ پاسخ آلیس: ۱۲۳-۴۵-۶۷۸۹

۳ الف (۲) ۲: تاریخ تولدتان را وارد کنید؟ پاسخ آلیس ۱/۱/۲۰۰۰

۳ الف (۲) ۳: رمز سری شما چیست؟ پاسخ آلیس: ۷۲۲۷؛ چرا رمز سری؟ این برای مواردی است که فردی به اپلیکیشن دست پیدا کند و از امکان هویت دیجیتال برای جمع کردن پاسخ‌‌ها برای شماره امنیت اجتماعی و تاریخ تولد استفاده کند و سپس بخواهد به جای آلیس با بانک ارتباط برقرار کند کاربرد دارد. رمز سری به عنوان آخرین مانعی به کار گرفته می‌‌شود که توسط هیچ‌‌کس برای تایید هویت پیدا شود.

۴. پاسخ‌‌های آلیس با ورودی‌‌های عمومی نام، شماره تلفن، آدرس عمومی هویت دیجیتال او و گواهی بانک مبنی بر اینکه آلیس در حال حاضر مشتری بانک است ادغام می‌‌شود تا اثبات دانش صفر (zk-SNARK) تولید شود.

۴ الف: اثبات به قرارداد هوشمند تایید در بلاک چین فرستاده می‌‌شود.

۵. قرارداد هوشمند عبارت «صحیح» را در پاسخ می‌‌فرستد و بانک هم در لیست‌‌های خود در سیسم‌‌های داخلی به دنبال عبارت صحیح می‌‌گردد.

۶. حالا دکمه‌‌ای در اپلیکیشن موبایل برای آلیس هست که با آن با بانک تماس بگیرد. آلیس دکمه را می‌‌زند و به نماینده بانک یعنی باب وصل می‌‌شود تا انتقال بانکی را شروع کند.

مثال بالا توضیحی از روش کار zk-SNARK در زمانی است که آلیس قصد تماس با بانک Acme برای شروع عملیات انتقال از حسابی به حساب دیگر را دارد. در مثال بالا نیاز به در میان گذاشتن اطلاعات حساس با باب وجود ندارد و زمان میانگین پاسخ برای بانک Acme را هم کاهش می‌‌دهد که خود همین امر هزینه‌‌ها را کاهش می‌‌دهد (بازی برد برد هم برای آلیس و هم برای بانک).

واسطه و اثبات مشتری کنونی

یکی از عناصر کلیدی مثال بالا درباره zk-SNARK در دنیای واقعی، گواهی بانک برای حساب آلیس در بانک Acme است. این یک عنصر کلیدی است که اغلب در زمان ارائه مثال درباره zk-SNARKها نادیده گرفته می‌‌شود. وقتی یک واسطه وجود دارد که باید در فرایند zk-SNARK دخیل شود، این امر چطور حاصل خواهد شد؟ رویکردهای مختلفی می‌‌تواند وجود داشته باشد، با این حال می‌‌توانیم از دید اثبات وجود به این مسئله رجوع کنیم، یعنی اثبات مشتری کنونی (Proof of Current Customer) را اجرا کنیم که امکان اجرای واقع‌‌گرایانه‌‌تری از مثال بالا را به وجود می‌‌آورد.

اثبات مشتری کنونی می‌‌تواند به شکل زیر برای بانک Acme کار کند:

وقتی اول آلیس مشتری بانک می‌‌شود یا از قبل مشتری بانک است، بانک با ارسال یک تراکنش به آدرس هویت دیجیتال آلیس در بلاک چین مربوطه، گواهی مربوط به مشتری بودن آلیس را صادر می‌‌کند (تراکنش حاوی داده‌‌های رمزنگاری شده‌‌ای است که اپلیکیشن بانک Acme آلیس برای نشان داده اینکه آلیس مشتری بانک است می‌‌خواند).

هویت صادرکننده (بانک Acme) توسط بررسی آدرس عمومی Acme تایید می‌‌شود. در بلاک چین، یک محل ثبت آدرس عمومی در قرارداد هوشمند وجود دارد که آدرس‌‌های عمومی و هویت‌‌های مربوط به آن را ذخیره می‌‌کند، بنابراین بانک Acme می‌‌تواند به عنوان صادرکننده گواهی اصلی شناسایی شود. این محل ثبت تنها توسط افراد خاص یا سازنده ثبت قرارداد قابل بروزرسانی است.

سپس تراکنش جدیدی از بانک Acme به آدرس هویتی دیجیتال عمومی الیس با داده‌‌های رمزنگاری شده ارسال می‌‌شود که تایید می‌‌کند آلیس مشتری بانک است و می‌‌تواند بدون قرار قبلی طی ۶۰ دقیقه با بانک تماس بگیرد.

نکته: چندین روش برای مواجهه با مورد بالا وجود دارد. مثلا به جای استفاده از تراکنش‌‌های ساده، می‌‌توانیم از اسناد ذخیره‌‌شده در یک سیستم ذخیره‌‌سازی غیرمتمرکز استفاده کنیم که داده‌‌های مربوط را نگهداری می‌‌کند و می‌‌تواند برای تایید داده‌‌های زیرساختی تراکنش و امضای دیجیتال بانک Acme به کار گرفته شود.

در مثال بالا، الیس می‌‌توانست بدون به اشتراک گذاشتن اطلاعات خود با باب در بانک Acme ارتباط برقرار کند و انتقال پول از حسابی به حساب دیگر را مجاز کند. zk-SNARKها و بلاک چین‌‌ها هردو می‌‌توانند به هم خیلی خوب کار کنند: حفظ حریم خصوصی، امنیت و شفافیت تبادل و تایید اطلاعات.

zk-SNARKها علاوه بر سناریوی بالا، می‌‌توانند در جاهای دیگری هم استفاده شوند، از جمله:

۱. تایید رایانش (متمرکز و غیر متمرکز)

۲. رمز ارزهای ناشناس یا رمز ارزهایی که می‌‌توانند بکارگیری zk-SNARKها در قراردادهای هوشمند را ممکن کنند، مانند زی کش و اتریوم.

۳. اثبات منشا بین بلاک چین‌‌های عمومی/خصوصی (به جای ثبت کل داده‌‌های یک تراکنش که در بلاک چین خصوصی بر یک بلاک چین عمومی اتفاق می‌‌افتد، یک اثبات می‌‌تواند بر روی یک بلاک چین عمومی ذخیره شود. این شرکت‌‌ها را قادر به امن نگه داشتن داده‌‌های حساس و اثبات منشا یک تراکنش خاص می‌‌کند).

۴. مجاز کردن بدون نیاز به رمز (همانطور که در مثال آلیس و باب گفتیم)

۵. اشتراک‌‌گذاری اطلاعات درباره هویت یک فرد، مثلا: آلیس > 21 است، درست است یا غلط؟ (سن مشخص نمی‌‌شود). یک zk-SNARK می‌‌تواند برای اثبات اینکه آلیس بیشتر از ۲۱ سال سن دارد لازم است همزمان اعتماد بین طرفین دخیل را هم کاهش می‌‌دهد.

استفاد‌‌ه‌‌ وسیع‌‌تر از zk-SNARKها می‌‌تواند روش ذخیره‌‌سازی داده‌‌ها را تغییر دهد. شاید شرکت‌‌ها نیازی به نگه داشتن داده‌‌های چندانی درباره‌‌ مشتریان و کاربران خود نداشته باشند، کما این‌‌که الان هم همینطور است. سازمان‌‌ها در آینده می‌‌توانند با بلاک چین‌‌ها تعامل داشته باشند و از اثبات دانش صفر برای برقراری ارتباط با فرایندهای کنونی استفاده کنند و در پی همین امر نشت داده کاهش پیدا می‌‌کند، حریم خصوصی داده‌‌های کاربر ارتقا پیدا خواهد کرد و خطر موجود برای سازمان‌‌ها کاهش پیدا خواهد کرد. اشتراک‌‌گذاری داده‌‌های محرمانه بین مردم هم کاهش بیشتر خواهد یافت. بکارگیری اثبات دانش صفر و سرویس هویت هم به کاربران امکان محافظت بیشتر از داده‌‌ها و به حداقل رساندن افشا شدن داده را فراهم می‌‌کند، چون شرکت‌‌هایی که ابعاد مهمی از داده‌‌های هویت فرد را در اختیار دارد کم کم از میان می‌‌روند.

یکی از بخش‌‌های کلیدی که باید برای افزایش اعتماد بین‌‌ کاربران zk-SNARK بهبود پیدا کند، حذف مرحله‌‌ راه‌‌اندازی است. تحقیقات مداومی در رمزنگاری دانش صفر در حال انجام است و تکنولوژی‌‌هایی مثل ZK-STARKS هم برای برداشتن این مرحله واسطه‌‌ای توسعه داده می‌‌شوند که همین امر باعث بهتر شدن فرایند استفاده از رمزنگاری دانش صفر برای ارائه‌‌ی اثبات دانش است. در مطلب بعدی به ZK-STARKها خواهم پرداخت.

امیدوارم همه شما از این مطلب درباره‌‌ zk-SNARK لذت برده باشید. اگر هر پرسشی درباره‌‌ی این مطلب و مطالب پیشین این مجموعه دارید، می‌‌توانید به ایمیل من به آدرس [email protected] ارسال کنید.

بررسی عمیق‌‌تر تماس آلیس و باب پیش از نمونه‌‌ اهدای دسترسی – ورودی‌‌ها و خروجی‌‌های برنامه‌‌ی ZL-SNARK:

برای کسانی که به دانستن شکل اساسی برنامه‌‌ zk-SNARK علاقه دارند، می‌‌خواهم مثال زیر را بر اساس مثال آلیس و باب در بالا توضیح دهم.

zk-SNARKها با اعداد کار می‌‌کنند، پس باید ورودی‌‌های رشته‌‌ای را به اعداد تبدیل کنیم (می‌‌توانید از این سایت برای تبدیل رشته‌‌های متنی به عدد استفاده کنید https://cryptii.com/decimal-text).

نام عمومی: آلیس؛ از طریق تبدیل‌‌کننده‌‌‌‌ی Unicode برای به دست آوردن عدد مقابل اجرا کنید: ۶۵ ۱۰۸ ۱۰۵ ۹۹ ۱۰۱، همه فاصله‌‌ها را حذف کنید تا این به دست بیاید: ۶۵۱۰۸۱۰۵۹۹۱۰۱.

شماره تلفن عمومی (۵۵۵-۶۶۶-۷۷۷۷)؛ از طریق تبدیل‌‌کننده‌‌‌‌ی Unicode برای به دست آوردن عدد مقابل اجرا کنید: ۵۳ ۵۳ ۴۵ ۵۴ ۵۴ ۵۴ ۴۵ ۵۵ ۵۵ ۵۵ ۵۵، فاصله‌‌ها را بردارید تا عدد مقابل به دست بیاید: ۵۳۵۳۵۳۴۵۵۴۵۴۵۴۴۵۵۵۵۵۵۵۵۵.

آدرس عمومی بلاک چین: 0x4ef377462b03b750d52140c482394a6703d0d338؛ از طریق تبدیل‌‌کننده‌‌‌‌ی Unicode برای به دست آوردن عدد مقابل اجرا کنید: ۰ ۴۸ ۱۲۰ ۵۲ ۱۰۱ ۱۰۲ ۵۱ ۵۵ ۵۵ ۵۲ ۵۴ ۵۰ ۹۸ ۴۸ ۵۱ ۹۸ ۵۵ ۵۳ ۴۸ ۱۰۰ ۵۳ ۵۰ ۴۹ ۵۲ ۴۸ ۹۹ ۵۲ ۵۶ ۵۰ ۵۱ ۵۷ ۵۲ ۹۷ ۵۴ ۵۵ ۴۸ ۵۱ ۱۰۰ ۴۸ ۱۰۰ ۵۱ ۵۱ ۵۶، فاصله‌‌ها را حذف کنید و عدد مقابل به دست می‌‌آید: ۰۴۸۱۲۰۵۲۱۰۱۱۰۲۵۱۵۵۵۵۵۵۲۵۴۵۰۹۸۴۸۵۱۹۸۵۵۵۳۴۸۱۰۰۵۳۵۰۴۹۵۲۴۸۹۹۵۲۵۶۵۰۵۱۵۷۵۲۹۷۵۴۵۵۴۸۵۱۱۰۰۴۸۱۰۰۵۱۵۱۵۶.

تهیه گواهی عمومی بانک و تماس: الف) راه‌‌اندازی اولیه: بانک Acme یک تراکنش به آدرس عمومی هویت دیجیتال آلیس را با داده‌‌هایی که نشان می‌‌دهد آلیس مشتری بانک است می‌‌فرستد. این تراکنش وقتی رخ می‌‌دهد که آلیس حساب را باز کند یا وقتی که حساب خود را در اپلیکیشن موبایل بانک Acme برای اولین بار ثبت و تایید کند. ب) وقتی آلیس پیش از فرایند تایید تماس برقرار می‌‌کند، بانک تراکنش‌‌های حساب هویت دیحیتال آلیس را برای تراکنشی از سوی بانک Acme که شان دهد آلیس پیشتر مشتری بانک بوده است بررسی می‌‌کند. اگر تراکنشی پیدا شود بانک تراکنشی به همراه داده‌‌های رمزنگاری شده‌‌ای به آدرس آلیس ارسال می‌‌کند که نشان می‌‌دهد آلیس مشتری کنونی بانک است. تلفن آلیس حواسش به تراکنش‌‌های جدیدی که از بانک می‌‌رسد هست و به محظ پیدا کردن تراکنش، داده‌‌ها را از تراکنش کنونی می‌‌کشد، داده‌‌ها را رمزنگاری و هش‌‌گذاری می‌‌کند. داده‌‌ی هش‌‌گذاری‌‌شده با استفاده از رشته‌‌ Unicode به عدد زیر تبدیل می‌‌شود:

۴۹۶۶۵۶۶۷۶۸۶۶۶۷۵۴۵۴۵۲۵۰۵۲۴۹۵۳۴۸۵۲۷۰۶۶۴۸۵۳۶۸۵۱۷۰۵۵۵۰۵۳۶۸۶۵۴۸۵۲۵۰۵۵۵۶۶۵۴۸۴۹۶۸۶۵۵۴۵۵۶۶۵۴۵۲۵۶۵۵۵۲۶۹۵۳۵۶۶۶۶۹۶۹۷۰۵۶۵۲۶۵۶۵۵۵۵۷۵۳۶۶۵۶۷۰.

شماره خصوصی امنی اجتماعی: ۱۲۳-۴۵-۶۷۸۹ است که به صورت ورودی ۱۲۳۴۵۶۷۸۹ درمی‌‌آید.

تاریخ تولد خصوصی: ۱/۱/۲۰۰۰؛ ورودی: ۱۱۲۰۰۰

ورودی رمز سری: ۷۳۲۷

ورودی‌‌های عمومی و خصوصی در برنامه‌‌ زیر قرار داده می‌‌شوند که ورودی‌‌های عمومی را با آنچه در برنامه‌‌ی zk-SNARK نوشته شده است مقایسه می‌‌کند. اگر درست باشند برنامه جمع شماره امنیت اجتماعی و تاریخ تولید را در رمز سری ضرب می‌‌کند تا شماره هدف به دست آید. اگر آن شماره با شماره برنامه ZK-SNARK یکی باشد (۹۰۵۳۸۸۵۱۷۰۰۳)، برنامه با ارسال ۱ پاسخ می‌‌دهد. کد زیر که با ZoKrates نوشته شده است مثالی ارائه می‌‌کند:

کد ZoKrates برای مثال zk-SNARK

۱۰. پس از اینکه برنامه اجرا شد، اثباتی تولید می‌شود که شبیه تصویر زیر است:

خروجی zk-SNARK از ZoKrates

۱۱. سپس اثبات بالا در کنار ورودی‌‌های عمومی به قرارداد هوشمند تایید فرستاده می‌‌شود. اگر همه اطلاعات درست باشد، قرارداد پاسخ «درست» می‌‌فرستد. قرارداد تایید کلید تایید را در درون خود دارد و بر همین اساس می‌‌‌‌تواند از ورودی‌‌های عمومی و اثبات ارائه‌‌شده تعیین کند.