دیوید شوارتز پس از کندی در XRPL خطرات شبکه را توضیح داد

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

کندی در بسته شدن دفترها بررسی را آغاز کرد

این مشکل با ثبت یک ناهنجاری توسط تیم عملیات XRP Ledger در شبکه بروز کرد. بسته شدن دفترها در شبکه به‌طور قابل توجهی کندتر از حالت عادی انجام می‌شد که مهندسان را به تحقیق در مورد منبع تأخیر سوق داد. در این فرآیند، سوالاتی در مورد مقاومت ساختار غیرمتمرکز در جامعه مطرح شد.

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

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

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

به ادعای نقطه خطای واحد پاسخ داد

شوارتز همچنین ادعاهای مربوط به وابستگی شبکه به یک گره یا مرکز واحد را رد کرد. او گفت که XRPL به‌طور کامل در یک ساختار غیرمتمرکز عمل می‌کند و بسته شدن یک مرکز بزرگ، حتی گره خود او، یا تحت بار زیاد قرار گرفتن، به‌طور مستقیم بر قابلیت کارکرد کلی شبکه تأثیر نخواهد گذاشت.

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

سیستم‌های نظارتی تحت بار دچار اختلال شدند

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

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

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

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

سوابق ارسال شده به سرور آزمایشی قدیمی بررسی می‌شود

در طول بررسی، مشخص شد که سوابق روزانه مربوط به یکی از توسعه‌دهندگان XRPL به یک سرور آزمایشی قدیمی بنیاد XRP Ledger ارسال شده است. این موضوع جمع‌آوری کامل داده‌ها در زمان وقوع حادثه را دشوارتر کرد.

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