امنیت و عملکرد SNARK

SNARK (استدلال دانش غیر تعاملی مختصر) یک ابزار رمزنگاری است که امکانات جدید هیجان انگیزی را در طراحی سیستم، به ویژه در تنظیمات غیرمتمرکز باز می کند. SNARK ها اجازه می دهند داده ها توسط نهادهای نامعتبر پردازش شوند، که سپس می توانند ثابت کنند که داده ها معتبر هستند و به درستی پردازش شده اند. یک راه ساده‌لوحانه برای اثبات این امر، انتشار داده‌ها است، به هر کسی که می‌خواهد اعتبار آن را بررسی کند و مستقیماً آن را پردازش کند. 

SNARK به همان اثر می رسد، اما با هزینه بهتربه تایید کنندگان. به عنوان مثال، در یک مجموعه لایه دو (L2) قابل تأیید، یک سرویس جمع‌آوری تراکنش‌های زنجیره بلوکی را پردازش می‌کند. این سرویس به صورت دوره ای موجودی حساب کاربران خود را در بلاک چین لایه یک پست می کند. هر بار که یک به‌روزرسانی برای موجودی‌ها ارسال می‌کند، یک مدرک SNARK اضافه می‌کند که نشان می‌دهد توالی تراکنش‌های معتبری را می‌شناسد که مانده‌های حساب قدیمی را به موارد به‌روز شده تغییر داده است. به این ترتیب، اعتبارسنجی‌های بلاک چین مجبور نیستند کار سخت بررسی اعتبار تراکنش را انجام دهند (مثلاً بررسی یک امضای دیجیتال برای هر تراکنش) و یا به طور صریح تراکنش‌ها را برای محاسبه مانده‌های به‌روز شده پردازش کنند.  

My پست قبلی تمرکز بر عملکرد پروورهای SNARK - تعیین کننده اصلی قابلیت کاربرد SNARK. در حالی که اجرای یک اثبات کننده SNARK می تواند محاسباتی فشرده باشد، تا جایی که ممکن است ایجاد یک اثبات برای محاسبات در مقیاس بزرگ غیرممکن باشد، تأیید SNARK معمولاً بسیار ارزان تر از بررسی مستقیم و پردازش داده ها است. با این حال، هزینه های تأیید SNARK به طور قابل توجهی متفاوت است. این پست این هزینه ها را باز می کند و ویژگی های امنیتی SNARK های مختلف را با هم مقایسه می کند. 

به طور خاص، من توضیح می دهم که در SNARK های عملی با امنیت پس کوانتومی قابل قبول (PQ-SNARKs)، تنش قابل توجهی بین هزینه های امنیت و تأیید وجود دارد. علاوه بر این، در برخی موارد، این تنش در حال حاضر به نفع هزینه های راستی آزمایی نسبت به امنیت حل می شود.

برای اینکه SNARK ها به پتانسیل خود پی ببرند، سیستم های مستقر شده باید ایمن باشند و کاربران باید از امنیت خود مطمئن باشند. من این پست را با پیشنهاد اقدامات ساده ای که جامعه وب 3 می تواند انجام دهد تا اطمینان حاصل شود که این ویژگی ها برای طولانی مدت باقی می مانند، به پایان می رسانم. 

اقدامات امنیتی کمی 

SNARK در صورتی ایمن است که از نظر محاسباتی غیرممکن باشد برای ارائه یک مدرک قانع کننده از یک عبارت نادرست. به عنوان مثال، در زمینه جمع‌آوری‌های L2، مهاجمی که مایل به سرقت وجوه من است می‌خواهد یک بیانیه نادرست فرم را ثابت کند: "من تراکنش امضا شده دیجیتالی را می‌شناسم که تمام دارایی‌های جاستین را به حساب خودم منتقل می‌کند." 

سطح امنیتی یک SNARK با مقدار کاری که باید انجام شود برای یافتن یک مدرک قانع کننده از یک اظهارات نادرست اندازه گیری می شود. مشابه دیگر رمزنگاری‌های اولیه مانند امضای دیجیتال، لگاریتم این مقدار کار به عنوان «بیت‌های امنیت» نامیده می‌شود. به عنوان مثال، 30 بیت امنیت به این معنی است که 2³⁰ ≈ 1 میلیارد "گام کار" برای حمله به SNARK مورد نیاز است. این ذاتاً یک معیار تقریبی برای امنیت دنیای واقعی است زیرا مفهوم یک مرحله از کار می‌تواند متفاوت باشد و ملاحظات عملی مانند الزامات حافظه یا فرصت‌های موازی در نظر گرفته نمی‌شوند.

و کیفی

بیت های امنیت یک است کمی اندازه گیری امنیت SNARK SNARK ها نیز در خود متفاوت هستند کیفی ویژگی های امنیتی 

به عنوان مثال، برخی از SNARK ها به یک مراسم راه اندازی قابل اعتماد برای تولید یک کلید اثبات ساختاریافته نیاز دارند. SNARK هایی که اصلاً نیازی به راه اندازی قابل اعتماد ندارند نامیده می شوند شفاف است. 

برای اینکه یک SNARK غیرشفاف ایمن باشد، معمولاً حداقل یکی از شرکت‌کنندگان در مراسم باید صادقانه رفتار کرده باشد، به این معنی که یک «Trapdoor» را تولید کرده و سپس دور انداخته است که اگر با درب‌های همه شرکت‌کنندگان دیگر ترکیب شود، کار را آسان می‌کند. برای یافتن "شواهد" قانع کننده SNARK برای هر اظهارات نادرستی. تنظیمات قابل اعتماد هستند بودن اجرا با صدها یا هزاران شرکت کننده تا این فرض تا حد ممکن ملایم باشد. 

SNARK ها همچنین از نظر حساسیت به حملات کوانتومی متفاوت هستند. به طور خاص، بسیاری از SNARK ها (به عنوان مثال، گروت16, PlonK, نیزه ماهی, ضد گلوله, نو اختر) بر این فرض تکیه کنید که محاسبه لگاریتم های گسسته دشوار است (و در برخی موارد، مفروضات اضافی نیز). محاسبه لگاریتم‌های گسسته چیزی است که کامپیوترهای کوانتومی می‌توانند به طور موثر انجام دهند. از این رو، این SNARK ها ایمن پس کوانتومی (غیر PQ) نیستند. 

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

تعهدات چند جمله ای

همه SNARK ها از یک رمزگذاری اولیه به نام a استفاده می کنند طرح تعهد چند جمله ای، و این جزء اغلب یک گلوگاه عملکرد است. (برای جزئیات به من مراجعه کنید پست قبلی.) علاوه بر این، شفافیت و امنیت پس کوانتومی قابل قبول SNARK صرفاً توسط طرح تعهد چند جمله ای که استفاده می کند تعیین می شود. 

یکی از نمونه های برجسته به اصطلاح است تعهدات چند جمله ای KZG، که توسط PlonK, نیزه ماهی، و خیلی های دیگر. تعهدات KZG نه شفاف هستند و نه امن پس از کوانتومی. دیگر طرح‌های تعهد شفاف هستند اما پس کوانتومی نیستند، از جمله ضد گلوله, هیراکسو کرجی ته پهن ماهیگیری. 

هنوز طرح‌های دیگر هم شفاف هستند و هم به طور قابل قبولی پس کوانتومی. این شامل رایگان, لیگرو, Ligero++, ترمز کردنو شکارچی ماهر. همه این طرح ها بر اساس کدهای تصحیح خطا هستند. هش کردن تنها رمزگذاری اولیه ای است که آنها استفاده می کنند. آنها همچنین ویژگی های زیر را به اشتراک می گذارند: هزینه های تأیید (اندازه گیری شده با تعداد ارزیابی های هش و عملیات میدانی) به صورت خطی با تعداد بیت های امنیتی افزایش می یابد.

به طور کلی، یک "تکرار" منفرد از این تعهدات چند جمله ای پس کوانتومی تنها به تعداد کمی (مثلا 2-4) بیت امنیت دست می یابد. بنابراین، پروتکل باید بارها تکرار شود تا سطح امنیتی "تقویت" شود و هزینه های تأیید با هر تکرار افزایش می یابد. بنابراین، برای کنترل هزینه های تأیید در PQ-SNARK (و در نتیجه هزینه های گاز در برنامه های بلاک چین)، طراحان پروتکل تشویق می شوند تا سطح امنیتی را پایین نگه دارند. 

با کمیاب استثنا، این تنش بین امنیت بتن و هزینه های تأیید در SNARK های غیر PQ (شفاف و غیر شفاف به طور یکسان) ایجاد نمی شود. غیر PQ-SNARK ها از گروه های منحنی بیضی استفاده می کنند که در آنها محاسبه لگاریتم های گسسته سخت فرض می شود و سطوح امنیتی آنها توسط گروه مورد استفاده تعیین می شود. اندازه گروه منحنی بیضوی مناسب و در نتیجه هزینه هر عملیات گروهی با سطح امنیتی مورد نظر افزایش می یابد. با این حال عدد عناصر گروه در یک برهان مستقل از انتخاب گروه هستند. 

در PQ-SNARK ها، نه تنها اندازه ارزیابی های هش به صورت خطی با سطح امنیتی مورد نظر رشد می کند، بلکه تعداد ارزیابی های موجود در اثبات و انجام شده توسط تأیید کننده نیز افزایش می یابد. 

هزینه های تایید کننده بتن و امنیت در SNARK های مستقر شده

هزینه های تایید کننده بتن و سطوح امنیتی SNARK های مستقر شده به طور قابل توجهی متفاوت است. در اینجا چند نمونه گویا آورده شده است:

هزینه های تایید کننده 

My پست قبلی دو نمونه از هزینه های راستی آزمایی بتن را ذکر کرد: PlonK هزینه اثبات زیر 300,000 گاز برای تایید در اتریوم، در حالی که اثبات StarkWare حدود 5 میلیون گاز هزینه دارد. اثبات های StarkWare شفاف و قابل قبول پس کوانتومی هستند در حالی که PlonK چنین نیستند. با این حال، همانطور که در ادامه توضیح داده شد، اثبات‌های StarkWare در سطح امنیتی بسیار پایین‌تری نسبت به اثبات‌های PlonK در اتریوم اجرا می‌شوند.

امنیت بتن

تنها منحنی بیضوی با پیش‌کامپایل‌های اتریوم، altbn128 نامیده می‌شود، بنابراین این منحنی است که تمام SNARK‌های غیرPQ مستقر در استفاده از اتریوم، از جمله آزتک ها'شن zkSync's این منحنی - و از این رو SNARK های مستقر که از آن استفاده می کنند - در ابتدا تصور می شد که تقریباً 128 بیت امنیت را ارائه می دهد. اما به دلیل حملات بهبود یافته (زمان اجرای دقیق آن است دشوار است برای تعیینمنحنی در حال حاضر به طور گسترده ای در نظر گرفته می شود که 100 تا 110 بیت امنیت را ارائه می دهد. 

EIP وجود دارد زیر توجه معرفی پیش‌کامپایل‌هایی برای منحنی‌های مختلف که هنوز هم اعتقاد بر این است که امنیت نزدیک به 128 بیت را ارائه می‌دهند. چنین منحنی هایی هستند قبلاً استفاده شده در SNARK های پروژه های غیر اتریوم از جمله ZCash، Algorand، Dfinity، Filecoin و Aleo. 

در مقابل، طبق داده‌های زنجیره‌ای، PQ-SNARK‌های StarkWare (در سیستم به اصطلاح SHARP، مخفف SHARed Prover) برای هدف قرار دادن 80 بیت امنیت پیکربندی شده‌اند. این سطح امنیتی تحت حدس و گمان های خاصی در مورد استحکام آماری FRI (که بعداً در این پست به آن خواهم پرداخت) وجود دارد. 

اصطلاح "80 بیت امنیت" در این زمینه مبهم است، بنابراین اجازه دهید آن را باز کنم. به طور کلی، به این معنی است که یک مهاجم می تواند با ارزیابی یک تابع هش 2، یک مدرک قانع کننده برای یک عبارت نادرست ارائه کند.⁸⁰ بار (یعنی KECCAK-256، تابع هش مورد استفاده توسط اتریوم). به بیان دقیق تر، مهاجمی که مایل به انجام 2^k ارزیابی هش می تواند یک دلیل قانع کننده با احتمال تقریبا 2 ایجاد کند^k-80. مثلا با 2⁷⁰ در ارزیابی‌های هش، می‌توان یک «اثبات» SNARK برای یک عبارت نادرست با احتمال حدود 2 پیدا کرد.^-10 = 1/1024 

این مفهوم ضعیف تر از آنچه که اصطلاح "80 بیت امنیت" در زمینه های دیگر به معنای آن است. به عنوان مثال، یک تابع هش مقاوم در برابر برخورد (CRHFs) که روی 80 بیت امنیتی پیکربندی شده است، خروجی های 160 بیتی تولید می کند. اگر تابع هش به خوبی طراحی شده باشد، سریعترین روش برخورد یافتن خواهد بود حمله تولد، یک روش brute-force که می تواند برخوردی با حدود 2 پیدا کند^160/2 = 2⁸⁰ ارزیابی های هش با این حال، با 2^k ارزیابی هش، حمله Birthday یک برخورد با احتمال تنها 2 پیدا می کند^2k-160. 

مثلاً 2⁷⁰ ارزیابی هش یک برخورد با احتمال 2 به دست می دهد^-20  ≈ 1/1,000,000. این بسیار کمتر از احتمال 1/1,000 مهاجمی است که یک اثبات PQ-SNARK را با 80 بیت امنیتی پیکربندی کرده است. 

این تفاوت می تواند به شدت جذابیت انجام یک حمله را تغییر دهد. برای نشان دادن، تصور کنید یک مهاجم بودجه ای 100 هزار دلاری دارد که می تواند 2 مورد را بخرد⁷⁰ ارزیابی های هش و فرض کنید که اگر مهاجم موفق شود، سود آن 200 میلیون دلار است. ارزش مورد انتظار حمله علیه یک PQ-SNARK که روی 80 بیت امنیتی پیکربندی شده است (1/1,000) * 200 میلیون دلار یا 200 هزار دلار است - دو برابر هزینه. اگر احتمال موفقیت فقط 1/1,000,000 بود، مانند یک CRHF، ارزش مورد انتظار حمله فقط 200 دلار بود. 

دو مفهوم "80 بیت امنیت" نیز در استحکام آنها نسبت به حملات مستقل به شدت متفاوت است. برای مثال، فرض کنید 1,000 طرف مستقل هر کدام با انجام 2 مورد به PQ-SNARK حمله کنند.⁷⁰ ارزیابی های هش از آنجایی که هر کدام با احتمال 1/1,000 موفق می شوند، حداقل یکی از آنها به احتمال زیاد موفق می شود. اگر هرکدام با احتمال 1/1,000,000 موفق می‌شدند، چنین نمی‌شد.

انتظار می‌رود گروه‌های منحنی بیضی که به خوبی طراحی شده‌اند، رفتاری مشابه با CRHF‌ها داشته باشند، با حملات شبه تولد مانند الگوریتم rho پولارد شناخته شده ترین بودن این بدان معنی است که در گروهی که 128 بیت امنیت ارائه می دهد، 2^k عملیات گروهی باید یک راه حل برای نمونه ای از مسئله لگاریتم گسسته با احتمال تنها 2 ارائه دهد.^2k-256. مثلاً 2⁷⁰ عملیات گروهی یک لگاریتم گسسته را با احتمال نجومی کوچک 2 پیدا می کند^-116. علاوه بر این، هر عملیات گروهی کندتر از ارزیابی CRHF است. 

امروزه چند ارزیابی هش امکان پذیر است؟

در ژانویه 2020، هزینه محاسبه فقط 2 است⁶⁴ ارزیابی SHA-1 با استفاده از پردازنده گرافیکی بود $45,000. این هزینه 2 را می گذارد⁷⁰ ارزیابی‌های SHA-1 بر روی پردازنده‌های گرافیکی با چند میلیون دلار (شاید پس از ادغام اتریوم کمتر شود، زیرا دور شدن از اثبات کار استخراج تحت تسلط GPU احتمالاً تقاضا برای محاسبات GPU را کاهش می‌دهد و هزینه آن را کاهش می‌دهد). 

با جمع‌آوری‌های اعتباری که قبلاً صدها میلیون دلار در وجوه کاربر ذخیره می‌کنند، یافتن یک مدرک قانع‌کننده از یک اظهارنامه نادرست می‌تواند میلیون‌ها دلار سود به همراه داشته باشد. پیکربندی یک PQ-SNARK با امنیت 80 بیتی تحت حدسیات تهاجمی، کمتر از 10 بیت فضایی بین حملات سودآور و امنیت حدسی PQ-SNARK باقی می‌گذارد.

به عنوان یک نقطه داده دیگر، نرخ هش شبکه بیت کوین در حال حاضر حدود 2 است⁶⁴  ارزیابی هش در ثانیه، یعنی ماینرهای بیت کوین به طور کلی 2⁸⁰ ارزیابی SHA-256 هر 18 ساعت. البته این رقم چشمگیر به دلیل سرمایه گذاری گسترده در ASIC ها برای استخراج بیت کوین است. 

با فرض شش بلوک بیت کوین ایجاد شده در هر ساعت، و با توجه به پاداش بلاک فعلی 6.25 بیت کوین در هر بلوک، این 2⁸⁰ ارزیابی SHA-256 احتمالاً کمتر از 22,000 دلار * 18 * 6 * 6.25 ≈ 15 میلیون دلار هزینه دارد. در غیر این صورت، استخراج بیت کوین با قیمت های فعلی سودآور نخواهد بود. 

اقدامات پیشنهادی برای یک اکوسیستم سالم

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

با توجه به ماهیت پیچیده این پروتکل ها، این پارادایم بررسی عمومی باری را بر دوش کارشناسان قرار می دهد تا به طور آشکار و صریح درباره امنیت قراردادهای مستقر شده بحث کنند. 

اما با PQ-SNARK ها، حتی برای متخصصان نیز می تواند دشوار باشد که سطح امنیتی پروتکل مستقر شده را تعیین کنند، به همان دلیل که امنیت و عملکرد تأیید کننده برای این SNARK ها در تنش هستند: سطح امنیتی (و هزینه های تأیید کننده) به پارامترهای داخلی بستگی دارد. SNARK. و حداقل برای StarkWare's قراردادهای هوشمندانه، این پارامترها را فراخوانی می کنندd logBlowupFactor، proofOfWorkBits و n_Queries مستقیماً در کد قرارداد هوشمند مشخص نشده‌اند، بلکه به عنوان داده عمومی به قرارداد هوشمند منتقل می‌شوند. تا آنجا که من می دانم، ساده ترین راه برای شناسایی این پارامترها از اطلاعات زنجیره ای از طریق یک فرآیند چهار مرحله ای است: 

1. مشاهده قرارداد هوشمند مناسب در یک بلاک کاوشگر مانند Etherscan، 
2. روی یک کلیک کنید معامله "تأیید اثبات" مناسب, 
3. رمزگشایی داده های ورودی تراکنش، و
4. بفهمید که چگونه تفسیر کردن داده های ورودی رمزگشایی شده برای یادگیری پارامترهای کلیدی SNARK که با هم سطح امنیت را تعیین می کنند. 

این مرحله نهایی مستلزم یافتن کد Solidity مناسب برای اجرای تراکنش است که ممکن است خود یک کار گیج کننده باشد. (وقتی داشتم آماده می کردم بررسی مذاکرات در تابستان امسال، Etherscan قادر به رمزگشایی داده های ورودی مربوط به تراکنش های تأیید کننده SHARP مطابق مرحله 2 بالا بود. اما به نظر می رسد که دیگر کار نمی کند.)

پیشنهاد 1: بررسی دقیق 

با در نظر گرفتن این موضوع، اولین پیشنهاد من به جامعه web3 این است که بررسی دقیق سطح امنیتی SNARK های پس کوانتومی مستقر شده را بسیار آسان تر کند. این احتمالاً شامل ابزارهای بهتر برای درک داده‌های زنجیره‌ای و افزایش شفافیت توسط خود پروژه‌ها در شناخت این پارامترها است. 

پیشنهاد 2: هنجارهای قوی تر

امنیت 80 بیت خیلی پایینه مخصوصا نسخه ضعیف که 2⁷⁰ ارزیابی‌های هش برای حمله موفقیت‌آمیز با احتمال 1/1000 کافی است - حتی با توجه به سابقه طولانی حملات شگفت‌انگیز به رمزنگاری‌های اولیه. یکی، که در بالا ذکر شد، حملات بهتر به منحنی‌های بیضوی مناسب جفت مانند altbn128 است. مثال معروف تر SHA-1 است که با امنیت 80 بیت استاندارد شده بود اما در نهایت نشان داده شد که تنها به حدود 60 بیت می رسد. با در نظر گرفتن این سابقه، طراحان PQ-SNARK باید بیش از 10 بیت اتاق حرکت را هنگام پیکربندی سطح امنیتی برای خود بگذارند، به خصوص اگر تجزیه و تحلیل امنیتی شامل حدس های قوی در مورد امنیت آماری پروتکل های نسبتاً جدید مانند FRI باشد.

حتی برای PQ-SNARK ها، سطوح امنیتی مناسبی را می توان به سادگی با افزایش هزینه های تأیید به دست آورد. به عنوان مثال، افزایش امنیت تایید کننده SHARP از 80 به 128 بیت (تحت حدسیات در مورد درستی آماری FRI) هزینه های گاز را تقریباً یک ضریب افزایش می دهد، از کمی بیش از 5 میلیون به کمی بیش از 10 میلیون. بدون حدس و گمان در مورد FRI، هزینه های گاز با یک ضریب دیگر افزایش می یابد، به بیش از 20 میلیون. 

پس پیشنهاد بعدی من این است که جامعه web3 باید هنجارهای قوی تری را پیرامون سطوح امنیتی مناسب برای SNARK های مستقر ایجاد کند. توصیه شخصی من حداقل 100 بیت خواهد بود و اگر امنیت SNARK بر اساس فرضیات غیر استاندارد باشد حداقل 128 بیت خواهد بود. من اولین کسی نیستم که چنین پیشنهادی بدهد.

در اینجا، من مایلم امنیت بی قید و شرط را به عنوان یک "فرض استاندارد" طبقه بندی کنم مدل اوراکل تصادفی، اگر اوراکل تصادفی در SNARK مستقر شده با یک تابع هش استاندارد مانند KECCAK-256 نمونه سازی شود. مدل اوراکل تصادفی یک تنظیم ایده‌آل است که به منظور ثبت رفتار توابع هش رمزنگاری خوب طراحی شده است. اغلب برای تجزیه و تحلیل امنیت PQ-SNARK ها استفاده می شود. 

نمونه‌ای از مفروضات غیر استاندارد حدس‌ها (توضیح داده شده در زیر) در مورد صحت کمی یک پروتکل مانند FRI، چه در یک محیط تعاملی و چه به عنوان یک پروتکل غیر تعاملی در مدل تصادفی اوراکل است.

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

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

یک نکته: غواصی حتی عمیق تر در امنیت PQ-SNARK

80 بیت امنیت در PQ-SNARK های StarkWare به شرح زیر است. این PQ-SNARK ها از یک طرح تعهد چند جمله ای به نام استفاده می کنند رایگانو تأیید کننده SHARP StarkWare FRI را با 48 بیت امنیتی تحت یک حدس اجرا می کند. به طور کلی، حدس این است که یک حمله ساده به سلامت FRI بهینه است. در این حمله، یک اثبات کننده تقلب، با مقدار کمی تلاش، یک "اثبات FRI" تولید می کند که بررسی های تصادفی انتخاب شده توسط تایید کننده را با احتمال 2 پاس می کند.^-48. 

StarkWare FRI را با تکنیکی به نام "سنگ زدن" ترکیب می کند. این امر مستلزم آن است که یک اثبات کننده صادق قبل از تولید یک اثبات FRI، یک اثبات کار 32 بیتی ارائه دهد. مزیت سنگ زنی این است که کار مورد نیاز یک تقلب را برای انجام حمله ساده به FRI که در بالا ذکر شد به شدت افزایش می دهد، به حدود 2.³² ارزیابی های هش 

از آنجایی که (در انتظار) 2⁴⁸ تلاش برای حمله ساده قبل از موفقیت آمیز شدن یکی از آنها ضروری است، کل میزان کاری که ارائه دهنده تقلب باید انجام دهد تا یک اثبات FRI را جعل کند تقریباً 2 است.⁴⁸ * 2³² = 2⁸⁰ ارزیابی های هش

در نهایت، اجازه دهید نحوه به وجود آمدن 48 بیت امنیت برای FRI را باز کنیم. تأیید کننده FRI "پرس و جو" را به چند جمله ای متعهد می کند. هزینه های تأیید FRI به صورت خطی با تعداد پرس و جوها افزایش می یابد. به عنوان مثال، 36 درخواست تأیید کننده FRI تقریباً 4 برابر گران تر از 9 پرس و جو هستند. اما پرس و جوهای بیشتر به معنای امنیت بیشتر است. تعداد بیت های امنیتی در هر پرس و جو به پارامتر دیگری از FRI به نام نرخ کد بستگی دارد. 

به طور خاص، FRI از چیزی به نام کد نرخ رید-سولومون استفاده می کند r، که در آن r همیشه عددی کاملاً بین 0 و 1 است. هزینه های پروور FRI با نسبت معکوس دارد. r، بنابراین نرخ 1/16 منجر به اثباتی می شود که تقریباً چهار برابر کندتر و فضا برتر از نرخ ¼ است. 

تأییدکننده SHARP FRI را با نرخ کد 1/16 و با 12 درخواست تأییدکننده اجرا می‌کند.

StarkWare حدس می‌زند که هر جستار تأییدکننده FRI گزارشی را اضافه می‌کند₂(1 /r) بیت های امنیتی بر اساس این حدس، 12 پرس و جوی تایید کننده، 12 * ورود را به دست می دهند₂(16) = 48 بیت امنیت.

با این حال، تجزیه و تحلیل‌های کنونی تنها نشان می‌دهد که هر درخواست تأییدکننده کمی کمتر از گزارش اضافه می‌کند₂(1/r^1/2) بیت های امنیتی. بنابراین 12 درخواست تأیید کننده FRI فقط کمتر از 12 * ورود به سیستم را ارائه می دهند₂(4) = 24 بیت امنیت "قابل اثبات". 

پیشنهادی برای کاهش تنش بین امنیت و عملکرد

PQ-SNARK های عملی هزینه های تایید کننده ای دارند که به صورت خطی با تعداد بیت های امنیتی مورد نظر افزایش می یابد. یکی از تکنیک‌های امیدوارکننده برای کاهش این تنش، ترکیب SNARK است - که در پست قبلی خود به عنوان وسیله‌ای برای حل تنش بین هزینه‌های اثبات‌کننده و تأییدکننده توضیح دادم، اما می‌تواند امنیت را نیز برطرف کند. 

دو نمونه 

چند ضلعی هرمز است آهنگسازی PQ-SNARK با PlonK. ایده این است که پروور ابتدا یک PQ-SNARK proof π تولید کند. اگر PQ-SNARK به گونه ای پیکربندی شده باشد که دارای یک اثبات کننده سریع و سطح امنیتی کافی باشد، آنگاه π بزرگ خواهد بود. بنابراین پروور π را به تایید کننده ارسال نمی کند. در عوض، از PlonK برای اثبات اینکه π را می داند استفاده می کند. 

این به معنای اعمال PlonK به مداری است که π را به عنوان ورودی می‌گیرد و بررسی می‌کند که تأییدکننده PQ-SNARK، π را می‌پذیرد. از آنجایی که PQ-SNARK هزینه تأیید چند لگاریتمی دارد، PlonK روی یک مدار کوچک اعمال می‌شود و از این رو پروور PlonK سریع است. از آنجایی که اثبات‌های PlonK کوچک و ارزان هستند، هزینه‌های تأیید پایین است. 

متأسفانه استفاده از PlonK شفافیت و امنیت پسا کوانتومی را از بین می برد. در عوض می‌توان از خود PQ-SNARK به جای PlonK برای اثبات دانش π استفاده کرد (در واقع PQ-SNARK که توسط Polygon استفاده می‌شود به این شکل خودساخته است). 

در این دومین کاربرد PQ-SNARK، برای اثبات دانش π، سیستم را می توان برای دستیابی به امنیت کافی با اثبات هایی با اندازه معقول پیکربندی کرد، به عنوان مثال، با انتخاب نرخ کد بسیار کوچک برای استفاده در FRI. نکته کلیدی این است که، در حالی که این نرخ کد کوچک برای زمان اثبات بد است، کاربرد دوم PQ-SNARK فقط برای یک مدار کوچک اعمال می شود، بنابراین کل زمان اثبات کننده هنوز باید کم باشد.

درک تئوریک ما از امنیت SNARK های ترکیبی، چیزهای زیادی باقی می گذارد. با این حال، حملات شناخته شده ای به آنها وجود ندارد که سریعتر از حمله به یکی از SNARK های سازنده به صورت جداگانه باشد. به عنوان مثال، اگر یک PQ-SNARK را با PlonK بسازیم، ما حمله ای بهتر از حمله به PQ-SNARK (یعنی یافتن اثبات PQ-SNARK π یک عبارت نادرست) یا حمله به PlonK (یعنی، یک اثبات PlonK برای عبارت نادرست پیدا کنید "من یک اثبات PQ-SNARK π را می دانم که تایید کننده آن را می پذیرفت.")

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

***

جاستین تالر دانشیار دانشگاه جورج تاون است. او قبل از پیوستن به جورج تاون، دو سال را به عنوان پژوهشگر در آزمایشگاه یاهو در نیویورک گذراند و قبل از آن به عنوان پژوهشگر در دانشگاه مشغول به کار بود. موسسه تئوری محاسبات سیمونز در UC Beرکلی 

تدوینگر: تیم سالیوان @tim_org

***

نظرات بیان شده در اینجا نظرات پرسنل AH Capital Management, LLC ("a16z") نقل شده است و نظرات a16z یا شرکت های وابسته به آن نیست. برخی از اطلاعات موجود در اینجا از منابع شخص ثالث، از جمله از شرکت‌های سبد سرمایه‌ای که توسط a16z مدیریت می‌شوند، به‌دست آمده است. در حالی که a16z از منابعی گرفته شده است که معتقدند قابل اعتماد هستند، a16z به طور مستقل چنین اطلاعاتی را تأیید نکرده است و هیچ اظهارنظری در مورد صحت پایدار اطلاعات یا مناسب بودن آن برای یک موقعیت خاص ارائه نمی کند. علاوه بر این، این محتوا ممکن است شامل تبلیغات شخص ثالث باشد. aXNUMXz چنین تبلیغاتی را بررسی نکرده و محتوای تبلیغاتی موجود در آن را تایید نمی کند.

این محتوا فقط برای مقاصد اطلاعاتی ارائه شده است و نباید به عنوان مشاوره حقوقی، تجاری، سرمایه گذاری یا مالیاتی به آن اعتماد کرد. شما باید در مورد این موارد با مشاوران خود مشورت کنید. ارجاع به هر گونه اوراق بهادار یا دارایی دیجیتال فقط برای مقاصد توضیحی است و به منزله توصیه یا پیشنهاد سرمایه گذاری برای ارائه خدمات مشاوره سرمایه گذاری نیست. علاوه بر این، این محتوا برای هیچ سرمایه‌گذار یا سرمایه‌گذار بالقوه‌ای هدایت نشده و برای استفاده از آن در نظر گرفته نشده است، و تحت هیچ شرایطی نمی‌توان هنگام تصمیم‌گیری برای سرمایه‌گذاری در هر صندوقی که توسط a16z مدیریت می‌شود، به آن اعتماد کرد. (پیشنهاد سرمایه گذاری در یک صندوق a16z فقط توسط یادداشت قرار دادن خصوصی، قرارداد اشتراک و سایر اسناد مربوط به هر صندوق انجام می شود و باید به طور کامل خوانده شود.) هر گونه سرمایه گذاری یا شرکت پرتفوی ذکر شده، ارجاع شده، یا شرح داده شده نشان دهنده همه سرمایه گذاری ها در وسایل نقلیه تحت مدیریت a16z نیست، و نمی توان اطمینان داشت که سرمایه گذاری ها سودآور هستند یا سایر سرمایه گذاری های انجام شده در آینده ویژگی ها یا نتایج مشابهی خواهند داشت. فهرستی از سرمایه‌گذاری‌های انجام‌شده توسط صندوق‌های تحت مدیریت آندریسن هوروویتز (به استثنای سرمایه‌گذاری‌هایی که ناشر مجوز افشای عمومی a16z و همچنین سرمایه‌گذاری‌های اعلام‌نشده در دارایی‌های دیجیتالی عمومی را ارائه نکرده است) در https://a16z.com/investments موجود است. /.

نمودارها و نمودارهای ارائه شده در داخل صرفاً برای مقاصد اطلاعاتی هستند و هنگام تصمیم گیری برای سرمایه گذاری نباید به آنها اعتماد کرد. عملکرد گذشته نشان دهنده نتایج آینده نیست. محتوا فقط از تاریخ مشخص شده صحبت می کند. هر گونه پیش بینی، تخمین، پیش بینی، هدف، چشم انداز، و/یا نظرات بیان شده در این مطالب بدون اطلاع قبلی ممکن است تغییر کند و ممکن است متفاوت یا مغایر با نظرات بیان شده توسط دیگران باشد. لطفاً برای اطلاعات مهم بیشتر به https://a16z.com/disclosures مراجعه کنید.