بهره برداری از اشکال لایتنینگ یک انتخاب اخلاقی بود

این یک سرمقاله نظری توسط شینوبی، یک مربی خودآموخته در فضای بیت کوین و میزبان پادکست بیت کوین مبتنی بر فناوری است.

برای دومین بار در تقریباً یک ماه گذشته، btcd/LND یک باگ مورد سوء استفاده قرار گرفت که باعث شد تا در اجماع از بیت کوین Core منحرف شوند. بار دیگر، بوراک توسعه‌دهنده‌ای بود که این آسیب‌پذیری را راه‌اندازی کرد - این بار به وضوح عمدی بود - و یک بار دیگر، مشکل کد تجزیه تراکنش‌های بیت‌کوین در بالای لایه اجماع بود. همانطور که در من بحث کردم قطعه روی اشکال قبلی که بوراک راه‌اندازی کرد، قبل از Taproot محدودیت‌هایی در مورد حجم اسکریپت و داده‌های شاهد در یک تراکنش وجود داشت. با فعال‌سازی Taproot، این محدودیت‌ها حذف شدند و تنها محدودیت‌های محدودیت اندازه بلوک برای محدود کردن این بخش‌های تراکنش‌های فردی باقی ماند. مشکل آخرین باگ این بود که علیرغم این واقعیت که کد اجماع در btcd به درستی ارتقا یافته بود تا این تغییر را منعکس کند، کد مدیریت انتقال همتا به همتا - از جمله تجزیه داده‌ها قبل از ارسال یا هنگام دریافت - به درستی ارتقا پیدا نکرد. بنابراین بلوک‌ها و تراکنش‌های پردازش کد قبل از تأیید اعتبار برای اجماع، داده‌ها را شکست دادند، هرگز آن را به منطق اعتبارسنجی اجماع منتقل نکردند و بلوک مورد نظر هرگز تأیید نشد.

این بار هم اتفاق بسیار مشابهی افتاد. محدودیت دیگر در بخش همتا به همتا پایگاه کد، اعمال محدودیت بر روی داده های شاهد به صورت نادرست، محدود کردن آن به حداکثر 1/8 اندازه بلوک در مقابل اندازه بلوک کامل بود. بوراک آفرید معامله با داده های شاهد فقط یک واحد وزن بیش از حد سخت و یک بار دیگر گره های btcd و LND در آن ارتفاع بلوک متوقف شدند. این تراکنش یک تراکنش غیر استاندارد بود، به این معنی که با وجود اینکه کاملاً بر اساس قوانین اجماع معتبر است، طبق سیاست پیش‌فرض mempool معتبر نیست و بنابراین گره‌ها آن را در سراسر شبکه ارسال نمی‌کنند. استخراج آن به یک بلوک کاملاً ممکن است، اما تنها راه این است که آن را مستقیماً در اختیار یک ماینر قرار دهید، کاری که بوراک با کمک F2Pool انجام داد.

این واقعاً به این نکته منجر می‌شود که هر قطعه کدی که هدف آن تجزیه و اعتبارسنجی داده‌های بیت‌کوین است، باید به شدت مورد بازرسی قرار گیرد تا اطمینان حاصل شود که مطابق با کاری است که Bitcoin Core انجام خواهد داد. فرقی نمی کند که آن کد موتور اجماع برای اجرای یک گره باشد یا فقط یک قطعه کد که تراکنش ها را برای یک گره لایتنینگ منتقل می کند. این باگ دوم بود به معنای واقعی کلمه درست بالاتر از یکی از ماه گذشته است در پایگاه کد حتی توسط هیچکس در لایتنینگ لبز کشف نشد. AJ Towns آن را در 11 اکتبر گزارش داد، دو روز پس از اینکه باگ اصلی توسط 998-از-999 تراکنش مولتی سیگ Burak ایجاد شد. قبل از حذف به مدت 10 ساعت به صورت عمومی در Github پست شد. سپس یک اصلاح ایجاد شد، اما منتشر نشد، با این هدف که در نسخه بعدی LND بی سر و صدا این مشکل برطرف شود.

اکنون، این روش کاملاً استاندارد برای یک آسیب‌پذیری جدی است، به‌ویژه با پروژه‌ای مانند Bitcoin Core که در آن چنین آسیب‌پذیری در واقع می‌تواند آسیب جدی به شبکه/پروتکل لایه پایه وارد کند. اما در این مورد خاص، یک خطر جدی برای وجوه کاربران LND ایجاد کرد و با توجه به این واقعیت که به معنای واقعی کلمه دقیقاً در کنار باگ قبلی قرار داشت که همان خطرات را داشت، احتمال یافتن و سوء استفاده از آن بسیار زیاد بود. همانطور که بوراک نشان داد. این سؤال پیش می‌آید که آیا رویکرد وصله‌های بی‌صدا در مورد آسیب‌پذیری‌هایی مانند این که می‌تواند کاربران را در معرض سرقت وجوه باز بگذارد (زیرا گره آن‌ها قادر به تشخیص وضعیت‌های کانال قدیمی و جریمه مناسب آن‌ها ناتوان مانده است) راهی است.

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

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

LND نیز تنها چیزی نبود که تحت تأثیر قرار گرفت. مایعات روند میخکوبی نیز شکسته شد، برای رفع آن نیاز به به روز رسانی برای کارمندان فدراسیون دارد. نسخه‌های قدیمی‌تر Rust Bitcoin همچنین تحت تأثیر قرار گرفتند، که باعث شد تا stall بر برخی از کاوشگرهای بلوک و نمونه های الکترز تأثیر بگذارد (پیاده سازی سرور باطن برای Electrum Wallet). اکنون، به استثنای Liquid's Peg که در نهایت پس از انقضای قفل زمانی، وجوه را در اختیار کلیدهای بازیابی اضطراری نگهداشته شده توسط Blockstream قرار می دهد - و به طور واقع بینانه در طرح فیلم به سبک سرقت که Blockstream این سرمایه ها را به سرقت برده است، همه دقیقاً می دانند که باید به دنبال چه کسانی بروند - این افراد دیگر. مسائل هرگز سرمایه های کسی را در هیچ نقطه ای در معرض خطر قرار نمی دهند. همچنین، Rust Bitcoin در واقع این باگ خاص را در نسخه‌های جدیدتر اصلاح کرده بود، که ظاهراً به هیچ ارتباطی با نگه‌دارندگان پایگاه‌های کد دیگر برای برجسته کردن پتانسیل چنین مسائلی منجر نشد. تنها بهره برداری فعال از باگ در شبکه بود که به طور گسترده نشان داد که این مشکل در چندین پایگاه کد وجود دارد.

وقتی صحبت از آسیب‌پذیری‌هایی مانند این در نرم‌افزار لایه ۲ بیت‌کوین به میان می‌آید، این مشکلات بزرگی را به همراه دارد. اول، جدیت بررسی این پایگاه های کد برای اشکالات امنیتی و نحوه اولویت بندی آن در مقابل ادغام ویژگی های جدید. من فکر می‌کنم با توجه به اینکه این باگ دوم حتی توسط نگهبانان پایگاه کدی که در آن وجود داشت پیدا نشد، امنیت همیشه در اولویت نیست، حتی اگر به معنای واقعی کلمه درست در کنار باگ اولیه کشف شده در ماه گذشته بود. پس از یک باگ بزرگ که سرمایه کاربران را در معرض خطر قرار داد، آیا ممیزی داخلی آن پایگاه کد انجام نشد؟ آیا کسی از خارج از پروژه آن را کشف کرد؟ این نشان دهنده اولویتی برای محافظت از سرمایه کاربران نسبت به ایجاد ویژگی های جدید برای جذب کاربران بیشتر نیست. دوم، این واقعیت که این مشکل قبلاً در Rust Bitcoin اصلاح شده بود، عدم ارتباط بین نگهبانان پایگاه‌های کد مختلف را در رابطه با باگ‌هایی مانند این نشان می‌دهد. این کاملاً قابل درک است، زیرا وجود پایگاه‌های کد کاملاً متفاوت باعث نمی‌شود کسی که باگ را در یکی پیدا کرده است، بلافاصله فکر کند: «باید با تیم‌های دیگری که نرم‌افزار مشابهی را در زبان‌های برنامه‌نویسی کاملاً متفاوت می‌نویسند تماس بگیرم تا در مورد احتمال وجود چنین باگی به آنها هشدار دهم.» شما باگی در ویندوز پیدا نمی کنید و بلافاصله فکر می کنید که باگ را به نگهبانان هسته لینوکس گزارش دهید. بیت کوین به عنوان پروتکلی برای اجماع توزیع شده در سراسر یک شبکه جهانی، جانوری بسیار متفاوت است. شاید توسعه دهندگان بیت کوین باید شروع به فکر کردن در امتداد این خطوط در مورد آسیب پذیری های نرم افزار بیت کوین کنند. مخصوصاً وقتی صحبت از تجزیه و تفسیر داده‌هایی می‌شود که با اجماع مرتبط هستند.

در نهایت، شاید وقتی صحبت از پروتکل‌هایی مانند لایتنینگ به میان می‌آید، که به مشاهده زنجیره بلاک در همه زمان‌ها بستگی دارد تا بتواند به حالت‌های کانال قدیمی واکنش نشان دهد تا امنیت را حفظ کند، تجزیه مستقل و تأیید داده‌ها باید به حداقل مطلق برسد - اگر به طور کامل حذف نشده و به بیت کوین Core یا داده هایی که مستقیماً از آن مشتق شده اند واگذار نشده است. Core Lightning به این شکل طراحی شده است که به نمونه ای از Bitcoin Core متصل می شود و برای اعتبارسنجی بلوک ها و تراکنش ها کاملاً به آن بستگی دارد. اگر LND به همین صورت عمل می‌کرد، هیچ یک از این باگ‌ها در btcd بر کاربران LND تأثیر نمی‌گذاشتند که سرمایه‌شان را در معرض خطر قرار دهد.

به هر نحوی که کارها انجام شود - یا اعتبارسنجی برون سپاری به طور کامل یا صرفاً به حداقل رساندن اعتبارسنجی داخلی و نزدیک شدن به آن با دقت بیشتر - این اتفاق نشان می دهد که چیزی باید در رویکرد به این موضوع تغییر کند که چگونه نرم افزار لایه 2 تعامل با داده های مربوط به اجماع را مدیریت می کند. بار دیگر، همه بسیار خوش شانس هستند که این مورد توسط یک بازیگر مخرب مورد سوء استفاده قرار نگرفت، بلکه توسط یک توسعه دهنده که یک نکته را اثبات می کند، مورد سوء استفاده قرار گرفت. همانطور که گفته شد، بیت کوین نمی تواند روی خوش شانس بودن یا امیدواری به وجود عوامل مخرب حساب کند.

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

این یک پست مهمان توسط شینوبی است. نظرات بیان شده کاملاً متعلق به خود آنها است و لزوماً نظرات BTC Inc یا مجله Bitcoin را منعکس نمی کند.