ما مدت هاست که به موضوع ناشناس بودن در ارزهای رمزنگاری شده علاقه مند بوده ایم و سعی می کنیم توسعه فناوری ها را در این زمینه دنبال کنیم. در مقالات خود ما قبلاً به طور مفصل اصول عملیات را مورد بحث قرار داده ایم در مونرو، و همچنین انجام شد فناوری های موجود در این زمینه با این حال، امروزه همه ارزهای رمزنگاری ناشناس بر اساس مدل داده پیشنهادی بیت کوین - خروجی تراکنش خرج نشده (از این پس UTXO) ساخته شده اند. برای بلاک چین‌های مبتنی بر حساب مانند اتریوم، راه‌حل‌های موجود برای اجرای ناشناس بودن و محرمانگی (به عنوان مثال، یا ) سعی کرد مدل UTXO را در قراردادهای هوشمند تکرار کند.
در فوریه 2019، گروهی از محققان دانشگاه استنفورد و تحقیقات ویزا منتشر شد "Zether: به سوی حفظ حریم خصوصی در دنیای قراردادهای هوشمند." نویسندگان اولین کسانی بودند که رویکردی برای تضمین ناشناس بودن در بلاک چین‌های مبتنی بر حساب پیشنهاد کردند و دو نسخه از یک قرارداد هوشمند را ارائه کردند: برای معاملات محرمانه (پنهان کردن موجودی‌ها و مبالغ انتقال) و ناشناس (مخفی کردن گیرنده و فرستنده). ما فناوری پیشنهادی را جالب می‌دانیم و می‌خواهیم طراحی آن را به اشتراک بگذاریم، همچنین در مورد اینکه چرا مشکل ناشناس ماندن در بلاک‌چین‌های مبتنی بر حساب کاربری بسیار دشوار تلقی می‌شود و آیا نویسندگان موفق به حل کامل آن شده‌اند یا خیر صحبت کنیم.
درباره ساختار این مدل های داده
در مدل UTXO، یک تراکنش از «ورودی ها» و «خروجی ها» تشکیل شده است. یک آنالوگ مستقیم "خروجی ها" اسکناس های موجود در کیف پول شما است: هر "خروجی" مقداری ارزش دارد. وقتی به شخصی پول می‌دهید (یک تراکنش را تشکیل می‌دهید) یک یا چند «خروجی» را خرج می‌کنید، در این صورت آنها به «ورودی» تراکنش تبدیل می‌شوند و بلاک چین آنها را به‌عنوان خرج شده علامت‌گذاری می‌کند. در این حالت، گیرنده پرداخت شما (یا خود شما، در صورت نیاز به تغییر) "خروجی های" تولید شده جدید را دریافت می کند. این را می توان به صورت شماتیک به صورت زیر نشان داد:
بلاک چین های مبتنی بر حساب بسیار شبیه به حساب بانکی شما ساختار یافته اند. آنها فقط با مبلغ موجود در حساب شما و مبلغ انتقال سروکار دارند. هنگامی که مقداری از حساب خود را انتقال می دهید، هیچ "خروجی" را نمی سوزانید، شبکه نیازی به یادآوری ندارد که کدام سکه ها خرج شده اند و کدام ها خرج نشده اند. در ساده‌ترین حالت، تأیید تراکنش به بررسی امضای فرستنده و مبلغ موجودی او خلاصه می‌شود:
تجزیه و تحلیل فناوری
در مرحله بعد، در مورد نحوه پنهان کردن مبلغ تراکنش، گیرنده و فرستنده توسط Zether صحبت خواهیم کرد. همانطور که اصول عملکرد آن را شرح می دهیم، تفاوت های نسخه های محرمانه و ناشناس را یادداشت خواهیم کرد. از آنجایی که اطمینان از محرمانگی در بلاک چین‌های مبتنی بر حساب بسیار آسان‌تر است، برخی از محدودیت‌های اعمال‌شده توسط ناشناس‌سازی برای نسخه محرمانه این فناوری مرتبط نخواهد بود.
مخفی کردن موجودی و مبالغ انتقال
یک طرح رمزگذاری برای رمزگذاری موجودی ها و انتقال مقادیر در Zether استفاده می شود . به صورت زیر عمل می کند. وقتی آلیس می خواهد باب را بفرستد b سکه بر اساس آدرس (کلید عمومی آن) Y، او یک عدد تصادفی را انتخاب می کند r و مقدار را رمزگذاری می کند:
جایی که C - مقدار رمزگذاری شده D - مقدار کمکی لازم برای رمزگشایی این مقدار، G - یک نقطه ثابت روی منحنی بیضوی، وقتی در کلید مخفی ضرب شود، کلید عمومی به دست می آید.
هنگامی که باب این مقادیر را دریافت می کند، به سادگی آنها را به همان روش به موجودی رمزگذاری شده خود اضافه می کند، به همین دلیل است که این طرح راحت است.
به طور مشابه، آلیس همان مقادیر را از تعادل خود کم می کند Y از کلید عمومی شما استفاده می کند.
مخفی کردن گیرنده و فرستنده
به هم ریختن «خروجی ها» در UTXO به روزهای اولیه رمزارزها برمی گردد و به پنهان کردن فرستنده کمک می کند. برای انجام این کار، خود فرستنده هنگام انتقال، «خروجی‌های» تصادفی را در بلاک چین جمع‌آوری می‌کند و آنها را با خودش مخلوط می‌کند. سپس، او «خروجی‌ها» را با امضای حلقه امضا می‌کند – یک مکانیسم رمزنگاری که به او اجازه می‌دهد تأییدکننده را متقاعد کند که سکه‌های فرستنده در میان «خروجی‌های» موجود است. خود سکه های مخلوط البته خرج نمی شود.
با این حال، ما نمی‌توانیم خروجی‌های جعلی برای مخفی کردن گیرنده تولید کنیم. بنابراین، در UTXO، هر "خروجی" آدرس منحصر به فرد خود را دارد و از نظر رمزنگاری به آدرس گیرنده این سکه ها پیوند داده می شود. در حال حاضر هیچ راهی برای شناسایی رابطه بین آدرس خروجی منحصر به فرد و آدرس گیرنده بدون دانستن کلیدهای مخفی آن وجود ندارد.
در مدل مبتنی بر حساب، ما نمی‌توانیم از آدرس‌های یکبار مصرف استفاده کنیم (در غیر این صورت مدل «خروج» خواهد بود). بنابراین، گیرنده و فرستنده باید در میان حساب‌های دیگر در بلاک چین ترکیب شوند. در این حالت، یک سکه 0 رمزگذاری شده از حساب های مختلط بدهکار می شود (یا اگر گیرنده مختلط باشد، 0 اضافه می شود)، بدون اینکه واقعاً موجودی واقعی آنها تغییر کند.
از آنجایی که فرستنده و گیرنده همیشه یک آدرس دائمی دارند، استفاده از گروه‌های یکسان برای مخلوط کردن هنگام انتقال به آدرس‌های یکسان ضروری است. نگاه کردن به این موضوع با یک مثال ساده تر است.
فرض کنید آلیس تصمیم دارد به خیریه باب کمک کند، اما ترجیح می دهد که این انتقال برای یک ناظر خارجی ناشناس بماند. سپس برای اینکه خود را در قسمت فرستنده پنهان کند، وارد حساب های آدام و ادل نیز می شود. و برای مخفی کردن باب، حساب های بن و بیل را در قسمت گیرنده اضافه کنید. آلیس با مشارکت بعدی تصمیم گرفت الکس و آماندا را در کنار او و بروس و بنجن را در کنار باب بنویسد. در این مورد، هنگام تجزیه و تحلیل زنجیره بلوکی، در این دو تراکنش تنها یک جفت شرکت کننده متقاطع وجود دارد - آلیس و باب، که این تراکنش ها را بی نام می کند.
مسابقات تراکنش
همانطور که قبلاً اشاره کردیم، برای پنهان کردن موجودی شما در سیستم های مبتنی بر حساب، کاربر موجودی و مبلغ انتقال خود را رمزگذاری می کند. در عین حال، او باید ثابت کند که موجودی حسابش منفی است. مشکل این است که هنگام ایجاد یک تراکنش، کاربر مدرکی در مورد وضعیت فعلی حساب خود ایجاد می کند. اگر باب تراکنشی را برای آلیس بفرستد و قبل از تراکنش ارسال شده توسط آلیس پذیرفته شود، چه اتفاقی می افتد؟ سپس معامله آلیس نامعتبر تلقی می شود، زیرا اثبات تعادل قبل از پذیرفته شدن معامله باب ساخته شده است.
اولین تصمیمی که در چنین شرایطی گرفته می شود، مسدود کردن حساب تا زمان انجام تراکنش است. اما این رویکرد مناسب نیست، زیرا علاوه بر پیچیدگی حل چنین مشکلی در یک سیستم توزیع شده، در یک طرح ناشناس مشخص نخواهد شد که حساب چه کسی مسدود شود.
برای حل این مشکل، این فناوری تراکنش‌های ورودی و خروجی را از هم جدا می‌کند: مخارج تأثیر فوری بر ترازنامه دارد، در حالی که دریافت‌ها اثر تأخیری دارند. برای انجام این کار، مفهوم "عصر" معرفی شده است - گروهی از بلوک ها با اندازه ثابت. "دوران" فعلی با تقسیم ارتفاع بلوک بر اندازه گروه تعیین می شود. هنگام پردازش تراکنش، شبکه بلافاصله موجودی فرستنده را به روز می کند و وجوه گیرنده را در یک مخزن ذخیره می کند. وجوه انباشته تنها زمانی در اختیار گیرنده قرار می گیرد که «دوران» جدیدی آغاز شود.
در نتیجه، کاربر می تواند بدون در نظر گرفتن تعداد دفعات دریافت وجوه (البته تا جایی که موجودی او اجازه می دهد) تراکنش ها را ارسال کند. اندازه دوره بر اساس سرعت انتشار بلوک ها در شبکه و سرعت ورود یک تراکنش به یک بلوک تعیین می شود.
این راه حل برای نقل و انتقالات محرمانه به خوبی جواب می دهد، اما با تراکنش های ناشناس، همانطور که در ادامه خواهیم دید، مشکلات جدی ایجاد می کند.
محافظت در برابر حملات تکراری
در بلاک چین‌های مبتنی بر حساب، هر تراکنش توسط کلید خصوصی فرستنده امضا می‌شود، که تأییدکننده را متقاعد می‌کند که تراکنش اصلاح نشده و توسط صاحب این کلید ایجاد شده است. اما اگر مهاجمی که به کانال انتقال گوش می‌داد این پیام را رهگیری کند و دقیقاً همان پیام دوم را ارسال کند، چه؟ تأیید کننده امضای تراکنش را تأیید می کند و به نویسندگی آن متقاعد می شود و شبکه دوباره همان مبلغ را از موجودی فرستنده حذف می کند.
به این حمله حمله تکراری می گویند. در مدل UTXO، چنین حملاتی مرتبط نیستند، زیرا مهاجم سعی می کند از خروجی های صرف شده استفاده کند که به خودی خود معتبر نیست و توسط شبکه رد می شود.
برای جلوگیری از این اتفاق، یک فیلد با داده‌های تصادفی در تراکنش تعبیه می‌شود که به آن nonce یا به سادگی «salt» می‌گویند. هنگام ارسال مجدد تراکنش با salt، تأیید کننده به دنبال این است که ببیند آیا nonce قبلاً استفاده شده است یا خیر و اگر نه، تراکنش را معتبر می‌داند. برای اینکه کل تاریخچه نانسس های کاربر در بلاک چین ذخیره نشود، معمولاً در اولین تراکنش برابر با صفر تنظیم می شود و سپس یک افزایش می یابد. شبکه فقط می تواند بررسی کند که عدم انجام تراکنش جدید با تراکنش قبلی متفاوت است.
در طرح انتقال ناشناس، مشکل اعتبار سنجی nonces تراکنش به وجود می آید. ما نمی‌توانیم به طور صریح nonce را به آدرس فرستنده متصل کنیم، زیرا بدیهی است که این انتقال را بی‌نام می‌کند. همچنین نمی‌توانیم یکی را به غیر حساب‌های شرکت‌کننده اضافه کنیم، زیرا ممکن است با سایر انتقال‌های در حال پردازش مغایرت داشته باشد.
نویسندگان Zether پیشنهاد می‌کنند بسته به «عصر»، nonce را به صورت رمزنگاری تولید کنند. مثلا:
اینجا x کلید مخفی فرستنده است و Gepoch - یک مولد اضافی برای دوره، که با هش کردن رشته ای به شکل 'Zether +' به دست می آید. اکنون به نظر می رسد مشکل حل شده است - ما عدم وجود فرستنده را فاش نمی کنیم و با عدم مشارکت شرکت کنندگان درگیر دخالت نمی کنیم. اما این رویکرد یک محدودیت جدی را تحمیل می کند: یک حساب نمی تواند بیش از یک تراکنش در هر «دوره» ارسال کند. این مشکل، متأسفانه، حل نشده باقی مانده است، و در حال حاضر نسخه ناشناس Zether، به نظر ما، به سختی برای استفاده مناسب است.
پیچیدگی مدارک دانش صفر
در UTXO، فرستنده باید به شبکه ثابت کند که مبلغ منفی را خرج نمی کند، در غیر این صورت امکان تولید سکه های جدید از هوا وجود دارد (چرا این امکان وجود دارد، ما در یکی از موارد قبلی نوشتیم. ). و همچنین "ورودی ها" را با امضای حلقه امضا کنید تا ثابت کنید که در میان سکه های مخلوط شده وجوه متعلق به او وجود دارد.
در نسخه ناشناس بلاک چین مبتنی بر حساب، عبارات اثبات بسیار پیچیده‌تر هستند. فرستنده ثابت می کند که:
- مبلغ ارسالی مثبت است.
- موجودی غیرمنفی باقی می ماند.
- فرستنده مبالغ انتقال (از جمله صفر) را به درستی رمزگذاری کرده است.
- موجودی موجودی فقط برای فرستنده و گیرنده تغییر می کند.
- فرستنده صاحب کلید خصوصی حساب کاربری خود است و در واقع در لیست فرستنده ها (در میان افراد درگیر) قرار دارد.
- Nonce استفاده شده در تراکنش به درستی ترکیب شده است.
برای چنین اثبات پیچیده ای، نویسندگان از مخلوطی استفاده می کنند (به هر حال یکی از نویسندگان در ایجاد آن شرکت داشت) و که به آنها سیگما گلوله می گویند. اثبات رسمی چنین بیانیه ای کار نسبتاً دشواری است و تعداد افرادی را که مایل به اجرای فناوری هستند بسیار محدود می کند.
نتیجه؟
به نظر ما، بخشی از Zether که حریم خصوصی را به بلاک چین‌های مبتنی بر حساب کاربری می‌آورد، در حال حاضر قابل استفاده است. اما در حال حاضر، نسخه ناشناس این فناوری محدودیت های جدی در استفاده از آن و پیچیدگی آن در اجرای آن اعمال می کند. با این حال نباید نادیده گرفت که نویسندگان آن را تنها چند ماه پیش منتشر کردند و شاید شخص دیگری راه حلی برای مشکلات امروز پیدا کند. بالاخره علم اینگونه انجام می شود.
منبع: www.habr.com