آستانه ZCASH معاملات محافظت شده: اثبات مفهوم

در اوایل سال جاری با بنیاد ZCASH همکاری کردیم تا امضاهای آستانه ای را به Sapling ارائه دهیم. در این وبلاگ می خواهیم در مورد پیشرفت خود و برخی از نتایج هیجان انگیز که تاکنون کسب کرده ایم با جامعه به اشتراک بگذاریم. نکته برجسته این است که برای اولین بار توانستیم یک گره کامل ZCASH را اجرا کنیم ، برای پشتیبانی از 2 طرف معاملات محافظ SAPLING. اثبات مفهوم از این طریق منتشر می شود. این وبلاگ به عنوان یک سری چالش هایی که با آن روبرو هستیم بسیار فنی و ساختار یافته است.

انگیزه و پس زمینه

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

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

همچنین برای بارگذاری محاسبات سنگین درگیر به شخص ثالث بدون ایجاد امنیت در امنیت مفید است (به توجه به مشخصات پروتکل Sapling ، بخش 4. 13 مراجعه کنید).

با این حال ، SAPLING از چند امضای با حریم خصوصی پشتیبانی نمی کند ، که ما در اینجا "معاملات محافظت شده از آستانه" می نامیم. این یک ویژگی اساسی در اکثر blockchains است ، و به ساختارهای مختلف دسترسی می تواند یک معامله را امضا کند و عناصر HW ایمن را به فرآیند امضای اضافه کند. در این پست وبلاگ ، ما یک قدم به قدم آنچه را که برای اضافه کردن چنین پشتیبانی مستقیماً به ZCASH Core انجام می شود ، نشان می دهیم.

چالش شماره 1: طراحی پروتکل

طرح امضای Sapling ، به نام RedJubJub ، یک طرح امضاء شبیه Schnorr با برخی از گزینه های طراحی اضافی است که توسط رمزنگاران ECC ساخته شده است ، که بخشی از آن از طرح امضای EDDSA الهام گرفته است.

ساختار اصلی درخت در نهال ، همانطور که در زیر مشاهده می شود درگیر است. چالش ما این بود که به طرحی ارائه دهیم که به خواسته های زیر پاسخ دهد:

1. می تواند برای تعداد کلی از امضا کنندگان واقعی (آستانه T) از گروه امضا کنندگان بالقوه (N) کار کند
2. ایمن قابل اثبات
3. هیچ تغییر قابل توجهی در درخت یا پروتکل کلیدی وجود ندارد ، یعنی هیچ تغییری در ZK-SNARK که برای اثبات دانش برخی از کلیدها به عنوان بخشی از بیانیه استفاده می شود ، وجود ندارد.

توضیحی از multiparty redjubjub ما را می توان در GitHub ما یافت.

ما در نهایت پایین ترین سطح درخت کلید را تغییر دادیم: ask دیگر نتیجه اشتقاق کلید از sk نیست، بلکه به صورت توزیع شده بین طرف های غیرقابل اعتماد محاسبه می شود. در واقع ask هرگز در یک مکان واحد ساخته نمی شود. طرفین فقط ak مشتق شده را به اشتراک می گذارند که به عنوان بخشی از پروتکل Sapling نیز با شخص ثالثی به اشتراک گذاشته می شود که به محاسبه اثبات دانش صفر کمک می کند. ما فرض کردیم که این حزب ممکن است در امضای چند حزبی نیز شرکت کند (شخص ثالث نمی تواند به تنهایی امضایی تولید کند و ما هیچ قدرت اضافی به او نمی دهیم). این بدان معنی است که حریم خصوصی ما در محاسبات چند جانبه بر خلاف پروتکل اصلی Zcash علیه بلاک چین است، اما هیچ حریم خصوصی بین طرف هایی که پروتکل را اجرا می کنند وجود ندارد. ما فکر می کنیم که قابل قبول است زیرا بیشتر موارد استفاده از یک طرف است که می خواهد محاسبات را روی چندین دستگاه خود انجام دهد. ما به کارهای آینده می رویم تا این طرح برای برخی از طرف های امضاکننده نیز خصوصی شود.

ما از امنیت مبتنی بر شبیه سازی برای طرح خود استفاده می کنیم و از هیچ فرض امنیتی اضافی در مورد آنچه قبلاً در Sapling استفاده شده است استفاده نمی کنیم. این پروتکل با سربار کوچک در محاسبات بسیار کارآمد است. به احتمال زیاد برخی از احزاب می توانند بر روی دستگاه های سخت افزاری اجرا شوند.

چالش شماره 2: استفاده مجدد از رمزنگاری Zcash

همانطور که در فضای بلاک چین رایج است، همه چیز بر اساس رمزنگاری منحنی بیضوی ساخته شده است. Sapling از یک منحنی بیضی منحصر به فرد به نام Jubjub استفاده می کند: Jubjub یک منحنی ادواردز پیچ خورده است که بر روی میدان اسکالر BLS12-381 ساخته شده است. از آنجایی که این EC نسبتاً جدید است و عمدتاً در Zcash استفاده می شود، تنها اجرای محاسبات Jubjub همانی است که در Zcash استفاده می شود.

خبر بد این است که ما به محاسبات چند جانبه نیاز داریم تا برخی از محاسبات با هدف عمومی را روی نقاط Jubjub EC و میدان اسکالر BLS12-381 اجرا کند.

متأسفانه، کتابخانه Jubjub برای پشتیبانی از Zcash Sapling و نه به اندازه API ساخته شده است که می تواند توسط سایر مصرف کنندگانی که می خواهند با این منحنی کار کنند، استفاده کنند. خبر خوب این است که پیاده سازی Zcash، LibRustZcash یکپارچه است: به زبان Rust نوشته شده است که زبان انتخابی ما نیز هست، دائماً در حال بررسی و ممیزی است و یک اشکال در آنجا می تواند منجر به اشکال در Zcash شود.

کاری که ما در نهایت انجام دادیم این است که LibRustZcash را جدا کردیم، آن را از کدهای غیرضروری حذف کردیم (مثلاً دانش مربوط به صفر) و آن را به عنوان بخشی از کتابخانه منحنی بیضی با هدف کلی خود وصل کردیم. محصول جانبی این است که اکنون هر کسی می تواند از Jubjub برای هر محاسباتی به روشی ایمن استفاده کند.

چالش شماره 3: ادغام Multiparty-RedjubJub در گره کامل ZCASH

اکنون که ما بلوک های ساختمانی رمزنگاری شده و پروتکل به روز شده را داشتیم ، نوشتن "بهشت-شهر" در واقع ساده بود: یک اثبات Redjubjub دو طرفه از کتابخانه مفهومی. این به خوبی در حالت مستقل کار کرده است اما ارزش زیادی ندارد مگر اینکه بتوانیم نشان دهیم که می تواند به عنوان بخشی از کد گره کامل کار کند.

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

چند نظر در معماری کامل گره ZCASH وجود دارد - این یک کد C ++ است که روش هایی را از LibrustzCash Rust Code برای رمزنگاری در پروتکل فراخوانی می کند. وابستگی ها "به دست آمده" هستند به گونه ای که هر کتابخانه ای که کد ZCash از آن استفاده می کند ، باید به صورت دستی اضافه شود و در برابر چک های هارد کدگذاری شده تأیید شود.

از آنجا که کد ما به دست نیامده است ، ما کتابخانه بهشت-شهر را بازنویسی می کنیم تا درخت وابستگی آن را به حداقل برساند ، ٪ 80 ، استفاده مجدد از کتابخانه های زنگ زدگی که در حال حاضر بخشی از پایگاه کد ZCASH هستند. بقیه به صورت دستی اضافه شدند. ما نسل کلیدی توزیع شده بهشت را بهشت و روشهای امضای توزیع شده را به عنوان جایگزینی برای برخی از روشهای اصلی در LibrustzCash وصل کردیم و از برخی منطق چسب استفاده کردیم تا انواع و انواع LibrustzCash خود را سازگار کنیم. علاوه بر این ، ما تغییرات جزئی در کد C ++ ایجاد کردیم. در اینجا پیوندهایی به LibrustzCash Patched و کد Node Node Patched ZCASH وجود دارد. سرانجام ما اثبات مفهوم را در ZCASH 2. 0. 5 برای TestNet و Stand Alone Regtest اجرا می کنیم (احتمالاً باید روی نسخه های جدیدتر کار کند).

نسخه ی نمایشی

در این نسخه ی نمایشی ، ما یک گره ZCASH را در حالت Regtest (پنجره پایین) اجرا می کنیم. در پنجره فوقانی ما یک کیف پول مشتری را اداره می کنیم. در ابتدا ، کیف پول برخی از سکه ها را به آدرس شفاف و متعلق به آن معدن می کند. سپس ما یک نسل کلید 2 حزب را فراخوانی می کنیم و هر دو طرف را به صورت محلی شبیه سازی می کنیم. در نتیجه ما یک آدرس محافظ با یک کلید توزیع شده ایجاد می کنیم. ما برخی از بودجه را از آدرس شفاف به آدرس محافظ کیف پول منتقل می کنیم. سرانجام ما آدرس محافظ جدیدی را تولید می کنیم که یک پروتکل امضاء 2 طرف را برای امضای یک معامله محافظ انجام می دهیم و وجوه را به صورت خصوصی از آدرس محافظ اول به دوم منتقل می کنیم.

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

بسته شدن کلمات

امضاهای محافظ آستانه احتمالاً به عنوان بخشی از فعال سازی NU3 به Zcash می آیند. اکنون به عنوان بخشی از نقشه راه برای سال 2020 در دست مهندسان ZF است. امیدواریم که اثبات ما به عنوان یک پله پله به سمت ساختن این ابزار مفید به روش قوی باشد. ZCash یک دارایی دیجیتالی مهم با خصوصیات حریم خصوصی منحصر به فرد است. این یک کاندیدای عالی خواهد بود که در آینده در Zengo گنجانده شود. لطفاً برای هرگونه سؤال پیگیری از گروه تحقیقاتی تلگرام ما استفاده کنید.

سرانجام ما می خواهیم از آریل NOF بخاطر طراحی پروتکل و اثبات امنیت آن تشکر کنیم.