آنچه درباره Proposer Boost باید بدانید

مقاله رو با شرح یک واقعه شروع میکنیم.در تاریخ ۲۵ ماه می ۲۰۲۲ (۴ خرداد ۱۴۰۱)، بیکن چین متحمل بازآرایی (reorg) به طول ۷ بلوک شد. دلیل اصلی این اتفاق، عدم بروزرسانی به موقع و همزمان کلاینت‌های مختلف شبکه، به آپگرید اعمال پروپوزر بوست بود. این اتفاق بهانه‌ای شد تا به تشریح مفهوم Proposer Boost و دلایل تعریف آن بپردازیم. در ادامه این مطلب در خصوص فرایند اجماع اتریوم توضیحی کوتاه خواهیم داد و سپس حملات مرتبط و راهکار جلوگیری از آن را شرح خواهیم داد.

توضیحی کوتاه بر فرایند اجماع اتریوم

فرایند اجماع شبکه اتریوم در بیکن چین Gasper نامیده می‌شود که خود از دو جز LMD GHOST (برای انتخاب سر شاخه) و Casper FFG (برای قطعیت بخشیدن) تشکیل شده است؛ LMD GHOST یا Latest Message Driven Greediest Heaviest Observed SubTree rule – اگر فکر کردید که ترجمه‌ای از این عبارت ارائه می‌دهم، کور خوانده‌اید – مجموعه قوانینی برای انتخاب سرشاخه اصلی بلوک‌هاست. این قانون بر حسب میزان وزن رای‌ها (شهادت – attestation) اعتبارسنج‌ها، سرشاخه اصلی را معین می‌کند. در هر ارتفاع بلوک معین، فورکی که بیشترین میزان تصدیق رای را در حمایت از خود داشته باشد، انتخاب می‌شود. برای مثال به شکل زیر دقت کنید:

در شکل بالا، مستطیل‌ها نشان‌گر بلوک‌ها و دوایر نشان‌دهنده تعداد رای‌های هستند. مسیر مشخص شده با رنگ آبی، سرشاخه canonical بلاک چین است.

در سمت دیگر، کاسپر به بحث قطعیت می‌پردازد؛ اجماع BFT ذاتا ناهمزمان است یعنی نیازی نیست که پیام‌ها به شکل همزمان رد و بدل شود و این اجماع می‌تواند همچنان جواب دهد. از سوی دیگر نظریه CAP در علوم کامپیوتر بیان می‌کند که برای حفظ Finality و Liveness به شکل توامان، نیاز به تعریف حد بالایی برای زمان پیام‌های ارسالی خواهیم داشت. کاسپر با تقسیم‌بندی‌ بلوک‌ها، به تناوب‌های مشخص، سعی می‌کند که پس از سپری شدن مدتی مشخص، وضعیت شبکه را قطعی نماید. در این تقسیم‌بندی، هر ۱۲ ثانیه (معادل با زمان تقریبی یک بلوک) یک اسلات (Slot) و هر ۶۴ اسلات، یک ایپاک (epoch) نامیده می‌شود. پس از هر epoch، وضعیت بلوک‌ها قطعی می‌شود و برای تغییر آن، احتیاج به شرایط بسیار خاصی است. در هر اسلات، یک کمیته (که زیرمجموعه‌ای از کل اعتبارسنج‌هاست) انتخاب می‌شود. در هر کمیته دو نقش وجود دارد؛ یک اعتبارسنج وظیفه پیشنهاد بلوک (‌Block Proposer) دارد و بقیه وظیفه تعیین سرشاخه اصلی (Attestation) را دارند.

با توجه به وضعیت اجماع شبکه اتریوم، امکان چند حمله احتمالی به شبکه وجود دارد: حملات بازآرایی (reorg) ex post و ex ante.

حمله ex post چیزی است که مخاطب با آن آشنایی دارد و به عنوان حمله reorg می‌شناسد؛ این حمله در اجماع PoS شانس کمی برای اجرا دارد. حتی اگر عامل متخاصم ۶۵ درصد از کل مقدار استیک شده را در اختیار داشته باشد، شانس او برای اجرای reorg یک بلوکه (در هر زمان دلخواه) با توجه به پارامترهای فعلی تنها در حدود ۰.۰۵ درصد است.

اما حمله بازآرایی ex ante داستان متفاوتی است:

حمله بازآرایی ex ante

در این حمله، عامل متخاصم بلوک n+1 را تشکیل می‌دهد اما به شبکه ارائه نمی‌دهد (و به صحت آن شهادت می‌دهد)، سپس با توجه به موقعیت جغرافیایی نودهای خود در لایه p2p، به محض اطلاع از انتشار بلوک n+2، بلوک خود را منتشر می‌کند. با توجه به توزیع گسترده نودهای عامل متخاصم در سطح لایه شبکه، اکثر نودها بلوک n+1 را زودتر از بلوک n+2 مشاهده می‌کنند و با توجه به وزن رای‌های پشت آن، طبق فرایند LMD GHOST واجد شرایط سرشاخه شدن می‌شود. نوع پیشرفته‌تری از این حمله وجود دارد که به حمله balancing معروف است. در این نوع از حمله، عامل متخاصم به شکلی برنامه‌ریزی می‌کند که نیمی از نودهای صادق بلوک n+1 را در ابتدا ببینند و تصدیق کنند و نیمی دیگر بلوک n+2 را. در این حالت متخاصم لازم نیست که به مقابله با نودهای صادق بپردازد و در روی کاغذ می‌تواند reorgای دو بلوکه ایجاد کند.

راهکار مقابله با این حملات؛ سازوکار Proposer Boost

حال که با این حمله آشنا شدیم، به راهکاری که برای مقابله با آن اندیشیده شده اشاره خواهیم کرد. همان‌طور که ذکر شد، اجماع PBFT ذاتا غیرهمزمان است، اما برای این که بتوانیم از چنین حملاتی جلوگیری کنیم می‌توانیم به شکلی مصنوعی، گلوگاهی زمانی ایجاد کنیم. طبق این راهکار، هر اسلات را به محدوده مشخصی تقسیم می‌کنیم و اگر بلوک موردنظر تا آن پایان آن زیرمحدوده بتواند ارائه شود و رای جمع‌آوری کند، وزن بیشتری به آن خواهیم داد. به این وزن بیشتر (که میزان این پارامتر در اختیار شبکه است و طبق آخرین تحقیقات، وزن ۴۰ تا ۴۳ درصد بیشتر، بهترین بازدارندگی را ایجاد می‌کند) Proposer Boost می گوییم.

تعیین محدوده‌ای برای ارائه بلوک در هر اسلات.

این چنین، عامل متخاصم نمی‌تواند با بازداشتن بلوک خود و ارائه آن پس از موعد مقرر، از سازوکار LMD GHOST بهره جوید و بلوک خود را به عنوان بلوک اصلی به کرسی نشاند، چرا که بلوک صحیح بعدی (در اسلات مشخص) از وزن بیشتری برخوردار خواهد بود. این چنین حملات Balancing به شدت مشکل‌تر خواهد شد.

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

 بازآرایی بیکن چین چه بود؟

حال که توضیحی در خصوص Proposer Boost ارائه کردیم، ماجرای reorg هفت بلوکه بیکن چین را بررس یکنیم؛ واقعیت این است که این ماجرا تنها به خاطر اختلاف زمانی اعمال این پارامتر جدید در کلاینت‌های مختلف رخ داد؛ زمان توزیع آخرین نسخه کلاینت‌های مشهوری که از این قابلیت پشتیبانی می‌کنند به شرح زیر بود:

بازآرایی ۷ بلوکه شبکه Beacon Chain

-لایت هاوس (Lighthouse): ۵ آپریل

-تکو (Teku): ۷ آپریل

-پریسم (Prysm): ۲۶ آپریل

-لودستار (Lodestar): ۱۱ می

-نیمباس (Nimbus): در آخرین نسخه که ۲۱ می منتشر شد به روش قبلی بازگشت

فورک رخ داده در بیکن چین

طبق بررسی های اولیه، با توجه به توزیع کلاینت‌ها و زمان آپدیت آخر، حدود ۷۵ درصد از کل نودها Proposer Boost را فعال داشتند و یک چهار باقی‌مانده آن را فعال نکرده بودند. اتفاقاتی که افتاد به شرح زیر بود:

بلوک ۷۴، حدود ۱۲ ثانیه دیرتر رسید، بلوک ۷۵ به موقع در اسلات مقرر رسید. بنابراین بوست شد و به عنوان سرشاخه شناخته شد، این اتفاق تا بلوک ۸۱ رخ داد. احتمالا سازنده بلوک ۸۲ این قابلیت را فعال نداشت، بنابراین طبق الگوی LMD، به بلوک ۷۴ وزن بیشتری داد.

طبق بررسی‌های انجام شده، شانس وقوع چنین اتفاقی (با فرض توزیع نودها به شکل گفته شده) تنها ۰.۲۵ به توان ۶ بوده است. بنابراین دلیل اصلی چنین رخدادی، تکه تکه شدن کلاینت‌ها به دو دسته بود که هر یک وزن بیشتری برای حالت خاصی قائل بودند. به نظر می‌رسد راه‌حل اصلی عدم تکرار چنین رویدادی، دسته‌بندی این بروزرسانی به موردی مشابه هاردفورک است؛ چرا که این پارامتر مشخصا می‌تواند قوانین برگزیدن سرشاخه را حت تاثیر قرار دهد. بنابراین طبیعی است که همچون یک هاردفورک طی ارتفاع بلوکی مشخص و به شکل هماهنگ، در سطح شبکه فعال شود.