اندازه گیری عملکرد SNARK: Frontends، Backends و آینده

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

هزینه های تأیید برای SNARK ها می تواند متفاوت باشد، اما به خوبی درک شده و اغلب بسیار خوب است. مثلا، PlonK هزینه اثبات 290,000 گاز برای تایید در اتریوم، در حالی که اثبات StarkWare حدود 5 میلیون گاز هزینه دارد. SNARK ها به طور بالقوه در تنظیمات مختلف حتی خارج از بلاک چین قابل اجرا هستند - برای مثال امکان استفاده از سریع اما غیرقابل اعتماد سرورها و سخت افزار. 

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

اما اول: SNARK ها چگونه مستقر می شوند

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

به طور معمول، IR نوعی نمونه رضایت مدار است که معادل ψ. این بدان معنی است که مدار C داده ها را به عنوان ورودی می گیرد wو همچنین برخی ورودی‌های اضافی که معمولاً «توصیه‌های غیر قطعی» نامیده می‌شوند و اجرا می‌شوند ψ on w. از ورودی های مشاوره برای کمک استفاده می شود C اجرا ψ، در حین نگهداری C کم اهمیت. مثلا هر بار ψ دو عدد را تقسیم می کند x و y، ضریب q و باقیمانده r می تواند به عنوان مشاوره ارائه شود Cو C به سادگی می توانید آن را بررسی کنید x = qy + r. این چک هزینه کمتری نسبت به ساخت دارد C یک الگوریتم تقسیم را برای محاسبه اجرا کنید q و r از ابتدا

در نهایت، یک SNARK برای رضایت مداری اعمال می شود C. به این گفته می شود SNARK باطن. برای تعداد انگشت شماری از مشکلات بسیار ساختار یافته مانند ضرب ماتریس, پیچیدگی هاو چندین مشکل نمودارSNARK های شناخته شده ای وجود دارند که از این پارادایم frontend/backend اجتناب می کنند و در نتیجه به یک اثبات کننده بسیار سریعتر دست می یابند. اما تمرکز این پست بر روی SNARK های همه منظوره است.

همانطور که خواهیم دید، هزینه های ارائه شده در باطن SNARK با افزایش می یابد C's اندازه. نگه داشتن C کوچک می تواند چالش برانگیز باشد، زیرا مدارها فرمت بسیار محدودی برای بیان یک محاسبات هستند. آنها شامل دروازه ها، متصل شده توسط سیم. هر دروازه g مقداری تغذیه می شود و الف را اعمال می کند بسیار تابع ساده به آن مقادیر. سپس نتیجه از طریق سیم‌هایی که از آن خارج می‌شوند به دروازه‌های «پایین‌دست» وارد می‌شود g.

مقیاس پذیری SNARK: واقعا چقدر زمان می برد؟

سوال کلیدی این است که اثبات SNARK نسبت به اجرای مجدد ساده چقدر زمان بیشتری می برد ψ روی داده ها؟ پاسخ این است سربار ثابت از SNARK، نسبت به بررسی مستقیم شاهد. عبارت اخیر اشاره به این واقعیت دارد که در برهان ساده لوحانه که در آن P می فرستد w به V, V چک ها wاعتبار با اجرا ψ بر روی آن. 

تقسیم سربار پروور به «سربار جلویی» و «سربار پشتیبان» مفید است. در صورت ارزیابی مدار C دروازه به دروازه است F گران تر از دویدن ψ، سپس می گوییم سربار frontend است F. در صورت استفاده از backend prover به C is B گران تر از ارزیابی C دروازه به دروازه، سپس می گوییم که سربار backend است B. کل سربار prover است تولید - محصول، F·B. این سربار ضربی می تواند قابل توجه باشد حتی اگر F و B به صورت فردی متواضع هستند 

در عمل، F و B هر دو می توانند تقریباً 1000 یا بزرگتر باشند. این بدان معناست که کل سربار پروور نسبت به بررسی مستقیم شاهد می تواند 1 میلیون تا 10 میلیون یا بیشتر باشد. برنامه‌ای که فقط برای یک ثانیه روی لپ‌تاپ اجرا می‌شود، می‌تواند به راحتی منجر به SNARK شود که به ده‌ها یا صدها روز زمان محاسباتی (تک رشته‌ای) نیاز دارد. خوشبختانه، این کار به طور معمول تا اندازه های مختلف قابل موازی سازی است (بسته به SNARK). 

به طور خلاصه، اگر امروز می خواهید از SNARK در یک برنامه استفاده کنید، یکی از سه مورد باید درست باشد:

1. بررسی مستقیم شاهد در لپ تاپ بسیار کمتر از یک ثانیه طول می کشد.
2. بررسی مستقیم شاهد به ویژه برای نمایش در یک مدار قابل قبول است، بنابراین سربار frontend کوچک است.
3. شما مایلید روزها منتظر بمانید تا پروور SNARK به پایان برسد، و/یا برای منابع عظیم محاسباتی موازی هزینه کنید.

Tاو در ادامه این پست توضیح می دهد که هزینه های سربار frontend و backend از کجا می آیند و چگونه آنها را برای SNARK های مختلف تخمین می زنم. سپس به چشم‌اندازهایی برای بهبود می‌پردازیم. 

جداسازی فرانت اند و باطن

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

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

اکثر backendها در واقع از تعمیم مدارهای حسابی که معمولاً موارد رضایت از محدودیت رتبه-1 (R1CS) نامیده می شوند، پشتیبانی می کنند. به استثنای قابل توجه گروت16 و پیشینیان آن، این SNARK ها می توانند برای پشتیبانی از IR های دیگر نیز ساخته شوند. برای مثال، StarkWare از چیزی به نام بازنمایی جبری میانی (AIR) استفاده می‌کند که شبیه به مفهومی به نام محاسبات پلونکیش که می تواند توسط PlonK و سایر باطن ها پشتیبانی شود. توانایی برخی از Backendها برای پشتیبانی از IRهای عمومی تر می تواند هزینه های سربار فرانت اندهایی را که این IR ها را تولید می کنند کاهش دهد. 

Backendها همچنین از نظر فیلدهای محدودی که به طور بومی پشتیبانی می کنند متفاوت هستند. در بخش بعدی بیشتر در این مورد بحث خواهم کرد.

رویکردهای مختلف به frontends

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

یکی از رویکردهای محبوب ظاهری، تولید مدارهایی است که اساساً یک CPU ساده را که به آن ماشین مجازی (VM) نیز می‌گویند، گام به گام اجرا می‌کنند. طراحان فرانت‌اند مجموعه‌ای از «عملیات اولیه» مشابه دستورالعمل‌های مونتاژ برای پردازنده‌های رایانه واقعی را مشخص می‌کنند. توسعه‌دهندگانی که می‌خواهند از frontend استفاده کنند، مستقیماً به زبان اسمبلی «برنامه‌های کنترل شاهد» را می‌نویسند یا به زبان‌های سطح بالاتری مانند Solidity می‌نویسند و برنامه‌هایشان را به‌طور خودکار در کد اسمبلی کامپایل می‌کنند. 

مثلا StarkWare's قاهره یک زبان اسمبلی بسیار محدود است که در آن دستورالعمل‌های اسمبلی تقریباً اجازه جمع و ضرب را در یک میدان محدود می‌دهد، تابع را فراخوانی می‌کند، و در یک حافظه غیرقابل تغییر (یعنی یک بار نوشتن) می‌خواند و می‌نویسد. Cairo VM یک معماری فون نویمان است، به این معنی که مدارهای تولید شده توسط frontend اساساً یک برنامه Cairo را به عنوان ورودی عمومی می گیرند و برنامه را روی شاهد اجرا می کنند. زبان قاهره تورینگ کامل است - علیرغم مجموعه دستورالعمل های محدود آن، می تواند معماری های استاندارد بیشتری را شبیه سازی کند، اگرچه انجام این کار ممکن است گران باشد. پیشانی قاهره اجرای برنامه های قاهره را تبدیل می کند T دستورالعمل های ابتدایی به آنچه "درجه" نامیده می شود2 هوا با T ردیف ها و حدود 50 ستون ها." چی دقیقا این یعنی برای این پست مهم نیست، اما تا آنجا که به پروورهای SNARK مربوط می شود، این مربوط به مدارهایی با بین 50 تا 100 گیت برای هر یک از T مراحل CPU قاهره. 

RISC صفر رویکردی مشابه به قاهره دارد، اما با ماشین مجازی که به اصطلاح معماری RISC-V، یک معماری منبع باز با اکوسیستم نرم افزاری غنی که در حال افزایش محبوبیت است. به عنوان یک مجموعه دستورالعمل بسیار ساده، طراحی یک فرانت اند کارآمد SNARK که از آن پشتیبانی می کند، ممکن است نسبتا قابل اجرا باشد (حداقل نسبت به معماری های پیچیده مانند x86 یا ARM). از ماه می، RISC صفر در حال تبدیل برنامه ها است اجرا کردن T دستورالعمل های اولیه RISC-V به درجه 5 AIR با 3T ردیف ها و 160 ستون ها. این مربوط به مدارهایی با حداقل است 500 گیت ها در هر مرحله از CPU RISC-V. بهبودهای بیشتر در آینده نزدیک پیش بینی می شود.

پروژه های مختلف zkEVM (به عنوان مثال، zkSync 2.0، Scroll، zkEVM Polygon) ماشین مجازی را به عنوان (duh) ماشین مجازی اتریوم می دانند. فرآیند تبدیل هر دستورالعمل EVM به یک "ابزار" معادل (یعنی یک مدار بهینه سازی شده که دستورالعمل را اجرا می کند) به طور قابل توجهی بیشتر از معماری های ساده تر Cairo و RISC-V درگیر است. به این دلیل و دلایل دیگر, برخی از پروژه های zkEVM به طور مستقیم مجموعه دستورات EVM را پیاده سازی نمی کنند، بلکه برنامه های Solidity سطح بالا را قبل از تبدیل آنها به مدار به سایر زبان های اسمبلی کامپایل می کنند. نتایج عملکرد از این پروژه ها در انتظار است.

پروژه‌های «شبیه‌ساز CPU» مانند RISC-V و Cairo یک مدار واحد تولید می‌کنند که می‌تواند همه برنامه‌ها را در زبان اسمبلی مرتبط مدیریت کند. رویکردهای جایگزین "مانند ASIC" هستند که مدارهای مختلفی را برای برنامه های مختلف تولید می کنند. این رویکرد ASIC مانند می‌تواند مدارهای کوچک‌تری برای برخی از برنامه‌ها ایجاد کند، به‌ویژه زمانی که دستورالعمل اسمبلی که برنامه در هر مرحله زمانی اجرا می‌کند به ورودی برنامه بستگی ندارد. به عنوان مثال، به طور بالقوه می تواند از سربار frontend به طور کامل برای برنامه های خط مستقیم مانند ضرب ماتریس ساده لوح اجتناب کند. اما رویکرد ASIC نیز بسیار محدود به نظر می رسد. تا آنجا که من می دانم، نحوه استفاده از آن برای پشتیبانی از حلقه ها بدون محدودیت های تکرار از پیش تعیین شده، شناخته شده نیست. 

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

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

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

برخی از پروژه‌ها روی زمینه‌هایی با محاسبات سریع کار می‌کنند. مثلا، پلونکی 2 و دیگران از فیلد مشخصه 2 استفاده می کنند⁶⁴ - 2³² + 1 زیرا محاسبات در این زمینه را می توان چندین برابر سریعتر از فیلدهای کمتر ساختار یافته پیاده سازی کرد. با این حال، استفاده از چنین مشخصه کوچکی ممکن است منجر به چالش هایی در نمایش کارآمد حساب اعداد صحیح از طریق عملیات میدانی شود (به عنوان مثال، ضرب دو عدد صحیح بدون علامت 32 بیتی ممکن است نتیجه ای بزرگتر از مشخصه میدان به دست دهد). 

 اما مهم نیست که چه، برای همه SNARK های محبوب امروزی برای دستیابی به 128 بیت امنیت (بدون افزایش قابل توجهی در هزینه های تأیید)، آنها باید در زمینه ای با اندازه بزرگتر از 2 کار کنند.¹²⁸. تا آنجا که من می توانم بگویم، این بدان معنی است که هر عملیات میدانی حداقل به حدود ده ضرب ماشینی 64 بیتی، و عملیات جمع و عملیات بیتی بیشتری نیاز دارد. از این رو، به دلیل نیاز به مدارهایی که در میدان های محدود عمل می کنند، باید حداقل یک مرتبه سربار را در نظر گرفت. 

به طور خلاصه، فرانت‌اندهای موجود که از انتزاع ماشین مجازی استفاده می‌کنند، مدارهایی با گیت‌های 100x تا 1000x در هر مرحله از ماشین مجازی و احتمالاً برای ماشین‌های مجازی پیچیده‌تر، تولید می‌کنند. علاوه بر این، محاسبات میدان محدود حداقل 10 برابر کندتر از دستورالعمل های مشابه در پردازنده های مدرن است (به استثنای احتمالی اگر پردازنده از فیلدهای خاص پشتیبانی داخلی داشته باشد). «رویکرد ASIC frontend» ممکن است برخی از این هزینه‌ها را کاهش دهد، اما در حال حاضر در انواع برنامه‌هایی که می‌تواند پشتیبانی کند محدود است.

تنگناهای باطن چیست؟

SNARK ها برای رضایت مداری معمولاً با ترکیب یک پروتکل از لحاظ نظری امن اطلاعاتی به نام "طراحی می شوند.IOP چند جمله ایبا یک پروتکل رمزنگاری به نامطرح تعهد چند جمله ای" در بیشتر موارد، گلوگاه بتن برای اثبات کننده، طرح تعهد چند جمله ای است. به‌ویژه، این SNARK‌ها از نظر رمزنگاری، به یک یا چند چند جمله‌ای متعهد می‌شوند که درجه آنها (حداقل) است. |C|، تعداد گیت های مدار C. 

به نوبه خود، گلوگاه بتنی در طرح تعهد چند جمله ای به طرح مورد استفاده و اندازه مدار بستگی دارد. اما همیشه یکی از سه عملیات زیر خواهد بود: محاسبه FFTها، توان در یک گروه رمزنگاری یا مرکل هشینگ. Merkle-hashing معمولاً تنها در صورتی یک گلوگاه است که مدار کوچک باشد، بنابراین ما بیشتر در مورد آن بحث نمی کنیم. 

تعهدات چند جمله ای بر اساس گزارش گسسته

در تعهدات چند جمله ای بر اساس سختی مسئله لگاریتم گسسته در یک گروه رمزنگاری G (KZG, ضد گلوله, کرجی ته پهن ماهیگیریو Hyrax-commit، پروور باید a را محاسبه کند تعهد بردار پدرسن به ضرایب چند جمله ای این شامل یک نمایی چند جمله ای است که اندازه آن برابر با درجه چند جمله ای است. در SNARK ها، این درجه معمولاً اندازه است |C| از مدار C.

ساده‌لوحانه انجام شد، اندازه چند نما |C| حدود 1.5 نیاز دارد·|C|·ورود به سیستم |G| ≈ 400·|C| عملیات گروهی، جایی که |G| تعداد عناصر گروه را نشان می دهد G. با این حال، رویکردی به نام الگوریتم پیپنگر وجود دارد که می‌تواند این میزان را تقریباً کاهش دهد. |C|. برای مدارهای بزرگ (مثلاً |C| ≥ 225) این گزارش |C| ضریب به طور مشخص می تواند 25 یا بیشتر باشد، یعنی برای مدارهای بزرگ، انتظار داریم که تعهد برداری پدرسن ممکن است با کمی بیش از 10 قابل محاسبه باشد.·|C| عملیات گروهی هر عملیات گروهی به نوبه خود (به عنوان یک توپ بسیار خشن) حدود 10 برابر کندتر از یک عملیات میدان محدود است. SNARK هایی که از این تعهدات چند جمله ای استفاده می کنند به همان اندازه گران هستند P حدود 100·|C| عملیات میدانی 

متأسفانه، SNARK های موجود دارای سربار اضافی در بالای ضریب 100 برابری بالا هستند. مثلا:

• اسپارتیپروور که از تعهد چند جمله ای Hyrax استفاده می کند، باید انجام دهد |C|^½ بسیاری از چند توان هر کدام به اندازه |C|^½، تضعیف سرعت الگوریتم پیپنگر با ضریب تقریباً دو. 
• In گروت16, P باید روی یک گروه مناسب برای جفت شدن کار کند، که عملیات آن معمولاً حداقل 2 برابر کندتر از گروه هایی است که جفت دوستانه نیستند. P همچنین باید به جای 3، 1 چند نمایی انجام دهد. در مجموع، این منجر به کاهش سرعت ضریب 6 اضافی نسبت به 100 می شود.·|C| برآورد بالا 
• نیزه ماهی و PlonK همچنین به جفت‌ها نیاز دارند و اثبات‌کننده‌های آنها به طور قابل‌توجهی بیش از 3 چند جمله‌ای را متعهد می‌کنند. 
• برای هر SNARK که استفاده می کند ضد گلوله (به عنوان مثال، Halo2، که تقریباً PlonK است اما به جای تعهدات چند جمله ای KZG، ضد گلوله است)، پروور مجبور است بسیاری از نمایی های چند جمله ای را به صورت لگاریتمی در مرحله "باز کردن" طرح تعهد محاسبه کند، و این تا حد زیادی هر گونه سرعت Pippenger را پاک می کند. 

به طور خلاصه، SNARK های شناخته شده ای که از تعهدات برداری Pedersen استفاده می کنند، به نظر می رسد که دارای سربار باطنی حداقل 200x و تا 1000x یا بیشتر هستند. 

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

برای SNARK هایی که از سایر تعهدات چند جمله ای استفاده می کنند (مانند رایگان و Ligero-commitگلوگاه این است که پروور باید FFT های بزرگ را انجام دهد. به عنوان مثال، در AIR های درجه 2 تولید شده توسط قاهره (با 51 ستون و T ردیف‌ها، یکی در هر مرحله از CPU Cairo)، پروور مستقر StarkWare حداقل 2 FFT در هر ستون، به طول بین 16 ·T و 32 ·T. ثابت ها 16 و 32 به پارامترهای داخلی FRI که توسط StarkWare تنظیم شده است بستگی دارد و می تواند کاهش یابد - اما به قیمت افزایش هزینه های تأیید. 

به طور خوش بینانه، یک FFT به طول 32·T حدود 64 طول می کشد·T·ورود به سیستم (32T) ضرب میدان. این بدان معناست که حتی برای مقادیر نسبتاً کوچک از T (به عنوان مثال، T ≥ 2²⁰، تعداد عملیات میدانی در هر ستون حداقل 64 است·25·T= 1600·T. بنابراین به نظر می رسد که سربار باطن حداقل هزاران نفر باشد. علاوه بر این، این امکان وجود دارد که FFT های بزرگ با پهنای باند حافظه بیش از عملیات میدانی تنگنا شوند. 

در برخی زمینه‌ها، سربار Backend SNARK‌هایی که FFT‌های بزرگ را انجام می‌دهند را می‌توان با تکنیکی به نام proof aggregation کاهش داد. برای جمع آوری، این به این معنی است P (سرویس جمع آوری) دسته بزرگی از تراکنش ها را به مثلاً 10 دسته کوچکتر تقسیم می کند. برای هر دسته کوچک i, P یک اثبات SNARK تولید می کند πi از اعتبار دسته ولی P این شواهد را برای اتریوم ارسال نمی کند، زیرا این امر منجر به افزایش تقریبا 10 برابری هزینه های گاز می شود. در عوض، SNARK دوباره اعمال می شود، این بار برای ارائه یک اثبات π ایجاد آن P می داند π₁ ...،π₁₀. یعنی شاهد که P ادعای دانستن ده دلیل π است₁,…,π₁₀و بررسی مستقیم شاهد رویه تأیید SNARK را برای هر یک از شواهد اعمال می کند. این اثبات واحد π به اتریوم پست شده است. 

در تعهدات چند جمله ای مانند FRI و Ligero-commit، تنش شدیدی بین وجود دارد P زمان و V هزینه ها، با پارامترهای داخلی که به عنوان دستگیره ای عمل می کنند که می تواند یکی را با دیگری عوض کند. از آنجا که π₁ ,…,π₁₀ در اتریوم پست نمی‌شوند، دستگیره را می‌توان تنظیم کرد تا این اثبات‌ها بزرگ هستند و تولید آنها سریعتر است. فقط در کاربرد نهایی SNARK، برای تجمیع π₁ ,…,π₁₀ به یک اثبات واحد π, آیا طرح تعهد نیاز به پیکربندی برای اطمینان از اثبات کوچک دارد؟ 

StarkWare در نظر دارد تا تجمع اثباتی را مستقر کند بی واسطه. این نیز محور پروژه هایی مانند پلونکی 2.

گلوگاه های دیگر برای مقیاس پذیری SNARK چیست؟

این پست بر روی اثبات متمرکز شده است زمان، اما سایر هزینه های اثباتی نیز می توانند گلوگاه مقیاس پذیری باشند. برای مثال، برای بسیاری از بک‌اندهای SNARK، پروور باید چندین عنصر فیلد را برای هر دروازه ذخیره کند C، و این هزینه فضا می تواند بسیار زیاد باشد. مثلا یک برنامه ψ اجرا در یک ثانیه روی یک لپ تاپ می تواند شاید یک میلیارد عملیات ابتدایی را روی یک پردازنده مدرن انجام دهد. همانطور که دیدیم، به طور کلی باید انتظار داشت C برای چنین عملیاتی به بیش از 100 گیت نیاز است. این به معنای 100 میلیارد دروازه است که بسته به SNARK، می تواند ده ها یا صدها ترابایت فضا برای P. 

مثال دیگر: بسیاری از SNARK های محبوب (به عنوان مثال، PlonK, نیزه ماهی, گروت16) برای ایجاد یک «کلید اثبات» ساختاریافته به یک «مراسم راه اندازی مورد اعتماد» نیاز دارید، که باید توسط پروور ذخیره شود. تا جایی که من می دانم، بزرگترین چنین مراسمی یک کلید اثباتی تولید کرد که قادر به پشتیبانی از مدارهای حدود 2 بود²⁸≈دروازه 250 میلیون اندازه کلید اثبات چند ده گیگابایت است. 

در شرایطی که تجمیع اثبات امکان پذیر است، این تنگناها را می توان تا حد زیادی کاهش داد. 

نگاه به آینده: چشم انداز برای SNARK های مقیاس پذیرتر

هر دو سربار frontend و backend می توانند سه مرتبه یا بیشتر باشند. آیا می‌توان انتظار داشت که این موارد در آینده نزدیک به میزان قابل توجهی کاهش یابد؟ 

من فکر می کنم ما - تا یک نقطه. اول، سریعترین backendهای امروزی (مثلاً اسپارتی و ترمز کردنو SNARK های دیگر که ترکیبی از پروتکل چک جمع با تعهدات چند جمله‌ای) اثبات‌های بزرگی دارند - معمولاً جذر در اندازه مدار - بنابراین مردم واقعاً از آنها استفاده نمی‌کنند. من انتظار دارم که اندازه اثبات و زمان تأیید کننده در آینده نزدیک از طریق ترکیب عمق یک با SNARK های مقاوم کوچک به طور معنی داری کاهش یابد. مشابه تجمیع اثبات، این بدان معنی است که یک اثبات کننده ابتدا یک اثبات SNARK ایجاد می کند π با SNARK "سریع، اثبات بزرگ"، اما ارسال نکنید π به V. نسبتا، P از یک SNARK مقاوم کوچک برای تولید یک اثبات استفاده می کند π' که می داند π, و ارسال کنید π' به V. این می‌تواند مقداری از هزینه‌های سربار SNARK‌هایی را که امروزه محبوب هستند، کاهش دهد. 

دوم، شتاب سخت افزاری می تواند کمک کند. یک قانون کلی بسیار خشن این است که GPU ها می توانند سرعت 10 برابری را نسبت به CPU خریداری کنند و ASIC ها سرعت 10 برابری را نسبت به GPU ها خریداری کنند. با این حال، من سه نگرانی در این زمینه دارم. اول، FFT های بزرگ ممکن است به جای عملیات میدانی، با پهنای باند حافظه تنگنا شوند، بنابراین SNARK هایی که چنین FFT هایی را انجام می دهند ممکن است سرعت های محدودی را از سخت افزار تخصصی مشاهده کنند. دوم، در حالی که این پست بر روی گلوگاه تعهد چند جمله‌ای متمرکز شده است، بسیاری از SNARK‌ها به اثبات‌کننده نیاز دارند تا عملیات‌های دیگری را انجام دهد که فقط کمی هزینه کمتری دارند. بنابراین شکستن گلوگاه تعهد چند جمله ای (به عنوان مثال، افزایش سرعت چند نمایی در SNARK های مبتنی بر log گسسته) ممکن است یک عملیات گلوگاه جدید ایجاد کند که خیلی بهتر از قبلی نیست. (به عنوان مثال، SNARK ها از جمله Groth16، Marlin، و PlonK علاوه بر نمایی های چندگانه، FFT ها را نیز انجام می دهند.) در نهایت، میدان‌ها و منحنی‌های بیضوی که منجر به کارآمدترین SNARK‌ها می‌شوند ممکن است برای مدتی به تکامل خود ادامه دهند و این ممکن است چالش‌هایی را برای شتاب پروور مبتنی بر ASIC ایجاد کند.

در بخش جلویی، ممکن است به طور فزاینده‌ای متوجه شویم که رویکرد «شبیه‌ساز CPU» پروژه‌هایی مانند Cairo، RISC Zero، zkEVMs، و دیگران در واقع به خوبی (از نظر عملکرد) با پیچیدگی مجموعه‌های دستورالعمل CPU مقیاس می‌شوند. در واقع، این دقیقاً امید پروژه های مختلف zkEVM است. این ممکن است به این معنی باشد که در حالی که سربار frontend سه مرتبه یا بیشتر باقی می‌ماند، فرانت‌اندها از VMهایی پشتیبانی می‌کنند که به طور فزاینده‌ای با معماری‌های واقعی CPU مطابقت دارند. یکی از نگرانی‌های جبران‌کننده این است که ممکن است قسمت‌های جلویی پیچیده و ممیزی آن دشوار شود، زیرا ابزارهای رمزگذاری شده دستی که دستورالعمل‌های پیچیده‌تر را به‌طور فزاینده‌ای اجرا می‌کنند، افزایش می‌یابد. روش های تأیید رسمی احتمالاً نقش مهمی در رسیدگی به این نگرانی ایفا خواهند کرد. 

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

***

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

***

تشکر و قدردانی: سپاسگزارم النا برگر برای پیشنهاد موضوع این پست، و به آراسو آرون، جوزف بونوو سام راگزدیل برای نظرات روشنگر همچنین از سردبیرم تشکر ویژه دارم تیم سالیوان.

***

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

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

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