مکانیسم اثبات آگاهی صفر: zkSNARK و zkSTARK

قدم اول: آشنایی با مکانیسم اثبات آگاهی صفر

در این مکانیسم، قصد این است که 2 شرکت کننده اصلی در فرآیند (اثباتگر و تاییدگر) میتوانند بر سر یک statement توافق کنند؛ به صورتی که اثباتگر از این statement آگاه است اما بدون اینکه بخواهد هیچگونه جزئیاتی از آن را در اختیار تاییدگر بگذارد، اثبات کند که به statement آگاه است.

تاییدگر بدون در اختیار داشتن خود statement یا جزئیاتی از آن، قادر نیست صحت یا عدم صحت آن را برای دیگری اثبات کند و تنها اثباتگر میتواند چنین کاری کند. با توجه به این موضوع، اگر اثباتگر کوچکترین آگاهی از statement داشته باشد، مکانیسم اثبات آگاهی صفر نقض میشود.

به زبان ساده در این مکانیسم، یک طرف به طرف دیگری اثبات میکند که از موضوعی آگاهی دارد بدون اینکه موضوع را بیان کرده یا انتقال دهد.

در پروتکلی که چنین مکانیسمی اعمال شود، پروتکل باید قادر باشد که یک سری input های تعاملی از سوی تاییدگر دریافت کند. این ورودی ها یک یا تعدادی چالش هستند که پاسخ آنها از سوی اثباتگر، تاییدگر را قانع میکند که اثباتگر درباره ی آن statement مذکور، صادق است. این حالت interactive zero-knowledge proof نام دارد.

یک سری non-interactive zero-knowledge proof نیز داریم که کارکرد آنها وابسته به مفروضات پردازش یافته (computational assumptions) است مثل هش های کریپتوگرافیک.

فرض، گذاره ایست که صحت و وقوع آن حتمیست؛ بدون آنکه نیاز به اثبات داشته باشد.

مثال هایی برای درک مکانیسم آگاهی صفر

1- غار علی بابا

غار علی بابا، یک ورودی داشته و دو دالان دارد که به هم متصل بوده و گرد هستند. بین این دو دالان دری وجود دارد که با یک کلمه رمز باز میشود. پگی به عنوان اثباتگر، رمز در را میداند و میخواهد به ویکتور که تاییدگر است، این موضوع را اثبات کند بدون اینکه رمز را به او لو بدهد.

پگی بدون اطلاع دادن به ویکتور وارد یکی از 2 دالان شده و کنار در توقف میکند. ویکتور مسیر عبور او را ندیده و نمیداند در دالان A قرار دارد یا B.

ویکتور به داخل غار آمده و بر سر دو راهی دالان ها ایستاده و به پگی دستور میدهد که از کدام دالان برگردد. پگی با دانستن رمز در، مشکلی برای عبور از هرکدام از دالان ها ندارد.

پگی از همان مسیری که ویکتور خواسته به دوراهی برمیگردد.

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

احتمال اینکه پگی در 10 بار تکرار این فرآیند هر بار به صورت شانسی نیازی به عبور از در نداشته باشد بسیار اندک است:

1/2 to the power 10 = 1/1024

2- دو توپ و فرد کور رنگ

دو توپ سبز و قرمز داریم و فردی کور رنگ که هیچ تمایزی بین این 2 نمیدهد. او اصلا شک دارد به این که هر 2 توپ یکسان اند. توپ ها را به او میدهیم تا پشت سرش، هر کدام را در یک دست بگذارد و یکی را به انتخاب خود نشان بدهد. فرد دیگر باید بگوید رنگ توپ چیست. فرد کور رنگ، دوباره توپ را پشت سرش برده و به دلخواه خود جابجا میکند یا نمیکند! شخص کور رنگ بار دیگر یک توپ را نشان داده و میپرسد که آیا توپ عوض شده یا خیر. فرد کور رنگ خودش میداند که توپی که نشان میدهد همان قبلیست یا نه، اما آگاهی ندارد که "آیا واقعا رنگ آن قرمز است یا سبز؟ رنگ دو توپ اصلا متفاوت است؟"

در تعداد تکرار بالای این فرآیند نیز، احتمال اینکه رنگ هر دو توپ یکی باشد بسیار پایین خواهد آمد.

قدم دوم: تکنولوژی های zkSNARK و zkSTARK

دو تکنولوژی برجسته در اثبات آگاهی صفر، zero-knowledge succinct non-interactive argument of knowledge و zero-knowledge scalable transparent argument of knowledge اند که به آنها میپردازیم.

هر دوی این تکنولوژی ها non-interactive بوده و میتوانند به صورت یک پیاده سازی شده و عمل کنند.

پایه امنیت در zkSNARK ها، کریپتوگرافی منحنی های بیضوی است. اینگونه کریپتوگرافی ها هرچند تصادفی بوده اما در مقابل محاسبات کوانتومی آسیب پذیر اند. یافتن کلید خصوصی از روی کلید عمومی تولید شده، هرچند کار آسانی نیست اما به وسیله محاسبات کوانتومی امکان پذیر است.

این تکنولوژی که آن را اثبات آگاهی صفر مختصر غیر تعاملی مینامیم، نیاز به یک ستاپ (setup) اولیه دارد.
در طی ستاپ اولیه یک جفت کلید prover-verifier ایجاد میشود که برای تامین امنیت نیاز است که کلید prover پس از ایجاد proof نابود شود. در این مکانیسم تنها یک proof و یک کلید تاییدگر خواهیم داشت و هزینه storage و verify به شدت کاهش میابد اما وجود یک کلید که باید نابود شود، محیط را از حالت trustless به سویی میبرد که برای از بین رفتن کلید نیاز به trust داشته باشیم.

اگر امنیت کلید prover به خطر بیفتد، میتوان با آن تراکنش های جعلی ساخت و به خاطر ویژگی های zkSNARK روشی برای اثبات جعلی بودن آن نیست.

از سوی دیگر، zkSTARK ها وابسته به توابع هش برای تامین امنیت اند و این موضوع آنها را در مقابل محاسبات کوانتومی مقاوم میکند، اما در عین حال، هزینه ها را تا 4 برابر SNARK ها برای تولید proof و نگهداری از آن افزایش میدهند. برای استفاده از STARK ها نیازی به ستاپ اولیه نیست و این موضوع، محیط را هر چه بیشتر امن و غیرمتمرکز میکند.

با این حال STARK ها اجازه میدهند تا محاسبات و نگهداری از proof ها به صورت off-chain انجام شده و سپس proof ها در هر زمان به صورت on-chain تایید شوند. این موضوع قابلیت مقیاس پذیری بالایی را در اختیار توسعه دهندگان قرار میدهد.

جداول مقایسه بین zkSNARK و zkSTARK در مقابل bulletproofs