پس از مرگ در مورد حمله دوچرخه سواری جایگزین رعد و برق
بنابراین سروصدای زیادی پیرامون آسیب‌پذیری Lightning که اخیراً توسط Antoine Riard افشا شده است، ایجاد شده است. بسیاری از مردم ادعا می کنند که آسمان در حال سقوط است، که صاعقه اساساً شکسته شده است، و هیچ چیز نمی تواند دور از حقیقت باشد. من فکر می‌کنم بخشی از مشکل این است که مردم واقعاً نمی‌دانند این آسیب‌پذیری چگونه کار می‌کند، اولاً، و ثانیاً بسیاری از مردم نمی‌دانند که چگونه این آسیب‌پذیری فردی با سایر مسائل شناخته‌شده در شبکه لایتنینگ که راه‌حل‌های شناخته شده‌ای دارند همپوشانی دارد.
بنابراین، ابتدا اجازه دهید مرور کنیم و سعی کنیم خود آسیب‌پذیری را درک کنیم. هنگامی که پرداخت لایتنینگ در سراسر شبکه انجام می شود، یک نکته کلیدی برای درک این است که قفل زمانی برای بازپرداخت یک پرداخت ناموفق چگونه کار می کند. نزدیک‌ترین جهش به گیرنده دارای قفل زمانی «x» است و هر جهشی که به فرستنده برمی‌گردد یکی از «x+1»، «x+2» و غیره دارد. قفل‌های زمانی به تدریج طولانی‌تر می‌شوند که هر پرش از گیرنده به سمت فرستنده برمی‌گردد. دلیل این امر این است که اگر پرداختی به گیرنده برسد، اما مشکلی مانع انتشار preimage تا فرستنده شود، جهش جایی که متوقف شده است زمان دارد تا آن را روی زنجیره اعمال کند، و preimage را در آنجا قرار دهد. هاپ های قبلی باید پرداخت را تایید کنند. در غیر این صورت، شخصی در وسط، جایی که شکست اتفاق می‌افتد، می‌تواند از هاپ خروجی‌اش بخواهد وجوه را با پیش‌نمایش مطالبه کند، و هاپی که آن را برای آنها ارسال کرده است آن را با مسیر بازپرداخت خود مطالبه کند، و آن شخص را در وسط بخت بگذارد. وجوه از دست رفته
حمله دوچرخه‌سواری جایگزین روشی پیچیده برای تلاش و انجام دقیقاً آن نتیجه نامطلوب است، گره هدف با از دست دادن پول توسط هاپ خروجی با یک تراکنش موفقیت‌آمیز وجه دریافتی و هاپ ورودی از طریق تراکنش بازپرداخت مطالبه وجه می‌کند. این امر مستلزم متوقف کردن گره قربانی، و جلوگیری از دیدن تصویر اولیه در تراکنش موفقیت آمیز در یک طرف تا زمانی که قفل زمانی منقضی می شود در طرف دیگر، جلوگیری می کند، بنابراین آنها می توانند بازپرداخت را در آنجا مطالبه کنند.
این به یک بازی بسیار هدفمند و پیچیده برای دستکاری حافظه قربانی نیاز دارد. بیایید به ساختار واقعی معامله در اینجا نگاه کنیم. شما تراکنش تعهد را دارید که تراکنش اصلی نشان دهنده وضعیت کانال لایتنینگ است. دارای یک خروجی برای هر طرف کانال است که نشان دهنده وجوه کاملاً تحت کنترل یک عضو یا دیگری است و خروجی برای هر HTLC در فرآیند مسیریابی. این خروجی ها همان خروجی هایی هستند که ما به آنها توجه می کنیم. هر خروجی HTLC می تواند بلافاصله در هر زمان با تصویر اولیه از گیرنده، یا پس از انقضای قفل زمانی در بازپرداخت خرج شود.
این حمله مستلزم آن است که یک طرف مخرب، یا دو طرف توطئه گر، کانالی در دو طرف گره قربانی داشته باشند که پرداخت را هدایت کند. بنابراین، باب، قربانی، یک کانال با آلیس و کارول، مهاجمان، و پرداخت از کارول به باب به آلیس دارد. اکنون به یاد داشته باشید که مسیر بازپرداخت قفل زمانی بین آلیس و باب منقضی می شود و قبل از بازپرداخت بین کارول و باب معتبر می شود.
مهاجمان یک پرداخت را از طریق باب انجام می دهند و سپس آلیس از ارسال تصویر اولیه برای باب برای نهایی کردن پرداخت پس از دریافت آن خودداری می کند. کاری که باب اکنون انجام خواهد داد این است که منتظر بماند تا پنجره قفل زمانی بین او و آلیس منقضی شود و به پخش تراکنش تعهد کانال و تراکنش بازپرداخت برود تا قبل از منقضی شدن پنجره قفل زمانی تایید شود. کاری که آلیس انجام خواهد داد این است که تراکنش preimage را صرف مطالبه وجوه با خروجی غیرمرتبط با کانال کند و بلافاصله پس از آن دومین ورودی را در تراکنش موفقیت آمیز preimage دوبرابر خرج کند. هدف در اینجا این است که تراکنش مهلت زمانی باب را از mempool خارج کنیم، اما همچنین تراکنش موفقیت آمیز preimage را حذف کنیم تا باب آن را نبیند. اگر این کار را انجام دهد، پیش‌نمایش را یاد می‌گیرد و به سادگی می‌تواند وجوه موجود در کانال خود را با کارول مطالبه کند، قبل از اینکه تراکنش مهلت زمانی او برای خرج کردن معتبر باشد.
آلیس و کارول باید این کار را به طور ثابت انجام دهند، هر بار که باب تراکنش تایم اوت خود را با آلیس بازپخش می کند، تا زمانی که ارتفاع بلوک از جایی که تراکنش تایم اوت کارول معتبر است بگذرد. سپس می‌توانند تراکنش موفقیت‌آمیز را از طرف آلیس، و تراکنش تایم اوت را از طرف کارول ارسال کنند، و باب را رها کنند که کیسه را نگه دارد و ارزش پرداختی را که مسیریابی می‌کرد از دست داده باشد.
مشکل در این دو مورد است. اولاً، گره Core بیت کوین قربانی باید به طور خاص مورد هدف قرار گیرد تا اطمینان حاصل شود که تراکنش موفقیت آمیز preimage در هیچ زمانی در mempool آنها منتشر نمی شود، جایی که گره لایتنینگ آنها می تواند preimage را به دست آورد. ثانیاً، اگر تراکنش دومی که آلیس برای خارج کردن تراکنش preimage استفاده می‌کند تأیید شود، آلیس متحمل هزینه می‌شود (به یاد داشته باشید، ایده این است که تراکنش زمان‌بندی با preimage جایگزین شود، به طوری که از mempool خارج شود، سپس تراکنش preimage را با تراکنش جایگزین کنید. دوم، دوبار مصرف ورودی اضافی در تراکنش preimage). این بدان معناست که هر بار که باب تراکنش تایم اوت خود را مجدداً پخش می کند، آلیس باید هزینه بیشتری را برای اخراج مجدد آن بپردازد، و هنگامی که تایید شد او در واقع هزینه ای متحمل می شود.
بنابراین باب می‌تواند آلیس را مجبور کند که صرفاً با بازپخش منظم تراکنش مهلت زمانی خود با کارمزد بالاتر، هزینه زیادی متحمل شود، به این معنی که اگر خروجی HTLC پرداختی به‌طور قابل‌توجهی بیشتر از هزینه‌هایی نباشد که آلیس متحمل می‌شود، انجام حمله از نظر اقتصادی به صرفه نیست. . همچنین می‌توان با تغییر نحوه ساخت تراکنش‌های موفقیت HTLC و زمان‌بندی به طور کامل از حمله جلوگیری کرد. با استفاده از پرچم SIGHASH_ALL، به این معنی که امضا به کل تراکنش متعهد می‌شود و در صورت تغییر کوچک‌ترین جزئیات (مانند افزودن ورودی جدید در تراکنش اولیه تصویر مورد نیاز برای این حمله) نامعتبر می‌شود. این با نسخه فعلی کانال های لایتنینگ با استفاده از خروجی های لنگر کار نمی کند، اما مشکل را به طور کامل حل می کند. پیتر تاد همچنین ویژگی اجماع جدیدی را پیشنهاد کرده است که به طور کامل مشکل را حل می کند، اساساً یک قفل زمانی معکوس، که در آن تراکنش نامعتبر می شود. بعد از یک زمان خاص یا ارتفاع بلوک به جای معتبر شدن پس از آن. با این حال به نظر من رفتن تا آنجا ضروری نیست.
صرفاً پخش مجدد تراکنش خود به طور منظم با کمی افزایش کارمزد، کاهش گسترده ای از حمله است، اما پویایی های متعددی نیز وجود دارد که صرف نظر از آن، آن را به یک مشکل جدی تبدیل می کند. اول، اگر شما یک گره مسیریابی نیستید، این واقعاً یک مسئله جدی نیست. بنابراین اکثر کاربران نهایی از این حمله در امان هستند. ثانیاً، دلایل زیادی وجود دارد که چرا گره‌ها به هیچ فرد تصادفی اجازه نمی‌دهند کانال‌هایی را برای آنها باز کند. گره‌های بزرگ در مورد افرادی که با آنها همتا می‌شوند بسیار انتخابی هستند، زیرا کانال‌های تصادفی که به طور کارآمد یا حرفه‌ای مدیریت نمی‌شوند، هزینه‌ای به شکل سرمایه هدر رفته یا هدر رفته در کانال‌های بلااستفاده دارند. بنابراین هر گره بزرگی که بتواند هدفی آبدار برای این حمله بسازد، در وهله اول حتی برقراری ارتباط با آنها بی اهمیت نیست، چه رسد به اتصال به آنها با چندین کانال برای از بین بردن حمله در وهله اول. در نهایت، همانطور که در گذشته در مورد آن نوشته‌ام، سایر حملات نامرتبط ممکن در شبکه از قبل نیاز به فیلترها و محدودیت‌هایی در نحوه انتخاب گره‌ها برای مدیریت HTLCهایی دارند که می‌توانند ارسال کنند. یعنی محدودیت‌هایی در اندازه پرداخت‌هایی که ارسال می‌کنند، تعداد پرداخت‌هایی که در هر زمان معین اجازه خواهند داد، و غیره. بنابراین حتی اگر بتوانید کانالی را با گره‌ای باز کنید که ارزش حمله را داشته باشد، با تکامل شبکه، از طریق معیارها و فیلترها فکر بیشتری می‌شود. برای تصمیم گیری در مورد فوروارد کردن پرداخت در وهله اول.
به طور کلی، این یک مسئله مشروع و حمله احتمالی است، اما هم از نظر کاهش مستقیم، و هم اینکه چگونه حمله با راه‌حل‌های دیگر مسائل در درازمدت تعامل خواهد داشت، این یک مشکل غیرقابل حل نیست. این یک مسئله مشروع است و رد کردن آن به عنوان صرفاً FUD واکنش دقیقی نیست، اما اینکه ادعا کنیم آسمان در حال سقوط است و شبکه لایتنینگ به عنوان یک پروتکل محکوم به فنا است، این موضوع را بسیار فراگیر می کند.
زمان به پیش خواهد رفت، ما با مشکلاتی مواجه خواهیم شد و آن مشکلات را به محض آمدن برطرف خواهیم کرد. مثل همیشه.