پیشرفته مقالات

کریپتو با ویتالیک؛ مثلث آسیب

در سری «کریپتو با ویتالیک» هر بار با ترجمه یکی از نوشته‌های ویتالیک بوترین – خالق شبکه اتریوم – همراه شما هستیم. در مقاله‌ای که در ادامه خواهید خواند، بوترین در جریان طراحی مکانیزمی برای محدود کردن مشکلات گواه اثبات سهام اتریوم (در آن زمان موسوم به Casper)، توضیحی در خصوص انواع حملات داخلی گروه‌های فعال به پروتکل ارائه می‌دهد. او چند راه‌حل احتمالی برای حل این حملات پیشنهاد می‌دهد. مقاله‌ای که خواهید خواند در تاریخ ۱۶ جولای سال ۲۰۱۷ منتشر شده است.

حملات ممکن داخلی در بلاکچین‌ها و پاسخ کسپر

دیاگرام زیر بخشی از اسلایدی است که برای ارائه‌ام در دانشگاه کورنل (Cornell) آماده کردم:

مثلث آسیب

اگر شکلی بتواند فلسفه مشوق‌های گنجانده شده در کسپر (Casper – طرح ابتدایی اتریوم برای حرکت به سوی گواه اثبات سهام که در نهایت تغییرات فراوان داشت و حتی در آخر طرح دیگری جایگزین آن شد) را تا حد خوبی نشان دهد، این شکل خواهد بود. بنابراین توضیح بیشتری می‌طلبد.

نمودار سه گروه – اقلیت، اکثریت و پروتکل (کاربران) – و چهار فلش که نشان‌دهنده اقدام خصمانه احتمالی است را نمایش می‌دهد: اقلیت به پروتکل حمله کند، اقلیت به اکثریت حمله کند، اکثریت به پروتکل حمله کند و اکثریت به گروه اقلیت حمله کند. نمونه‌هایی از هر یک به شرح زیر است:

  • اقلیت به پروتکل حمله کند: حمله فینی (Finney Attack) – این حمله نوعی از حمله خرج مجدد (Double Spend) است. در این حمله ماینر تراکنشی برای پرداخت هزینه کالا یا خدمتی آماده می‌‌کند سپس سعی می‌کند با پیدا کردن بلاک بعدی که حاوی فرستادن آن مبلغ به خود است (لغو تراکنش پیشین)، بدون آن که هزینه را پرداخت کند، از آن حدمت یا محصول بهره‌مند شود. این حمله تنها در صورتی کارساز می‌شود که طرف دوم معامله بدون صبر برای تایید بیشتر تراکنش، خدمت یا کالا را به شکل بی‌بازگشت ارسال کند.
  • اقلیت به اکثریت حمله کند: Feather Forking – در این نمونه از شبه فورک یا فورک خفیف، گروهی از ماینرها که حداکثر توان هش شبکه را در اختیار ندارند سعی می‌کنند تا هر بلوکی که حاوی تراکنشی از آدرس بلک لیست شده (سانسور شده) توسط آن‌هاست را بازگردانند (با ساخت بلاکی بدون آن تراکنش و ساخت بلاک صحیح بعدی بر روی آن تا تشکیل بزرگترین زنجیره را دهند) اما اگر بلاک نامطلوب دو تایید گرفت، از تلاش دست برمی‌دارند.
  • اکثریت به پروتکل حمله کند: حمله ۵۱ درصد.
  • اکثریت به اقلیت حمله کند: حمله سانسور ۵۱ درصدی؛ در این حمله کارتل خلافکار هیچ بلاکی که متعلق به عضوی از کارتل نباشد را نمی‌پذیرد.

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

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

این ویژگی گواه اثبات کار از این نشات می‌گیرد که گواه اثبات کار سنتی ناکاموتو به شکل بنیادی به تنبیه هر گونه سرپیچی و همرنگ نشدن با جماعت می‌پردازد.به عنوان یک ماینر اگر بلوکی تولید کنید که مورد اجماع قرار گیرد، پاداش دریافت می‌کنید و اگر بلوکی بسازید که با اجماع همسو نباشد مجازات می‌شوید (مجازات به شکل مشخص در پروتکل مشخص نشده است؛ بلکه هزینه الکتریسیته و سرمایه‌ای است که توسط ماینر برای تولید بلوک صرف شده و بی‌پاداش مانده است).

کسپر اما طوری طراحی شده است که دوگانگی و ایهام را مجازات کند – اگر دو پیام بفرستید که با یکدیگر تناقض داشته باشند، حتی اگر یکی از آن‌ها مطابق اجماع باشد، به سختی مجازات خواهید شد. بنابراین در صورتی که حمله بازگردانی قطعیت (Finality Reversion Attack) رخ دهد، تمامی کسانی که مسبب آن بودند جریمه خواهند شد و بقیه در امان خواهند بود. اکثریت تنها با متحمل شدن هزینه زیاد قادر به حمله به پروتکل خواهد بود و نمی‌تواند سبب شود که اقلیت پول از دست دهند.


دو ضلع دیگر مثلث آسیب

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

این قضیه پای تضاد بنیادین‌تری را به میان می‌کشد: معادل‌سازی خطای گوینده/شنونده (Speaker/Listener Fault Equivalence).

 معادل‌سازی خطای گوینده/شنونده (Speaker/Listener Fault Equivalence).
liveness fault

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

جریمه کردن هر دو گروه، به هر دو طرف اجازه می‌دهد که دیگری را به زحمت بیاندازد: اگر اقلیت باشد، با آفلاین شدن و اگر اکثریت باشد با سانسور. اما می‌توانیم با استفاده از تحلیل ضریب آسیب (Griefing Factor Analysis) – ضریب آسیب معیاری برای سنجش میزان آسیبی است که شرکت‌کنندگان در یک فرایند می‌توانند با سو استفاده از آن، به دیگران آسیب بزنند، حتی با وجود متحمل شدن هزینه و آسیب به خود – محدوده‌ای برای میزان سختی این کار مشخص نماییم. ضریب آسیب یک استراتژی در واقع مجموع پول از دست رفته قربانیان تقسیم بر میزان پول از دست رفته مهاجمان است. ضریب آسیب یک پروتکل بیشترین ضریب آسیبی است که ساختار یک پروتکل به مهاجمان اجازه می‌دهد. برای مثال اگر یک پروتکل به من اجازه دهد که با صرف یک دلار، به شما آسیبی ۳ دلاری بزنم، ضریب آسیب ۳ خواهد بود. اگر هیچ راهی برای آسیب زدن به بقیه وجود نداشته باشد، ضریب آسیب صفر خواهد بود و اگر بتوانید بدون متحمل شدن هیچ هزینه‌ای (و یا حتی با به دست آوردن منفعت طی آن) به دیگران آسیب زنید، ضریب آسیب بی‌نهایت خواهد بود.

به شکل کلی، هرگاه دوگانگی گوینده/شنونده وجود داشته باشد،‌ ضریب آسیب را نمی‌توان به زیر ۱ محدود کرد. دلیل این امر ساده است: از آن جا که هر دو گروه می‌توانند به یکدیگر آسیب رسانند، اگر گروه الف بتواند به گروه ب با ضریب x آسیب رساند، آن گاه طرف ب می‌تواند با ضریب یک تقسیم بر x این کار را انجام دهد و این دو ضریب نمی‌توانند به شکلی همزمان هر دو کمتر از یک باشند. می‌توانیم از این ضریب به سود خود بهره بریم: برای مثال، فرض کنید که تعیین ضریب ۲ برای حملات اکثریت قابل قبول باشد چرا که در آن صورت ضریب آسیب اقلیت ۰.۵ خواهد بود و بنا بر تشخیص ما، احتمال وقوع حمله از جانب اقلیت بیشتر است. می‌توانیم ضریب آسیب یک را برای حملات محدود بپذیریم اما برای حملات گسترده که منجر به گسست شبکه می‌شود این سبب می‌شود که در یک زنجیره گروهی تنبیه شوند و در زنجیره دوم، گروه دیگر. این گونه می‌توان به بازار (و توان پردازشی) اجازه داد که زنجیره تحت حمایت خود را انتخاب کنند. بنابراین در این ساختار، فضای زیادی برای مصالحه و انتخاب گزینه مناسب بنا بر شرایط پیش رو وجود دارد.

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

با این مقدمه می‌توان مفهوم تابع مطلوبیت پروتکل (Protocol Utility Function) را معرفی کرد؛ فرمولی که بیان می‌دارد که اوضاع پروتکل چقدر خوب است. به شکل ایده‌آل باید بتوان این فرمول را از درون بلاکچین محاسبه کرد. در مورد شبکه‌‌های مبتنی برگواه اثبات کار، این می‌تواند درصد بلوک‌های ایجاد شده که سر از زنجیره اصلی درمی‌آوردند، باشد. در کسپر، مطلوبیت پروتکل در حالت اجرای بی‌نقص که تمامی epochها به قطعیت می‌رسند و هیچ مشکل امنیتی پیش نمی‌آید صفر خواهد بود. مجازات متناسبی برای هر epoch که قطعی نشود در نظر گرفته خواهد شد و مجازات سنگینی در ازای هر قصور امنیتی در پی خواهد بود. اگر بتوان به نحوی تابع مطلوبیت پروتکل را تعریف کرد، آن گاه می‌توان مجازات‌ کوتاهی‌ها را تا جای امکان، هم‌اندازه با زیان تحمیلی به پروتکل تعیین کرد.

منبع
ٰVitalik

نوشته های مشابه

0 دیدگاه
Inline Feedbacks
View all comments
دکمه بازگشت به بالا