Follow Us
Facebooktwitteryoutube
YouTube
Promo
banner
Promo
banner

معرفی zk-SNARK ها

وبلاگ 1NewsD DevelopersEnterpriseBlockchain ExplainedEvent ها و کنفرانس ها Pressخبرنامه ها

مشترک شدن در خبرنامه ما.

آدرس ایمیل

ما به حریم خصوصی شما احترام می گذاریم

صفحه اصلی وبلاگ توسعه Blockchain

معرفی zk-SNARK ها

مروری بر اثبات دانش صفر و نحوه ادغام zk-SNARK ها در Ethereum. توسط ConsenSys مارس 27 ، 2017 ارسال شده در 27 مارس 2017

قهرمان خانه

در این پست هدف ما ارائه نمای کلی از zk-SNARK ها از دیدگاه عملی است. ما ریاضیات واقعی را به عنوان یک جعبه سیاه در نظر خواهیم گرفت و سعی در ایجاد شهودهایی در مورد چگونگی استفاده از آنها داریم. ما همچنین یک کار ساده از کارهای اخیر را ارائه می دهیم ادغام zk-SNARK ها در Ethereum.

اثبات دانش صفر

هدف از اثبات دانش صفر این است که یک تأیید کننده بتواند خود را متقاعد کند که یک اثبات کننده از یک پارامتر مخفی ، به نام شاهد ، که برخی از رابطه ها را برآورده می کند ، اطلاعاتی را کسب می کند ، بدون اینکه گواهی را برای تأیید کننده یا شخص دیگری نشان دهد..

ما می توانیم به طور دقیق تر این را داشته باشیم که داشتن یک برنامه ، نشانگر C ، گرفتن دو ورودی: C (x، w). ورودی x ورودی عمومی است و w ورودی مخفی شاهد است. خروجی برنامه بولین است ، یعنی درست یا نادرست. سپس به یک ورودی عمومی x خاص داده می شود ، ثابت کنید که اثبات کننده یک ورودی مخفی را می داند به طوری که C (x، w) == درست است.

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

برنامه مثال

فرض کنید به Bob یک هش H مقداری داده شده است ، و او مایل است مدرکی بدست آورد که آلیس مقدار s هش را برای H. می داند. به طور معمول آلیس با دادن s به Bob این را ثابت می کند ، پس از آن Bob هش را محاسبه می کند و بررسی می کند برابر است با H.

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

ما می توانیم سناریوی آلیس را با استفاده از برنامه زیر توصیف کنیم ، که در اینجا به عنوان یک تابع Javascript نوشته شده است:


تابع C (x، w) {return (sha256 (w) == x)؛} زبان کد: JavaScript (javascript)

به عبارت دیگر: این برنامه یک hash عمومی x و یک مقدار مخفی w را به خود اختصاص می دهد و اگر hash SHA-256 w برابر x باشد ، درست برمی گردد..

با ترجمه مسئله آلیس با استفاده از تابع C (x، w) متوجه می شویم که آلیس باید اثبات کند که دارای s است به طوری که C (H ، s) == درست است ، بدون اینکه لازم باشد s را نشان دهد. این مشکل کلی است که zk-SNARK ها حل می کنند.

تعریف zk-SNARK

zk-SNARK شامل سه الگوریتم G ، P ، V است که به شرح زیر تعریف شده است:

مولد کلید G یک پارامتر مخفی lambda و یک برنامه C می گیرد و دو کلید در دسترس عموم ، یک کلید اثبات کننده pk و یک کلید تأیید vk تولید می کند. این کلیدها پارامترهای عمومی هستند که فقط یک بار برای یک برنامه خاص C لازم است تولید شوند.

Pro P به عنوان ورودی کلید اثبات pk ، ورودی عمومی x و شاهد خصوصی w را می گیرد. الگوریتم اثبات prf = P (pk ، x ، w) را تولید می کند که اثبات کننده شاهد w را می شناسد و شاهد برنامه را راضی می کند.

V تأیید کننده V (vk، x، prf) را محاسبه می کند که در صورت اثبات صحت برمی گردد و در غیر این صورت نادرست است. بنابراین اگر اثبات کننده شاهد باشد شاهد رضایت C (x ، w) == درست است ، این عملکرد درست می شود.

در اینجا به پارامتر مخفی لامبدا که در ژنراتور استفاده می شود توجه کنید. این پارامتر گاهی اوقات استفاده از zk-SNARK در برنامه های دنیای واقعی را مشکل می کند. دلیل این امر این است که هرکسی این پارامتر را می داند می تواند اثبات جعلی ایجاد کند. به طور خاص ، با توجه به هر برنامه C و ورودی عمومی x ، شخصی که لامبدا را می شناسد می تواند fake_prf اثبات را تولید کند ، به طوری که V (vk ، x ، fake_prf) درست بدون دانستن راز w ارزیابی می کند.

بنابراین در واقع اجرای ژنراتور به فرایند بسیار مطمئنی نیاز دارد تا مطمئن شوید هیچ کس در مورد پارامتر در هر مکان اطلاعاتی نمی گیرد و آن را ذخیره نمی کند. این دلیل این بود مراسم بسیار مفصل تیم Zcash به منظور تولید کلید اثبات و کلید تأیید ، ضمن اطمینان از از بین رفتن پارامتر “زباله های سمی” لامبدا ، در این فرآیند انجام داد.

zk-SNARK برای برنامه نمونه ما

چگونه آلیس و باب در عمل از zk-SNARK استفاده می کنند تا آلیس ثابت کند که مقدار مخفی را در مثال بالا می داند?

اول از همه ، همانطور که در بالا بحث شد ، ما از یک برنامه تعریف شده توسط عملکرد زیر استفاده خواهیم کرد:

عملکرد C (x ، w) {بازگشت (sha256 (w) == x) ؛ } زبان کد: جاوا اسکریپت (جاوا اسکریپت)

اولین قدم این است که باب برای ایجاد کلید اثبات pk و کلید تأیید vk ژنراتور G را اجرا کند. ابتدا ، به طور تصادفی لامبدا تولید کنید و از آن به عنوان ورودی استفاده کنید:

(pk ، vk) = G (C ، لامبدا)

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

اکنون آلیس نقش یک ضرب المثل را بازی می کند. او باید ثابت کند که مقدار s هش شناخته شده H را می داند. او الگوریتم اثبات P را با استفاده از ورودی های pk ، H و s اجرا می کند تا prf اثبات را تولید کند:

prf = P (pk ، H ، s)

بعدی آلیس prf اثبات را به باب ارائه می دهد که عملکرد تأیید V (vk ، H ، prf) را اجرا می کند که در این حالت درست خواهد بود زیرا آلیس به درستی از اسرار آن آگاه است. باب می تواند اطمینان داشته باشد که آلیس راز را می دانسته است ، اما آلیس نیازی نبود که این راز را برای باب فاش کند.

کلیدهای تأیید و تأیید مجدد قابل استفاده مجدد

در مثال ما در بالا ، اگر باب بخواهد به آلیس ثابت کند که رازی را می داند ، نمی توان از zk-SNARK استفاده کرد ، زیرا آلیس نمی تواند بداند که باب پارامتر lambda را ذخیره نکرده است. باب به طور معقولانه ای قادر به اثبات جعلی است.

اگر برنامه ای برای بسیاری از افراد مفید باشد (مانند مثال Zcash) ، یک گروه مستقل قابل اعتماد جدا از آلیس و باب می تواند ژنراتور را اجرا کند و کلید اثبات pk و کلید تأیید vk را به گونه ای ایجاد کند که هیچ کس در مورد lambda اطلاعاتی کسب نکند..

هر کسی که اعتماد کند این گروه تقلب نکرده است می تواند از این کلیدها برای تعاملات بعدی استفاده کند.

zk-SNARK ها در اتریوم

توسعه دهندگان قبلاً ادغام zk-SNARK ها را در Ethereum آغاز کرده اند. این چگونه به نظر میرسد؟ به طور مشخص ، شما می توانید عناصر سازنده الگوریتم تأیید را به صورت قراردادهای از پیش تنظیم شده به Ethereum اضافه کنید. نحوه کار: تولید ژنراتور خارج از زنجیره برای تولید کلید اثبات و کلید تأیید. سپس هر اثبات کننده ای می تواند از کلید اثبات کننده برای ایجاد اثبات ، خارج از زنجیره نیز استفاده کند. سپس می توانید الگوریتم تأیید صحت عمومی را در یک قرارداد هوشمند و با استفاده از اثبات ، کلید تأیید و ورودی عمومی به عنوان پارامترهای ورودی ، اجرا کنید. سپس می توانید از نتیجه الگوریتم تأیید برای شروع سایر فعالیتهای زنجیره ای استفاده کنید.

مثال: معاملات محرمانه

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

نقشه برداری (آدرس => uint256) مانده ؛ زبان کد: جاوا اسکریپت (جاوا اسکریپت)

ما قصد داریم همان هسته اصلی را حفظ کنیم ، مگر اینکه تعادل را با هش تعادل جایگزین کنیم:

نقشه برداری (آدرس => bytes32) balanceHashes؛ زبان کد: JavaScript (javascript)

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

ما برای ارسال توکن از یک حساب به حساب دیگر از دو zk-SNARK استفاده خواهیم کرد. یک دلیل توسط فرستنده و دیگری توسط گیرنده ایجاد می شود.

به طور معمول در یک قرارداد رمز برای معتبر بودن معامله ای با اندازه اندازه ، ما باید موارد زیر را تأیید کنیم:

تعادل [از آدرس] >= ارزش

zk-SNARK های ما باید ثابت کنند که این مسئله ثابت است و همچنین هش های به روز شده با مانده های به روز شده مطابقت دارند.

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

در زیر برنامه ای است که ما برای فرستنده zk-SNARK استفاده خواهیم کرد ، جایی که مانند قبل x نشان دهنده ورودی عمومی است و w نمایانگر ورودی خصوصی است..

عملکرد senderFunction (x، w) {return (w.senderBalanceBefore > ارزش w && sha256 (مقدار w) == x.hashValue && sha256 (w.senderBalanceBeason) == x.hashSenderBalanceBefore && sha256 (w.senderBalanceBefore – w.value) == x.hashSenderBalanceAfter)} زبان کد: JavaScript (javascript)

برنامه استفاده شده توسط گیرنده به شرح زیر است:

گیرنده عملکرد عملکرد (x ، w) {بازگشت (sha256 (مقدار w) == x.hashValue && sha256 (w.receiverBalanceBeance) == x.hashReceiverBalanceBealan && sha256 (w.receiverBalanceBefore + w.value) == x.hashReceiverBalanceAfter)} زبان کد: JavaScript (javascript)

این برنامه ها بررسی می کنند که تراز ارسال شده از مقدار ارسال شده بزرگتر است و همچنین بررسی می کنند که همه هش ها مطابقت دارند. مجموعه معتبری از افراد کلیدهای تأیید و تأیید zk-SNARK های ما را تولید می کنند. بیایید آنها را confTxSenderPk ، confTxSenderVk ، confTxReceiverPk و confTxReceiverVk بنامیم.

استفاده از zk-SNARK ها در یک قرارداد نشانه چیزی شبیه به این است:

انتقال عملکرد (آدرس _to ، bytes32 hashValue ، bytes32 hashSenderBalanceAfter ، bytes32 hashReceiverBalanceAfter ، بایت zkProofSender ، بایت zkProofReceiver) {bytes32 hashSenderBalanceBefore = balanceHashes [msg.sender]؛ bytes32 hashReceiverBalanceBefore = balanceHashes [_to]؛ bool senderProofIsCorrect = zksnarkverify (confTxSenderVk ، [hashSenderBalanceBefore ، hashSenderBalanceAfter ، hashValue] ، zkProofSender)؛ bool receiverProofIsCorrect = zksnarkverify (confTxReceiverVk ، [hashReceiverBalanceBefore ، hashReceiverBalanceAfter ، hashValue] ، zkProofReceiver)؛ if (senderProofIsCorrect) && recepProofIsCorrect) {balanceHashes [msg.sender] = hashSenderBalanceAfter؛ balanceHashes [_to] = hashReceiverBalanceAfter؛ }} زبان کد: JavaScript (javascript)

بنابراین تنها به روزرسانی های موجود در بلاکچین هش مانده مانده ها است و نه موجودی ها. با این حال ، می توانیم بدانیم که تمام مانده ها به درستی به روز شده اند ، زیرا می توانیم خودمان راستی آزمایی کنیم.

جزئیات

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

  • کاربران باید ترازهای خود را در سمت مشتری پیگیری کنند ، و در صورت از دست دادن موجودی ، این رمزها قابل بازیابی نیستند. ترازوها را می توان بصورت رمزنگاری شده روی زنجیره با کلیدی که از کلید امضای مشتق شده است ، ذخیره کرد.
  • برای جلوگیری از توانایی معکوس کردن هش ها برای تعیین مانده ها ، باید ترازها از 32 بایت داده و رمزگذاری آنتروپی استفاده کنند..
  • نیاز به رسیدگی به پرونده لبه ارسال به آدرس بی استفاده دارید.
  • فرستنده برای ارسال نیاز به تعامل با گیرنده دارد. به طور بالقوه می توان سیستمی داشت که فرستنده از مدارک خود برای شروع معامله استفاده می کند. سپس گیرنده می تواند از طریق بلاکچین ببیند که آنها یک “معامله ورودی در انتظار” دارند و می توانند آن را نهایی کنند.

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

چگونه یک محصول بلاکچین موفق بسازیم

نحوه تنظیم و اجرای گره Ethereumوبینار

نحوه تنظیم و اجرای گره Ethereum

چگونه API Ethereum خود را بسازیموبینار

چگونه API Ethereum خود را بسازیم

چگونه یک نشانه اجتماعی ایجاد کنیموبینار

چگونه یک نشانه اجتماعی ایجاد کنیم

استفاده از ابزارهای امنیتی در توسعه قرارداد هوشمندوبینار

استفاده از ابزارهای امنیتی در توسعه قرارداد هوشمند

آینده دارایی های دیجیتال مالی و DeFiوبینار

آینده مالی: دارایی های دیجیتال و DeFi

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Adblock
detector