By Bitcoin מגזין - לפני חודשיים - זמן קריאה: 6 דקות
נתיחה שלאחר המוות על מתקפת הרכיבה על אופניים החלפת ברק
אז הרבה רעש נעשה מסביב פגיעות ברק נחשף לאחרונה על ידי אנטואן ריארד. אנשים רבים טוענים שהשמים נופלים, שהברק שבור ביסודו, ושום דבר לא יכול להיות רחוק יותר מהאמת. אני חושב שחלק מהבעיה הוא שאנשים לא באמת מבינים איך הפגיעות הזו עובדת, ראשית, ושנית הרבה אנשים לא מבינים איך הפגיעות האישית הזו חופפת לבעיות ידועות אחרות ברשת Lightning שיש להן פתרונות ידועים.
אז ראשית, בואו נעבור וננסה להבין את הפגיעות עצמה. כאשר תשלום Lightning מנותב על פני הרשת, דבר אחד שחשוב להבין הוא כיצד פועלות נעילות הזמן להחזר תשלום שנכשל. לקפיצה הקרובה ביותר למקלט יש מנעול זמן של 'x', ולכל קפיצה שחוזרת חזרה לשולח יש אחת של 'x+1', 'x+2' וכן הלאה. נעילות הזמן מתארכות בהדרגה ככל שאתה הולך כל דילוג מהמקלט בחזרה לכיוון השולח. הסיבה לכך היא שאם תשלום מגיע למקבל, אבל בעיה כלשהי מונעת מהתמונה המוקדמת להתפשט כל הדרך חזרה אל השולח, לקפיצה שבה היא נעצרה יש זמן לאכוף אותה על השרשרת, ולשים את התמונה המוקדמת שם שכל הקפיצות הקודמות צריכות לאשר את התשלום. אַחֵרwise מישהו באמצע, היכן שהכשל מתרחש, יכול שההופ היוצא שלו ידרוש את הכספים עם התמונה המוקדמת, וההופ שהעביר אותו אליו ידרוש את זה עם נתיב ההחזר שלו, ולהשאיר את האדם הזה באמצע, מזל שהוא הפסיד כְּסָפִים.
מתקפת הרכיבה ההחלפה היא דרך מסובכת לנסות ולהשיג בדיוק את התוצאה הלא רצויה הזו, צומת היעד מפסיד כסף בכך שההופ היוצא תובע את הכספים עם עסקת הצלחה, וההופ הנכנס תובע כספים באמצעות עסקת ההחזר. זה מצריך לעצור את צומת הקורבן ולמנוע מהם לראות את התמונה המוקדמת בעסקת ההצלחה בצד אחד עד לאחר תום נעילת הזמן בצד השני, כדי שיוכלו לתבוע את ההחזר שם.
זה דורש משחק מאוד ממוקד ומסובך של מניפולציה של ה- mempool של הקורבן. בואו נסתכל על מבנה העסקה בפועל המעורב כאן. יש לך את עסקת ההתחייבות, שהיא העסקה העיקרית המייצגת את מצב ערוץ Lightning. יש לו פלט לכל צד של הערוץ המייצג כספים בשליטה מלאה של חבר זה או אחר, ותפוקות עבור כל HTLC בתהליך ניתוב. התפוקות הללו הן אלו שאנו עוסקים בהן. ניתן לבזבז כל פלט HTLC באופן מיידי בכל עת עם התמונה המוקדמת מהמקלט, או לאחר תום נעילת הזמן בהחזר.
המתקפה דורשת שלצד זדוני, או שני צדדים זוממים, יש ערוץ משני הצדדים של צומת הקורבנות המנתב תשלום. אז לבוב, הקורבן, יש ערוץ עם אליס וקרול, התוקפים, ותשלום מנותב מקרול לבוב לאליס. כעת זכור, נתיב ההחזר של Timelock בין אליס לבוב יפוג ויהיה תקף לפני ההחזר בין קרול לבוב.
התוקפים מנתבים תשלום דרך בוב, ואז אליס תסרב לשלוח לבוב את התמונה המקדימה כדי לסיים את התשלום כשהיא תקבל אותו. מה שבוב יעשה עכשיו זה לחכות עד שחלון הנעילה יפוג בינו לבין אליס, וללכת לשדר את עסקת ההתחייבות של הערוץ ועסקת ההחזר כדי לקבל את אישורה לפני שחלון הנעילה יפוג. מה שאליס תעשה הוא אז ללכת לבזבז את עסקת הקדם-תמונה כדי לתבוע את הכספים עם פלט שאינו קשור לערוץ, ומיד לאחר מכן להוציא כפול את הקלט השני בעסקת ההצלחה הקדם-תמונה. המטרה כאן היא להוציא את עסקת הזמן הקצוב של בוב מה-mempool, אבל גם לגרש את עסקת ההצלחה שלפני התמונה כדי שבוב לא יראה אותה. אם כן, הוא ילמד את התמונה המוקדמת ויכול פשוט לתבוע את הכספים בערוץ שלו עם קרול לפני שעסקת הזמן הקצוב שלה תהיה תקפה להוצאתה.
אליס וקרול צריכות לעשות זאת על בסיס עקבי, בכל פעם שבוב משדר מחדש את עסקת הזמן הקצוב שלו עם אליס, עד שיחלוף גובה הבלוק שבו עסקת הזמן הקצוב של קרול תקפה. אז הם יכולים להגיש את עסקת ההצלחה בצד של אליס, ואת עסקת הזמן הקצוב בצד של קרול, ולהשאיר את בוב מחזיק את התיק לאחר שאיבד את ערך התשלום שהוא ניתב.
הבעיה עם זה היא כפולה. ראשית, של הקורבן Bitcoin יש למקד את צומת הליבה באופן ספציפי כדי להבטיח שבשום זמן עסקת הצלחת הקדם-תמונה לא תתפשט לתוך ה-mempool שלהם, שם צומת ה-Lightning שלהם יכול לרכוש את ה-preimage. שנית, אם העסקה השנייה שבה אליס משתמשת כדי לפנות את העסקה הקדם-תמונה מאושרת, אליס כרוכה בעלות (זכור, הרעיון הוא להחליף את עסקת הזמן הקצוב בתמונה המוקדמת, כך שהיא תסולק מה-mempool, ולאחר מכן החלף את עסקת הקדם-תמונה ב- שני, הוצאת כפולה של הקלט הנוסף בעסקת הקדם-תמונה). זה אומר שבכל פעם שבוב משדר מחדש את עסקת הזמן הקצוב שלו, אליס צריכה לשלם אגרה גבוהה יותר כדי לגרש אותה מחדש, וכשזה מאושר היא כרוכה בעלות.
אז בוב יכול לאלץ את אליס לגבות עלות גדולה פשוט על ידי שידור חוזר קבוע של עסקת הזמן הקצוב שלו עם עמלה גבוהה יותר, כלומר אם פלט התשלום של HTLC אינו שווה משמעותית יותר מהעמלות שאליס יכולה לגבות, ההתקפה לא כדאית מבחינה כלכלית. . כמו כן, ניתן יהיה למנוע את ההתקפה לחלוטין על ידי שינוי אופן בניית עסקאות הצלחת HTLC וזמן קצוב. על ידי שימוש בדגל SIGHASH_ALL, כלומר החתימה מתחייבת לכלל העסקה והופכת לבלתי חוקית אם הפרט הקטן ביותר (כמו הוספת הקלט החדש בטרנזקציית הקדם-תמונה הנדרשת להתקפה זו) משתנה. זה לא יעבוד עם הגרסה הנוכחית של ערוצי Lightning תפוקות עוגן, אבל זה יפתור את הבעיה לחלוטין. פיטר טוד גם הציע א תכונת קונצנזוס חדשה זה יפתור לחלוטין את הבעיה, בעצם מנעול זמן הפוך, שבו העסקה תהפוך לפסולה לאחר זמן מסוים או blockheight במקום להיות תקף לאחר מכן. ללכת כל כך רחוק אבל לא הכרחי לדעתי.
פשוט שידור חוזר של העסקה שלך באופן קבוע עם פגיעה קלה בעמלה הוא הקלה מאסיבית של המתקפה, אבל יש גם דינמיקות רבות שפשוט הופכות את זה לא לבעיה רצינית בלי קשר. ראשית, אם אתה לא צומת ניתוב, זו לא באמת בעיה רצינית. אז רוב משתמשי הקצה בטוחים מהתקפה זו. שנית, יש הרבה סיבות מדוע צמתים לא מאפשרים לאף אדם אקראי לפתוח להם ערוצים. צמתים גדולים הם מאוד סלקטיביים לגבי מי הם מצווים, שכן לערוצים אקראיים שאינם מנוהלים ביעילות או מקצועית יש עלות בדמות הון שקוע או מבוזבז בערוצים שאינם בשימוש. אז כל צומת גדול שיהפוך למטרה עסיסית למתקפה הזו הוא לא טריוויאלי אפילו להתחבר אליו מלכתחילה, שלא לדבר על להתחבר אליהם עם מספר ערוצים כדי להוציא את המתקפה מלכתחילה. לבסוף, כמו כתבתי על בעבר, התקפות אחרות שאינן קשורות אפשריות ברשת כבר מחייבות מסננים והגבלות באופן שבו צמתים בוחרים לטפל ב-HTLCs שהם יכולים להעביר. כלומר הגבלות על גודל התשלומים שיעבירו, כמה הם יאפשרו בכל זמן נתון וכו'. אז גם אם אפשר לפתוח ערוץ עם צומת ששווה לתקוף, ככל שהרשת תתפתח תהיה מחשבה רבה יותר על קריטריונים ומסננים על ההחלטה אם בכלל להעביר תשלום מלכתחילה.
בסך הכל, מדובר בסוגיה לגיטימית ומתקפה אפשרית, אבל הן מבחינת הפחתות ישירות, והן באינטראקציה של המתקפה עם פתרונות לנושאים אחרים בטווח הארוך, זו לא בעיה בלתי פתירה. זה נושא לגיטימי, ולבטל אותו כ-FUD גרידא זו לא תגובה מדויקת, אבל לטעון שהשמיים נופלים ורשת ברק כפרוטוקול נחרץ גורלה זה הרבה יותר מדי את הנושא.
הזמן יצעד הלאה, ניתקל בבעיות, ונתקן את הבעיות הללו ככל שיגיעו. כמו שתמיד עשינו.
מקור מקורי: Bitcoin מגזין