Whitepaper Ripple (XRP)

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

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

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

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

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

خبر عالی! این سکه در Binance ذکر شده است و من می توانم به شما در خرید ارزان تر کمک کنم! فقط از طریق این لینک ارجاع با Binance ثبت نام کنید و برای هر خرید 10 ٪ تخفیف هزینه رایگان دریافت خواهید کرد! و اگر می خواهید طرفدار و تجارت با اهرم 2-125x بروید ، از این لینک ارجاع برای تخفیف هزینه 10 ٪ رایگان دیگر در Binance استفاده کنید. تجارت مبارک!