نحوه اجتناب از اسلشینگ (Slashing) یا جریمه کاهش سهم در اتریوم 2.0

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

اسلشینگ چیست؟

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

نکته: اسلشینگ ارتباطی با جریمه غیر فعال بودن یک ولیدیتور ندارد و آن جریمه به‌صورت دیگری بر ولیدیتور (بسته به میزان غیر فعال بودن او در شبکه و عدم انجام وظایفش) اعمال می‌شود.

هدف اسلشینگ مایوس کردن کسانی است که به دنبال صدمه زدن و خرابکاری در شبکه اتریوم 2.0 هستند و در مقابل به کسانی که در شبکه در برابر این صدمات اقدام کرده و از شبکه محافظت می‌کنند پاداش می‌دهد. به تعبیر دیگر هزینه حمله و خرابکاری در شبکه را برای خرابکاران بالا می‌برد. به عنوان مثال یکی از این خرابکاری‌ها یا حمله‌ها می‌تواند اقدام برای ایجاد انشعاب یا فورک در شبکه باشد که ولیدیتورها را به اشتباه خواهد انداخت.

اسلشینگ چگونه کار می‌کند؟

اقدام بازدارندهٔ اسلشینگ ، از بین بردن بخشی از استیک (سهم) یک ولیدیتور (مشکوک به خرابکاری) است تا از این طریق بتواند شبکه اتریوم را مجاب کند آن ولیدیتور را از شبکه بیرون بیندازد. هدف از این اقدام، مایوس‌کردن و بازداشتن افرادی است که به دنبال ضربه زدن به شبکه اتریوم 2.0 هستند و به تبع آن مکانیزم‌های امنیتی برای حفاظت از شبکه و ترغیب بازیگران خوب را افزایش دهد.

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

در شرایط زیر امکان بروز اسلشینگ وجود دارد:

1. وقتی که یک ولیدیتور دو بلاک متعارض را در اسلات یکسانی با root متفاوت پردازش کند (مخصوصا یک هش از دیتای داخلی). اگر این اقدام با مجازات همراه نباشد به ولیدیتور این امکان را خواهد داد تا بتواند فورک‌های غیر‌ضروری و هرج و مرج در شبکه ایجاد نماید. اما ارائه مجدد یک بلاک یکسان شامل این اسلشینگ نمی‌شود.
2. وقتی که یک ولیدیتور دو بلاک متعارض در یک اسلات یکسان را تصدیق می‌کند. این عمل به عنوان رای دوگانه نام برده می‌شود و این ولیدیتور به عنوان کسی که سعی در ایجاد فورک در زنجیره دارد شناسایی می‌شود. در اینجا نیز رای‌گیری مجدد برای یک بلاک یکسان شامل اسلشینگ نمی‌شود.
3. وقتی که یک ولیدیتور رای می‌دهد در برابر رأیی که احاطه شده یا درحال احاطه شدن به وسیله رای قبلی است و به معنی این است که او رایی بر علیه تاریخچه می‌دهد.

بعد از اسلشینگ چه اتفاقی می‌افتد؟

به رغم وجود مکانیزم‌های چندگانه اجتناب از اسلشینگ ، بسیار مهم است که تنها یک ولیدیتور به ازای هر موجودیت (validator key pair) استفاده شود. در ظاهر ساده به نظر می‌رسد اما وقتی که چندین ولیدیتور تنظیم شده باشند، ممکن است با یک اشتباه سهوی به سادگی یک ولیدیتور درحال‌ کار مجددا به شبکه اضافه شود (duplication). ازین‌ رو ضروری است که قبل از بازیابی یا راه‌اندازی یک ولیدیتور از همه تنظیمات اطمینان حاصل شود. در اینجا و اینجا می‌توانید منابع بیشتری در این خصوص مطالعه نمایید.

در هنگام اسلش شدن یک ولیدیتور، موارد زیر اتفاق می‌افتد:

• آن ولیدیتور می‌بایست تا حداکثر 36 روز آینده از زنجیره beacon خارج شود.
• سه نوع جریمه به آن ولیدیتور تعلق می‌گیرد:
  ۱-کمترین میزان جریمه، درج یک پیغام افشاگر در یک بلاک توسط ولیدیتور افشاگر است.
  ۲-یک جریمه در ابتدای هر سیکل epoch در شبکه (هر 6.4 دقیقه) تا زمانی که آن ولیدیتور صف خروج را ترک کند.
  ۳-یک جریمه مخصوص در مابین بازه زمانی درج پیغام افشاگرانه در یک بلاک و زمانی که آن ولیدیتور مخرب امکان برداشت خواهد داشت. این جریمه متناسب با میزان ولیدیتورهای اسلش‌شده در یک بازه زمانی تعیین می‌گردد. حداکثر مقدار می‌تواند به اندازه کل سهم (بالانس) ولیدیتور مخرب باشد.

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

در نهایت این است که ولیدیتور اسلش‌شده دیگر نمی‌تواند عضوی از مجموعه ولیدیتورها باشد و مجدد لازم است که سهم و کلیدهای جدید برای پیوستن به مجموعه ولیدیتورها ایجاد گردد. خلاصه اینکه اسلشینگ برگشت‌ناپذیر است.

در آن 36 روز اعمال جریمه، بخش اعظم سهم (اتریوم لاک شده) ولیدیتور مخرب به تدریج از بین می‌رود و بعد از 36 روز بخش خیلی کمی از آن باقی می‌ماند که می‌تواند آن را برداشت نماید.

اشتباهات کاربری رایجی که منجر به اسلشینگ می‌شود

با وجود اینکه بروز سناریوهای مطرح شده در بخش قبل خیلی بعید به نظر می‌رسد اما یک کانفیگ (تنظیمات) ناخواسته و اشتباه (حتی برای یک ولیدیتور معتبر) نیز می‌تواند به این امر منجر شود. این حالت‌ها را در نظر بگیرید:

• کلیدهای اعتبارسنجی یکسانی در یک زمان بر روی دو سرور اجرا گردد، که حتی ممکن است یکی از سرورها به عنوان پشتیبان سرور اول در مواقع قطعی استفاده شود. اما چطور این پیاده‌سازی معقولانه می‌تواند به اسلشینگ منتهی شود؟ وقتی که به هر دلیلی سیستم پشتیبان (failover) به اشتباه فکر کند که سیستم اصلی دچار وقفه شده و بخواهد خود را جایگزین آن نماید غافل از آنکه با این کار دو نود یکسان در یک زمان در شبکه وارد می‌شود و به سادگی ممکن است ولیدیتور را در معرض اسلشینگ قرار دهد.
• وقتی که شما بدون انتقال تاریخچه محافظتی از اسلشینگ، کلیدهای خود را به ماشین دیگر یا کلاینت دیگری منتقل می‌کنید. در این وضعیت آن نود دوم ممکن است همگامی زمانی (synced clock) درستی نداشته باشد و می‌تواند به عنوان یک ولیدیتور مخرب در شبکه شناسایی شود.
• وقتی که به طور ناخواسته از روی کلاینت ولیدیتور خود سابقه یا تاریخچه slashing protection را حذف کنید یا از دست بدهید.
• راه‌اندازی کلاینت ولیدیتور روی محیط‌های مجازی مانند Docker یا ابر در صورتی که حجم (volume) دائمی نداشته باشد چنانچه ری استارت شود منجر به از دست رفتن تاریخچه slashing protection می‌شود.
• و بدترین حالت (بد شانسی) می‌تواند رخ دادن یک باگ نرم‌‌افزاری در پروتکل باشد و منجر به اسلشینگ گردد. هرچند که ولیدیتورها دارای کانفیگ مناسب و یک دیتابیس به منظور محافظت از اسلشینگ هستند اما وجود باگ‌هایی مانند اختلال در تایم سرور و یا پردازش ناصحیح block ID ها نیز می‌تواند به اسلشینگ منجر شود.

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

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

اسلشینگ را چه کسی انجام می‌دهد؟

اسلشر (Slasher)

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

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

پاداش‌های یافتن و انتشار اسلشینگ (Whistleblower Rewards)

برای ترغیب ولیدیتورها به یافتن اسلشینگ ، پاداش‌هایی روی زنجیره beacon در پروتکل اتریوم 2.0 در نظر گرفته شده است. مقدار پاداش برای هر ولیدیتور درحدود 0.1 اتریوم است. از سوی دیگر راه‌اندازی سریع یک اسلشر کلاینت در پریسم، پاداشی را نصیب شما نخواهد کرد. به طور پیش فرض، به محض پیدا‌شدن یک اسلشینگ، رخداد آن در سریع‌ترین زمان در تمام شبکه منتشر می‌شود تا در اولین بلاک ایجاد‌شده در آن لحظه ثبت گردد. بنابراین پاداش از آنِ ثبت‌کننده خواهد بود، نه ولیدیتوری که نرم‌افزار اسلشر روی آن اجرا شده است.

پس راه‌اندازی هر اسلشری به معنای منفعت بردن و پاداش گرفتن نیست. چون اسلشینگ به ندرت اتفاق می‌افتد بنابراین تنها یک اسلشر که به درستی کانفیگ شده باشد برای کل شبکه نیاز است.

اجتناب از اسلشینگ

خبر خوب این است که اسلشینگ اجتناب‌پذیر است. راهکارهای خیلی خوبی برای اجتناب از اسلشینگ ارائه شده است:

دیتابیس محلی slashing protection

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

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

محافظ راه دور (remote slashing protection)

یک راه حل جایگزین برای اجتناب از اسلشینگ راه‌اندازی یک اسلشر است. اسلشر تمام اتفاقات اعم از تاییدات و بلاک‌های دریافتی و رفرنس‌های ولیدیتور پیش از امضای یک پیغام را رکورد می‌کند. این متد از روش قبل محکم‌تر است. اما این متد هم نمی‌تواند در برابر اجرای نسخه‌های یکسان یک ولیدیتور شبکه را محافظت نماید.

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

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

مهاجرت تاریخچه slashing protection

اگر در مواقعی نیاز داشته باشید که کلیدهای ولیدیتور خود را به ماشین دیگری یا کلاینت متفاوت دیگری در شبکه اتریوم 2.0 منتقل کنید حتما لازم است که تاریخچه slashing protection خود را نیز منتقل نمایید.

پروپوزال EIP-3067: استاندارد محافظت در برابر اسلشینگ

این استاندارد یک استاندارد رسمی برای انتقال تاریخچه بین کلاینت‌های eth2 است. در این استاندارد روال انتقال اطلاعات تاریخچه در قالب یک فایل JSON ارائه شده است. در سطح بالا این فایل شامل این موارد است:

• اطلاعات وضعیت ریشه زنجیره برای تمایز بین شبکه اصلی و شبکه آزمایشی
• اطلاعات تمام بلاک‌های امضا‌شده و امضای تصدیق‌ها برای کلید عمومی ولیدیتوری که در حال کار است

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

وارد کرد کلیدهای فعلی در پریسم

در پریسم نسخه 1.0.1 پریسم اجازه وارد کردن فایل جیسون استاندارد EIP-3076 را به کلاینت ولیدیتور شما نمی‌دهد. تیم توسعه‌دهنده پریسم برای حل این مشکل در تلاش است و در نسخه‌های بعدی این مشکل رفع خواهد شد.

انتقال تاریخچه محافظت در برابر اسلشینگ از پریسم

مانند قبل و در نسخه فعلی پریسم یعنی 1.0.1 این کار در قالب فایل جیسون استاندارد EIP-3076 امکان‌پذیر نیست و تیم توسعه‌دهنده در تلاش برای رفع آن در نسخه‌های بعدی است.

انتقال فایل‌ها از یک ماشین درحال کار پریسم به ماشین دیگر

پیشنهاد تیم توسعه‌دهنده این است که تا زمان پشتیبانی کامل از تاریخچه محافظتی اسلشینگ در پریسم این کار را انجام ندهید. اما اگر واقعا به این کار نیاز دارید بهتر است موارد زیر را در نظر بگیرید:

1. ابتدا در ماشین اول، نود beacon و ولیدیتور خود را خاموش کنید و مطمئن شوید که تمام پروسس‌ها متوقف شده‌اند. برای این کار از ابزارها و دستورات مانیتور کردن پروسس‌ها در سیستم عامل می‌تواند استفاده کنید.
2. محل دایرکتوری والت خود را بررسی کنید. اگر پریسم را پیش‌فرض نصب کرده‌اید این مسیر را می‌توانید از لیست ولیدیتور اکانت‌ها پیدا کنید اما در سیستم عامل‌های مختلف ممکن است متفاوت باشد.
3. تمام محتویات دایرکتوری مذکور را به ماشین جدید منتقل کنید.
4. اگر در ولیدیتور فعلی پارامتر datadir را تغییر داده‌اید آن دایرکتوری را نیز به ماشین جدید منتقل کنید.
5. به اندازه چند سیکل زمانی epoch صبر کنید، نود beacon خود را همگام کرده (روی ماشین جدید) و سپس کلاینت ولیدیتور را روی ماشین جدید استارت کنید.
6. اطمینان پیدا کنید که کلیدهای یکسان را روی ماشین اول یا جای دیگر اجرا نکرده باشید.

Source