معرفی

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

همانند مفهوم رمز کاملاً قوی از رمزنگاری، پروتکل های واقعی "Publicly Verifiable Random Beacon" (از این پس PVRB) فقط سعی می کنند تا حد امکان به طرح ایده آل نزدیک شوند، زیرا در شبکه های واقعی به شکل خالص آن قابل اجرا نیست: باید به طور دقیق روی یک بیت توافق کرد، باید دورهای زیادی وجود داشته باشد و همه پیام ها باید کاملاً سریع و همیشه تحویل داده شوند. البته در شبکه های واقعی اینطور نیست. بنابراین، هنگام طراحی PVRB برای کارهای خاص در بلاک چین های مدرن، علاوه بر عدم امکان کنترل تصادفی بودن و قدرت رمزنگاری حاصل، بسیاری از مشکلات صرفاً معماری و فنی بیشتر نیز به وجود می آیند.

برای PVRB، بلاک چین خود اساسا یک رسانه ارتباطی است که در آن پیام ها = تراکنش ها است. این به شما امکان می‌دهد تا حدی از مشکلات شبکه، عدم تحویل پیام‌ها، مشکلات میان‌افزار انتزاعی بگیرید - تمام این خطرات توسط شبکه غیرمتمرکز متحمل می‌شوند و ارزش اصلی آن برای PVRB ناتوانی در ابطال یا خراب کردن تراکنش ارسال شده از قبل است. اجازه ندهید شرکت کنندگان از شرکت در پروتکل امتناع کنند، مگر اینکه حمله موفقیت آمیزی بر اساس اجماع انجام دهند. این سطح از امنیت قابل قبول است، بنابراین PVRB باید دقیقاً به اندازه زنجیره اصلی بلاک چین در برابر تبانی شرکت کنندگان مقاوم باشد. همچنین، این نشان می‌دهد که PVRB باید بخشی از اجماع باشد اگر شبکه بر روی بلاکچین اصلی توافق کند، حتی اگر در مورد تنها تصادفی منتخب نیز موافق باشد. یا، PVRB به سادگی یک پروتکل مستقل است که توسط یک قرارداد هوشمند پیاده سازی شده است که به طور ناهمزمان با توجه به بلاک چین و بلاک ها کار می کند. هر دو روش مزایا و معایب خود را دارند و انتخاب بین آنها بسیار بی اهمیت است.

دو روش برای پیاده سازی PVRB

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

قرارداد مستقل

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

گزینه با قرارداد مستقل خوب است:

• قابل حمل بودن (قراردادها را می توان از بلاک چین به بلاک چین کشید)
• سهولت اجرا و آزمایش (نوشتن و آزمایش قراردادها آسان است)
• سهولت در اجرای طرح های اقتصادی (ساده است که توکن خود را بسازید که منطق آن در خدمت اهداف PVRB باشد)
• امکان راه اندازی بر روی بلاک چین هایی که از قبل کار می کنند

معایبی هم دارد:

• محدودیت های قوی در منابع محاسباتی، حجم تراکنش و ذخیره سازی (به عبارت دیگر، cpu/mem/io)
• محدودیت در عملیات در قرارداد (همه دستورالعمل ها در دسترس نیستند، اتصال کتابخانه های خارجی دشوار است)
• ناتوانی در سازماندهی پیام‌ها سریع‌تر از تراکنش‌های موجود در بلاک چین

این گزینه برای اجرای یک PVRB مناسب است که باید در یک شبکه موجود اجرا شود، حاوی رمزنگاری پیچیده نیست و به تعداد زیادی تعامل نیاز ندارد.

اجماع یکپارچه

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

هنگام توصیف پیاده سازی PVRB در سطح اجماع شبکه، به هیچ وجه نمی توان از مسائل نهایی اجتناب کرد. نهایی بودن مکانیزمی است که در اجماع های قطعی استفاده می شود که در یک بلوک (و زنجیره منتهی به آن) که نهایی است و هرگز دور ریخته نمی شود، قفل می شود، حتی اگر یک چنگال موازی رخ دهد. به عنوان مثال، در بیت‌کوین چنین مکانیزمی وجود ندارد - اگر زنجیره‌ای با پیچیدگی بیشتر منتشر کنید، بدون در نظر گرفتن طول زنجیره‌ها، جایگزین هر زنجیره کمتر پیچیده‌تر خواهد شد. و در EOS، به عنوان مثال، آخرین بلوک های به اصطلاح آخرین بلوک های غیر قابل برگشت هستند که به طور متوسط ​​هر 432 بلوک ظاهر می شوند (12*21 + 12*15، پیش رأی + پیش تعهد). این فرآیند اساساً منتظر امضای 2/3 تولیدکنندگان بلوک (از این پس BP نامیده می شود) است. هنگامی که چنگال هایی ظاهر می شوند که قدیمی تر از آخرین LIB هستند، به سادگی دور انداخته می شوند. این مکانیسم تضمین می کند که تراکنش در بلاک چین گنجانده شده است و بدون توجه به منابعی که مهاجم در اختیار دارد، هرگز بازگردانده نمی شود. همچنین، بلوک‌های نهایی بلوک‌هایی هستند که توسط 2/3 BP در Hyperledger، Tendermint و سایر اجماع‌های مبتنی بر pBFT امضا شده‌اند. همچنین، منطقی است که پروتکلی برای اطمینان از نهایی بودن به عنوان یک افزودنی برای اجماع ایجاد کنیم، زیرا می تواند به صورت ناهمزمان با تولید و انتشار بلوک ها کار کند. اینجا یکی خوبه مقاله در مورد نهایی بودن در اتریوم

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

بنابراین، بهترین گزینه این است که PVRB و نهایی را در یک پروتکل ترکیب کنیم - سپس بلوک نهایی = تصادفی نهایی، و این دقیقاً همان چیزی است که ما نیاز داشتیم به دست آوریم. حالا بازیکنان یک تصادفی تضمین شده در N ثانیه دریافت می‌کنند و می‌توانند مطمئن باشند که بازگشت آن یا پخش مجدد آن غیرممکن است.

گزینه ادغام شده با اجماع خوب است:

• امکان اجرای ناهمزمان در رابطه با تولید بلوک ها - بلوک ها به طور معمول تولید می شوند، اما به موازات این، پروتکل PVRB می تواند کار کند که برای هر بلوک تصادفی ایجاد نمی کند.
• توانایی اجرای رمزنگاری حتی سنگین، بدون محدودیت های اعمال شده در قراردادهای هوشمند
• توانایی سازمان‌دهی تبادل پیام‌ها سریع‌تر از تراکنش‌های موجود در بلاک چین، به عنوان مثال، بخشی از پروتکل می‌تواند بین گره‌ها بدون توزیع پیام‌ها در شبکه کار کند.

معایبی هم دارد:

• مشکلات در تست و توسعه - شما باید خطاهای شبکه، گره های از دست رفته، هارد فورک های شبکه را شبیه سازی کنید.
• خطاهای پیاده سازی به هاردفورک شبکه نیاز دارند

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

بلاک چین که یک کانال پیام رسانی پروتکل شفاف و قابل اعتماد ارائه می دهد، این کار را به صورت رایگان انجام نمی دهد. هر پروتکل غیرمتمرکز باید احتمال حمله Sybil را در نظر بگیرد؛ هر اقدامی را می توان توسط نیروهای هماهنگ چندین حساب انجام داد، بنابراین، هنگام طراحی، لازم است توانایی مهاجمان برای ایجاد تعداد دلخواه پروتکل در نظر گرفته شود. شرکت کنندگانی که به صورت تبانی عمل می کنند.

PVRB و متغیرهای بلوک.

زمانی که گفتم هیچکس هنوز یک PVRB خوب را که توسط بسیاری از برنامه‌های قمار آزمایش شده است، در بلاک چین پیاده‌سازی نکرده است، دروغ نگفتم. پس این همه برنامه قمار در اتریوم و EOS از کجا می آید؟ این من را به همان اندازه که شما را شگفت زده می کند، شگفت زده می کند، آنها از کجا این همه تصادفی "مداوم" را در یک محیط کاملاً قطعی آورده اند؟

روش مورد علاقه برای به دست آوردن تصادفی بودن در بلاک چین این است که نوعی اطلاعات "غیرقابل پیش بینی" را از بلوک گرفته و بر اساس آن تصادفی ایجاد کنید - به سادگی با هش کردن یک یا چند مقدار. مقاله خوبی در مورد مشکلات چنین طرح هایی است اینجا. می توانید هر یک از مقادیر "غیرقابل پیش بینی" را در بلوک بگیرید، به عنوان مثال، هش بلوک، تعداد تراکنش ها، پیچیدگی شبکه و سایر مقادیر ناشناخته از قبل. سپس آنها را یک یا چند هش کنید و در تئوری باید یک تصادفی واقعی بدست آورید. حتی می‌توانید به وایت پیپر اضافه کنید که طرح شما «امن پس کوانتومی» است (زیرا توابع هش ضد کوانتومی وجود دارد :)).

اما افسوس که حتی هش های ایمن پس از کوانتومی نیز کافی نیستند. راز در الزامات PVRB نهفته است، اجازه دهید آنها را از مقاله قبلی به شما یادآوری کنم:

1. نتیجه باید دارای توزیع یکنواخت قابل اثبات باشد، یعنی مبتنی بر رمزنگاری قابل اثبات قوی باشد.
2. کنترل هیچ یک از بیت های نتیجه ممکن نیست. در نتیجه، نمی توان نتیجه را از قبل پیش بینی کرد.
3. شما نمی توانید با شرکت نکردن در پروتکل یا با بارگذاری بیش از حد شبکه با پیام های حمله، پروتکل تولید را خراب کنید.
4. همه موارد فوق باید در برابر تبانی تعداد مجاز از شرکت کنندگان پروتکل غیر صادق (مثلاً 1/3 شرکت کنندگان) مقاوم باشد.

در این حالت فقط نیاز 1 برآورده می شود و نیاز 2 برآورده نمی شود. با هش کردن مقادیر غیرقابل پیش بینی از بلوک، توزیع یکنواخت و تصادفی خوبی به دست خواهیم آورد. اما BP حداقل این گزینه را دارد که "بلاک را منتشر کند یا نه". بنابراین، BP حداقل می‌تواند از بین دو گزینه تصادفی انتخاب کند: «خود» و دیگری که اگر شخص دیگری بلوک را بسازد، مشخص می‌شود. BP می‌تواند از قبل «جذبه» کند که اگر بلوکی را منتشر کند چه اتفاقی می‌افتد، و به سادگی تصمیم به انجام آن بگیرد یا نه. بنابراین، هنگام بازی، به عنوان مثال، "زوج-فرد" یا "قرمز/مشکی" در رولت، او می تواند یک بلوک را تنها در صورت مشاهده برد منتشر کند. این همچنین استراتژی استفاده از هش بلوک "از آینده" را غیرقابل اجرا می کند. در این مورد، آنها می گویند که "تصادفی استفاده می شود که از هش کردن داده های فعلی و هش یک بلوک آینده با ارتفاع مثلا N + 42 به دست می آید که N ارتفاع بلوک فعلی است. این طرح را کمی تقویت می کند، اما همچنان به BP اجازه می دهد، هرچند در آینده، انتخاب کند که آیا بلوک را نگه دارد یا منتشر کند.

نرم افزار BP در این مورد پیچیده تر می شود، اما نه چندان. به سادگی، هنگام اعتبارسنجی و گنجاندن تراکنش در یک بلوک، یک بررسی سریع برای دیدن اینکه آیا یک برد وجود دارد یا خیر، و احتمالاً انتخاب یکی از پارامترهای تراکنش برای به دست آوردن احتمال بالای برنده شدن وجود دارد. در عین حال، گرفتن یک BP هوشمند برای چنین دستکاری هایی تقریبا غیرممکن است؛ هر بار می توانید از آدرس های جدید استفاده کنید و کم کم بدون ایجاد شک برنده شوید.

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

PVRB و commit-revel.

بسیار خوب، به لطف هش کردن و حداقل غیرقابل پیش بینی بودن نسبی هش بلوک و سایر متغیرها. اگر مشکل ماینرهای پیشرو را حل کنید، باید چیز مناسب تری دریافت کنید. بیایید کاربران را به این طرح اضافه کنیم - اجازه دهید آنها نیز بر تصادفی بودن تأثیر بگذارند: هر کارمند پشتیبانی فنی به شما می گوید که تصادفی ترین چیز در سیستم های IT اقدامات کاربران است :)

یک طرح ساده لوحانه، زمانی که کاربران به سادگی اعداد تصادفی را ارسال می کنند و نتیجه به عنوان مثال، هش از مجموع آنها محاسبه می شود، مناسب نیست. در این صورت، آخرین بازیکن می تواند با انتخاب تصادفی خود، کنترل کند که نتیجه چه خواهد بود. به همین دلیل است که از الگوی commit-reveal بسیار مورد استفاده استفاده می شود. شرکت‌کنندگان ابتدا هش‌های تصادفی (تعهد) خود را ارسال می‌کنند و سپس خود تصادفی‌ها را باز می‌کنند (آشکار می‌کند). مرحله «افشای» تنها پس از جمع‌آوری تعهدات لازم آغاز می‌شود، بنابراین شرکت‌کنندگان می‌توانند دقیقاً هش تصادفی را که قبلاً از آن ارسال کرده‌اند ارسال کنند. حالا بیایید همه اینها را با پارامترهای یک بلوک کنار هم بگذاریم، و بهتر از یکی که از آینده گرفته شده است (تصادفی بودن را فقط در یکی از بلوک های آینده می توان یافت) و voila - تصادفی بودن آماده است! اکنون هر بازیکنی بر تصادفی بودن نتیجه تأثیر می گذارد و می تواند BP مخرب را با نادیده گرفتن تصادفی خود که از قبل ناشناخته است، "شکست" دهد... همچنین می توانید با باز نکردن پروتکل در مرحله آشکارسازی، محافظت در برابر خرابکاری را اضافه کنید - به سادگی. با الزام مقدار معینی برای پیوست به تراکنش در هنگام انجام - یک سپرده تضمینی، که فقط در طی مراحل آشکارسازی بازگردانده می شود. در این صورت ارتکاب و عدم افشای آن زیان آور خواهد بود.

این تلاش خوبی بود و چنین طرح هایی در DApp های بازی نیز وجود دارد، اما افسوس که این دوباره کافی نیست. اکنون نه تنها ماینر، بلکه هر شرکت کننده در پروتکل نیز می تواند بر نتیجه تأثیر بگذارد. هنوز هم می توان خود مقدار را با تنوع کمتر و با هزینه کنترل کرد، اما، مانند مورد ماینر، اگر نتایج ترسیم ارزش بیشتری نسبت به هزینه مشارکت در پروتکل PVRB داشته باشد، تصادفی است. -تولید کننده (RP) می تواند تصمیم بگیرد که آیا فاش شود و همچنان می تواند حداقل از بین دو گزینه تصادفی انتخاب کند.
اما مجازات کسانی که مرتکب می شوند و افشا نمی شوند ممکن شد و این طرح به کار خواهد آمد. سادگی آن یک مزیت جدی است - پروتکل های جدی تر به محاسبات بسیار قدرتمندتری نیاز دارند.

PVRB و امضاهای قطعی.

راه دیگری برای وادار کردن RP برای ارائه یک عدد شبه تصادفی وجود دارد که در صورت ارائه یک "پیش تصویر" نمی تواند روی آن تأثیر بگذارد - این یک امضای قطعی است. چنین امضایی برای مثال RSA است و ECS نیست. اگر RP یک جفت کلید داشته باشد: RSA و ECC، و مقدار مشخصی را با کلید خصوصی خود امضا کند، در مورد RSA یک و تنها یک امضا دریافت می‌کند، و در مورد ECS می‌تواند هر تعداد را ایجاد کند. امضاهای معتبر مختلف زیرا هنگام ایجاد یک امضای ECS، از یک عدد تصادفی که توسط امضاکننده انتخاب می‌شود، استفاده می‌شود و می‌توان آن را به هر نحوی انتخاب کرد و به امضاکننده این فرصت را می‌دهد که یکی از چندین امضا را انتخاب کند. در مورد RSA: "یک مقدار ورودی" + "یک جفت کلید" = "یک امضا". پیش‌بینی اینکه RP دیگری چه امضایی خواهد داشت غیرممکن است، بنابراین یک PVRB با امضاهای قطعی می‌تواند با ترکیب امضاهای RSA چند شرکت‌کننده که مقدار یکسانی را امضا کرده‌اند، سازماندهی شود. به عنوان مثال، تصادفی قبلی. این طرح باعث صرفه جویی در منابع زیادی می شود، زیرا امضاها هم تاییدی بر رفتار صحیح طبق پروتکل و هم منبع تصادفی هستند.

با این حال، حتی با امضاهای قطعی، این طرح همچنان در برابر مشکل "آخرین بازیگر" آسیب پذیر است. آخرین شرکت‌کننده همچنان می‌تواند تصمیم بگیرد که آیا امضا را منتشر کند یا نه، در نتیجه نتیجه را کنترل می‌کند. شما می توانید طرح را اصلاح کنید، هش های بلوک را به آن اضافه کنید، دور بزنید تا نتوان نتیجه را از قبل پیش بینی کرد، اما همه این تکنیک ها، حتی با در نظر گرفتن بسیاری از تغییرات، هنوز مشکل نفوذ یک شرکت کننده بر جمع را حل نشده باقی می گذارد. منجر به یک محیط غیر قابل اعتماد می شود و تنها می تواند تحت محدودیت های اقتصادی و زمانی کار کند. علاوه بر این، اندازه کلیدهای RSA (1024 و 2048 بیت) بسیار بزرگ است و اندازه تراکنش‌های بلاک چین یک پارامتر بسیار مهم است. ظاهرا هیچ راه ساده ای برای حل مشکل وجود ندارد، بیایید ادامه دهیم.

PVRB و طرح های به اشتراک گذاری مخفی

در رمزنگاری، طرح‌هایی وجود دارند که می‌توانند به شبکه اجازه دهند تا بر روی یک و تنها یک مقدار PVRB توافق کند، در حالی که چنین طرح‌هایی در برابر هرگونه اقدام مخرب برخی از شرکت‌کنندگان مقاوم هستند. یکی از پروتکل های مفیدی که ارزش آشنایی با آن را دارد، طرح به اشتراک گذاری مخفی Shamir است. این برای تقسیم یک راز (به عنوان مثال، یک کلید مخفی) به چند قسمت، و توزیع این قسمت ها به N شرکت کننده عمل می کند. راز به گونه ای توزیع می شود که M قسمت از N برای بازیابی آن کافی است و این ها می توانند هر M قسمت باشند. اگر با انگشتان دست، پس از داشتن نموداری از یک تابع ناشناخته، شرکت‌کنندگان امتیاز را روی نمودار رد و بدل می‌کنند و پس از دریافت امتیاز M، کل عملکرد می‌تواند بازیابی شود.
توضیح خوبی در ارائه شده است ویکی اما بازی با آن عملا به منظور پخش پروتکل در ذهن شما مفید است نسخه ی نمایشی صفحه

اگر طرح FSSS (به اشتراک گذاری مخفی فیات-شمیر) به شکل خالص خود قابل اجرا بود، یک PVRB غیرقابل تخریب خواهد بود. در ساده ترین شکل، پروتکل ممکن است به شکل زیر باشد:

• هر شرکت کننده تصادفی خود را تولید می کند و سهام آن را بین سایر شرکت کنندگان توزیع می کند
• هر شرکت کننده بخشی از اسرار سایر شرکت کنندگان را فاش می کند
• اگر یک شرکت‌کننده بیش از M سهام داشته باشد، می‌توان تعداد این شرکت‌کننده را محاسبه کرد و بدون در نظر گرفتن مجموعه شرکت‌کنندگان آشکار شده، منحصربه‌فرد خواهد بود.
• ترکیبی از تصادفات آشکار شده PVRB مورد نظر است

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

این می تواند یک گزینه ایده آل باشد، این طرح PVRB مبتنی بر اشتراک مخفی فیات-شمیر به عنوان مثال در این مقاله. اما، همانطور که در بالا ذکر شد، اگر بخواهید آن را به طور مستقیم در بلاک چین اعمال کنید، محدودیت های فنی ظاهر می شود. در اینجا نمونه ای از اجرای آزمایشی پروتکل در قرارداد هوشمند EOS و مهمترین بخش آن - بررسی مشارکت کننده منتشر شده است: رمز. از روی کد می توانید ببینید که اعتبار سنجی اثبات به چندین ضرب اسکالر نیاز دارد و اعداد استفاده شده بسیار بزرگ هستند. باید درک کرد که در زنجیره‌های بلوکی، تأیید در لحظه‌ای اتفاق می‌افتد که تولیدکننده بلاک، تراکنش را پردازش می‌کند و به طور کلی، هر شرکت‌کننده باید به راحتی صحت پروتکل را تأیید کند، بنابراین الزامات سرعت عملکرد تأیید بسیار جدی است. . در این گزینه، گزینه بی اثر بود، زیرا تأیید در محدوده تراکنش (0.5 ثانیه) قرار نداشت.

کارآیی تأیید یکی از مهمترین الزامات برای استفاده از، به طور کلی، هر طرح رمزنگاری پیشرفته در بلاک چین است. ایجاد شواهد، آماده سازی پیام ها - این رویه ها را می توان خارج از زنجیره برداشت و روی رایانه های با کارایی بالا انجام داد، اما تأیید را نمی توان دور زد - این یکی دیگر از نیازهای مهم PVRB است.

PVRB و امضاهای آستانه

پس از آشنایی با طرح به اشتراک گذاری مخفی، یک کلاس کامل از پروتکل ها را کشف کردیم که با کلمه کلیدی "آستانه" متحد شده بودند. هنگامی که افشای برخی اطلاعات مستلزم مشارکت M شرکت‌کنندگان صادق از N است، و مجموعه شرکت‌کنندگان صادق می‌تواند زیرمجموعه دلخواه N باشد، ما از طرح‌های "آستانه" صحبت می‌کنیم. این آنها هستند که به ما اجازه می دهند با مشکل "آخرین بازیگر" مقابله کنیم، اکنون اگر مهاجم قسمت خود را از راز فاش نکند، شرکت کننده صادق دیگری این کار را برای او انجام می دهد. این طرح‌ها توافق بر یک معنا را امکان‌پذیر می‌کنند، حتی اگر پروتکل توسط برخی از شرکت‌کنندگان خراب شود.

ترکیبی از امضاهای قطعی و طرح های آستانه امکان ایجاد یک طرح بسیار راحت و امیدوارکننده برای اجرای PVRB را فراهم می کند - اینها امضاهای آستانه قطعی هستند. اینجا مقاله در مورد کاربردهای مختلف امضاهای آستانه، و در اینجا یکی دیگر از موارد خوب است طولانی مدت از داش.

آخرین مقاله امضاهای BLS را توصیف می کند (BLS مخفف Boneh-Lynn-Sacham است، اینجا مقاله)، که دارای کیفیت بسیار مهم و بسیار راحت برای برنامه نویسان هستند - کلیدهای عمومی، مخفی، عمومی و امضاهای BLS را می توان با استفاده از عملیات ساده ریاضی با یکدیگر ترکیب کرد، در حالی که ترکیب آنها کلیدها و امضاهای معتبر باقی می ماند و به شما امکان می دهد به راحتی بسیاری از آنها را جمع آوری کنید. امضا در یک و بسیاری از کلیدهای عمومی در یک. آنها همچنین قطعی هستند و نتایج یکسانی را برای داده های ورودی یکسان ایجاد می کنند. با توجه به این کیفیت، ترکیبی از امضاهای BLS خود کلیدهای معتبری هستند، که امکان اجرای گزینه ای را فراهم می کند که در آن M از N شرکت کننده، یک و تنها یک امضا تولید می کنند که قطعی، قابل تأیید عمومی و غیرقابل پیش بینی است تا زمانی که توسط Mth باز شود. شرکت کننده .

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

بنابراین، اگر شما در حال ساخت PVRB بر روی بلاک چین خود هستید، به احتمال زیاد با طرح امضای آستانه BLS مواجه خواهید شد، چندین پروژه در حال حاضر از آن استفاده می کنند. به عنوان مثال، DFinity (اینجا معیاری که مدار را پیاده سازی می کند و اینجا به عنوان مثال اجرای اشتراک‌گذاری محرمانه قابل تأیید)، یا Keep.network (در اینجا نشانگر تصادفی آنها است کاغذ زرد، اما مثال قرارداد هوشمند در خدمت پروتکل).

پیاده سازی PVRB

متأسفانه هنوز شاهد اجرای پروتکل آماده ای در بلاک چین های PVRB نیستیم که امنیت و پایداری خود را ثابت کرده باشد. اگرچه خود پروتکل ها آماده هستند، از نظر فنی به کار بردن آنها در راه حل های موجود آسان نیست. برای سیستم های متمرکز، PVRB معنی ندارد و غیرمتمرکزها در تمام منابع محاسباتی محدود هستند: CPU، حافظه، ذخیره سازی، I/O. طراحی PVRB ترکیبی از پروتکل های مختلف به منظور ایجاد چیزی است که تمام الزامات حداقل برخی از بلاک چین های قابل دوام را برآورده می کند. یک پروتکل کارآمدتر محاسبه می کند، اما به پیام های بیشتری بین RP ها نیاز دارد، در حالی که پروتکل دیگر به پیام های بسیار کمی نیاز دارد، اما ایجاد یک اثبات می تواند کاری باشد که ده ها دقیقه یا حتی ساعت ها طول می کشد.

من عواملی را که باید هنگام انتخاب یک PVRB با کیفیت در نظر بگیرید را فهرست می کنم:

• قدرت رمزنگاری. PVRB شما باید کاملاً غیرقابل تعصب باشد و توانایی کنترل یک بیت را نداشته باشد. در برخی از طرح ها اینطور نیست، بنابراین با یک رمزنگار تماس بگیرید
• مشکل "آخرین بازیگر".. PVRB شما باید در برابر حملاتی که مهاجمی که یک یا چند RP را کنترل می کند می تواند یکی از دو نتیجه را انتخاب کند، مقاوم باشد.
• مشکل خرابکاری پروتکل. PVRB شما باید در برابر حملاتی مقاوم باشد که در آن مهاجمی که یک یا چند RP را کنترل می‌کند تصمیم می‌گیرد تصادفی باشد یا خیر و می‌تواند تضمین شود یا با احتمال معینی بر آن تأثیر بگذارد.
• مشکل تعداد پیام ها. RP های شما باید حداقل پیام ها را به بلاک چین ارسال کنند و تا حد امکان از اقدامات همزمان خودداری کنند، مانند موقعیت هایی مانند "من برخی اطلاعات را ارسال کردم، منتظر پاسخ از یک شرکت کننده خاص هستم." در شبکه های p2p، به خصوص شبکه های پراکنده جغرافیایی، نباید روی پاسخگویی سریع حساب کنید
• مشکل پیچیدگی محاسباتی. تأیید هر مرحله از زنجیره PVRB باید بسیار آسان باشد، زیرا توسط تمام مشتریان کامل شبکه انجام می شود. اگر پیاده سازی با استفاده از قرارداد هوشمند انجام شود، الزامات سرعت بسیار سختگیرانه است
• مشکل دسترسی و زندگی. PVRB شما باید در شرایطی که بخشی از شبکه برای مدتی در دسترس نیست و بخشی از RP به سادگی از کار می‌افتد، انعطاف‌پذیر باشد.
• مشکل راه اندازی مطمئن و توزیع کلید اولیه. اگر PVRB شما از تنظیمات اولیه پروتکل استفاده می کند، پس این یک داستان بزرگ و جدی جداگانه است. اینجا مثال. اگر شرکت‌کنندگان باید کلیدهای خود را قبل از شروع پروتکل به یکدیگر بگویند، در صورت تغییر ترکیب شرکت‌کنندگان نیز این مشکل ایجاد می‌شود
• مسائل توسعه. در دسترس بودن کتابخانه ها به زبان های مورد نیاز، امنیت و عملکرد آنها، تبلیغات، تست های پیچیده و غیره.

به عنوان مثال، امضاهای آستانه BLS یک مشکل مهم دارند - قبل از شروع به کار، شرکت کنندگان باید کلیدها را بین یکدیگر توزیع کنند و گروهی را سازماندهی کنند که آستانه در آن کار خواهد کرد. این بدان معنی است که حداقل یک دور مبادله در یک شبکه غیرمتمرکز باید منتظر بماند و با توجه به اینکه راند تولید شده، برای مثال، در بازی ها، تقریباً در زمان واقعی ضروری است، به این معنی است که خرابکاری پروتکل در این مرحله امکان پذیر است. ، و مزایای طرح آستانه از بین می رود. این مشکل در حال حاضر ساده تر از موارد قبلی است، اما همچنان نیازمند ایجاد یک رویه جداگانه برای تشکیل گروه های آستانه است که باید از نظر اقتصادی محافظت شود، از طریق سپرده گذاری و برداشت وجوه (کاهش) از شرکت کنندگانی که از قوانین پیروی نمی کنند. پروتکل همچنین، تأیید BLS با سطح قابل قبولی از امنیت به سادگی، به عنوان مثال، در یک تراکنش استاندارد EOS یا Ethereum قرار نمی گیرد - زمان کافی برای تأیید وجود ندارد. کد قرارداد WebAssembly یا EVM است که توسط یک ماشین مجازی اجرا می شود. توابع رمزنگاری به صورت بومی (هنوز) پیاده سازی نشده اند و ده ها برابر کندتر از کتابخانه های رمزنگاری معمولی کار می کنند. بسیاری از پروتکل ها الزامات را به سادگی بر اساس حجم کلید برآورده نمی کنند، به عنوان مثال 1024 و 2048 بیت برای RSA، 4-8 برابر بزرگتر از امضای تراکنش استاندارد در بیت کوین و اتریوم.

وجود پیاده سازی ها در زبان های برنامه نویسی مختلف نیز نقش دارد - که تعداد کمی از آنها وجود دارد، به خصوص برای پروتکل های جدید. گزینه ادغام در اجماع نیاز به نوشتن یک پروتکل در زبان پلتفرم دارد، بنابراین باید در Go برای geth، در Rust برای Parity، در C++ برای EOS به دنبال کد بگردید. همه باید به دنبال کد جاوا اسکریپت بگردند و از آنجایی که جاوا اسکریپت و رمزنگاری دوستان صمیمی نیستند، WebAssembly کمک خواهد کرد، که اکنون قطعاً ادعا می کند که استاندارد مهم بعدی اینترنت است.

نتیجه

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

خداحافظ، برای PVRB ما در بلاک چین در حال توسعه هیا، ما با استفاده از امضاهای آستانه BLS تصمیم گرفتیم، PVRB را در سطح اجماع پیاده سازی کنیم، زیرا تأیید در قراردادهای هوشمند با سطح قابل قبولی از امنیت هنوز امکان پذیر نیست. این امکان وجود دارد که ما از دو طرح به طور همزمان استفاده کنیم: اول، اشتراک گذاری مخفی گران قیمت برای ایجاد random_seed درازمدت، و سپس از آن به عنوان پایه ای برای تولید تصادفی با فرکانس بالا با استفاده از امضاهای آستانه قطعی BLS استفاده می کنیم، شاید خودمان را فقط به آن محدود کنیم. یکی از طرح ها متأسفانه نمی توان از قبل گفت که پروتکل چیست؛ تنها خوبی این است که مانند علم، در مسائل مهندسی نیز نتیجه منفی است و هر تلاش جدیدی برای حل مشکل گام دیگری است برای تحقیق همه افراد درگیر در این مشکل برای برآوردن نیازهای تجاری، ما یک مشکل عملی خاص را حل می کنیم - ارائه برنامه های بازی با منبع قابل اعتماد آنتروپی، بنابراین باید به خود زنجیره بلوکی، به ویژه مسائل نهایی زنجیره و حاکمیت شبکه نیز توجه کنیم.

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

بنابراین، هنگامی که با برنامه نویسی روبرو می شوید که به صورت تصادفی غیرمتمرکز طراحی می کند، مراقب و دلسوز باشید و در صورت لزوم کمک روانی ارائه دهید :)

منبع: www.habr.com