تست‌نت اتریوم ۲/۰ متوقف شد.

آخرین به‌روزرسانی: ۲۸ مرداد ۱۳۹۹

در روز جمعه تست‌نت شبکه بلاک چین اتریوم ۲/۰ با مشکل مواجه شد و مراحل نهایی این نسخه آزمایشی فعلا اجرا نمی‌شود.

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

همان‌طور که در مقاله «معرفی شبکه بلاک چین اتریوم ۲» گفته شده است، اجرای اتریوم دو در چند فاز شروع خواهد شد و پیش از آغاز هر فاز، آن مرحله به صورت آزمایشی اجرا می‌شود. یکی از تست‌نت‌های آزمایشی، Medalla Testnet، یک شبکه عمومی است که توسط بنیاد اتریوم ایجاد شده است. این پروتکل برای فاز صفر شبکه اتریوم ۲/۰ و ایجاد مکانیزم اجماع اثبات سهام به کار گرفته می‌شود. تیم  Prysmatic، یک برنامه با زبان برنامه نویسی Go و به نام Prysm برای مشتریان اتریوم ۲/۰ نوشته است. در این برنامه مشخصات رسمی اتریوم ۲ پیاده‌سازی می‌شود.

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

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

خطای ایجاد شده به شکل زیر است:

“WARN roughtime: Roughtime reports your clock is off by more than 2 seconds offset=4h0m0.028854657s.”

در نتیجه وقتی نودها برای زمان‌بندی به سرور NTP متصل شدند، مقادیر اشتباهی را دریافت کردند. در حال حاضر در شبکه آزمایشی اتریوم ۲/۰ از شش سرور NTP برای زمان‌بندی استفاده می‌شود، اما نکته‌ای که وجود دارد این است که تمام سرورها مقادیر اشتباه ارائه داده‌اند.

طبق گزارش‌های ارائه شده از روند این نسخه آزمایشی و بررسی مشکل پیش آمده:

 «تمام سرورهای زمان‌بندی کلادفایر (Cloudflare Roughtime) زمان‌بندی اشتباه ارائه داده‌اند، و نودهای کلاینت پریسم نیز در دام این خطا افتاده‌اند.»

رائول جردن (Raul Jordan) یکی از توسعه‌دهندگان شبکه‌ی اتریوم ۲، در رابطه با این موضوع توضیح داد که در حال حاضر میزان مشارکت‌ها صحیح نیست زیرا:

تقریباً هیچ‌کس با سر زنجیره (Chain Head) هماهنگ‌ نشده است و تا وقتی که حتی یک گره هماهنگ با سرزنجیره هم نداشته باشیم، نمی‌توان یک مشارکت قابل اعتماد برقرار کرد. حتی مطمئن نیستم که میزان مشارکت کمتر از صفر درصد است یا خیر.

نیشانت داس (Nishant Das)، یکی دیگر از توسعه‌دهندگان اتریوم ۲، توضیح داده است که در حال حاضر و با این‌که برخی از نودهای کلاینت پریسم بروز هستند، اما تعداد افراد زیادی سعی دارند که به صورت هم‌زمان خود را با سر زنجیره هماهنگ کنند. بنابراین از آن‌جا که سیستم نمی‌تواند به تمام درخواست‎‌ها همزمان پاسخ دهد، نودها با خطا مواجه می‌شوند.

جردن در ادامه توضیح داد که:
برای شبکه‌ی اتریوم، زمان بسیار مهم است و این شبکه بدون هماهنگ‌سازی زمان، نمی‌تواند به درستی کار کند. ما برای تنظیم ساعت محلی کاربران از سیستم زمان کلادفایر (Cloudflare’s roughtime) استفاده می‌کنیم.

در روز جمعه سیستم تنظیم زمانی این شرکت بیش از چهار ساعت خاموش ماند و منجر به بروز اختلال در این شبکه شد. راه حل این مشکل این بود که ساعت سیستم کاربران به صورت اجباری بر اساس سیستم شرکت تنظیم نمی‌شد و در این صورت سیستم تنها خطاهایی مبنی بر زمان‌بندی اشتباه ارائه می‌کرد. 

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

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

ما برای رفع این مشکل، به صورت اتفاقی تمام ویژگی‌های مهم عملکرد نودهای پریسم را حذف کردیم، که این کار باعث بدتر شدن اوضاع شد.

این اتفاق، سودمندی تست‌نت را نشان‌ می‌دهد. ما با تست‌نت می‌توانیم به مشکلات احتمالی سیستم پی ببریم و برای رفع آن تلاش کنیم. این موضوع یادآور رویداد Devcon در سال ۲۰۱۶ است که پیتر زیلاگی (Peter Szilagyi) و سایر توسعه‌دهندگان اتریوم، یک کد دی‌داس (DDos Code) ایجاد کرده و باعث اختلال در شبکه شدند.

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

این اتفاق باعث شد که حدود ۳۰ هزار تایید‌کننده متوجه شوند که چرا نباید از پرمصرف‌ترین کلاینت استفاده کنند؛ زیرا شبکه‌ی اتریوم ۲/۰ به گونه‌ای طراحی شده است که از کلاینت‌ها و سیستم عامل‌های کوچک، اما ایمن استفاده کند.

اگر مشکلی در سیستم عامل ویندوز کاربر وجود داشته باشد می‌تواند بر روی شبکه اتریوم ۲ تاثیر بگذارد، بنابراین تمام تایید کنندگانی که از این ویندوز استفاه می‌کردند دچار مشکل شدند. در حالی‌که در عملکرد سایر تاییدکنندگان با سیستم عامل‌های دیگر مانند لینوکس، مشکلی ایجاد نشد.

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

همچنین نکته قابل تامل دیگر این اتفاق این بود که شبکه به صورت کامل متوقف شد در حالی‌که پیش از این در سایر اتفاقات از جمله رخداد ۲۰۱۶ که در بالا ذکر شد، هک DAO و حتی فورک، شبکه اتریوم به صورت کامل متوقف نشده بود و تولید شدن بلاک‌ها ادامه داشت.

مشکلات مربوط به حافظه هنگامی ایجاد می‌شوند که شبکه حدود ۳۰ درصد از تایید کنندگانش را از دست بدهد و پس از افزایش این مقدار به ۵۰ درصد مشکلات ایجاد شده بزرگ‌تر می‌شوند و سپس بعد از رسیدن به ۷۰ درصد شبکه متوقف می‌شود.

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

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

 اثر DDoS، یا منع سرویس توزیع‌ شده (distributed denial of service) یکی از مسائل امنیتی در شبکه‌های کامپیوتری است. در این اثر پس از سرازیر شدن تقاضاهای زیاد به یک سرور و استفاده بیش از حد از منابع آن (پردازنده، پایگاه داده، پهنای باند، حافظه و…)، سرویس‌دهی عادی سرور به کاربرانش دچار اختلال شده و یا از دسترس خارج می‌شود.