האם שיבוש הערוץ מהווה איום על רשת ברק של ביטקוין? PlatoBlockchain Data Intelligence. חיפוש אנכי. איי.

האם שיבוש הערוץ מהווה איום על רשת ברק של ביטקוין?

(תודה מיוחדת לאנטואן ריארד וגלב נאומנקו, שלהם מחקר אחרון הוא הבסיס למאמר זה.)

חסימת ערוצים היא אחת הבעיות הבולטות של רשת Lightning במונחים של דברים שעלולים לשבש את הצלחת התשלומים המנותבים עליה. זוהי בעיה ידועה בקרב מפתחים שהובנה עוד לפני שהרשת עצמה עלתה לאוויר ב-mainnet והתחילה לעבד אפילו סאטושי בודד.

עד כה לנושא לא היו ממש השפעות שליליות על הרשת, אבל כשבוחנים את העובדה הזו, חשוב לזכור שהרשת עדיין, בגדול, קטנה יחסית. מעבדי סוחר החלו לתמוך בו, כמו גם כמה בורסות והרבה שירותים ועסקים מקוריים של Lightning/Bitcoin, אבל במציאות, זה לא הרבה. הרשת היא עדיין דבר קטן מאוד המשמש בעיקר ביטקוינים, וזה לא חלק גדול מאוד מהעולם בכלל.

יתרה מכך, כמות הביטקוינים שמוציאים ומשתמשים בביטקוין שלהם בקביעות בהגדרות מסחר היא תת-קבוצה קטנה עוד יותר של אותה קבוצה קטנה ממילא. רק בגלל שהתקפות אפשריות לא מתרחשות עכשיו, אנשים לא צריכים להניח שזה אומר שהן ימשיכו לא להתרחש כשהרשת תגדל לקנה מידה גדול יותר. ככל שהוא יהיה גדול יותר, כך הוא יהפוך תחרותי ויריב יותר.

מה זה ג'מינג של ערוץ?

התפיסה הבסיסית של שיבוש ערוצים היא לנתב תשלומים דרך ערוץ Lightning שברצונך לשבש מעצמך לעצמך, ולאחר מכן לא לסיים אותם על ידי שחרור ה-preimage ל-hash התשלום ב- חוזי timelock hashed (HTLCs). הקורבן/ים לא יוכלו להסיר את ה-HTLCs מהערוץ שלהם עד לאחר שפג תוקפו של נעילת הזמן להחזר, מכיוון שלא תהיה להם דרך לאכוף את תביעתם לכסף שהם חייבים אם התמונה המוקדמת הייתה שוחררת לאחר הסרתה. אם אתה תוקע ערוץ לחלוטין על ידי כך, הערוץ הזה לא יהיה מסוגל לנתב תשלומים כלשהם עד לאחר תום הנעילת הזמן בכל התשלומים הזדוניים.

ישנן שתי אסטרטגיות שונות שניתן להפעיל כאן על מנת לבצע את ההתקפה. אתה יכול לנסות לתפוס את הכמות הניתנת לניתוב בערוץ, או שאתה יכול לנסות לתפוס את כל חריצי ה-HTLC הבודדים בערוץ. לערוץ Lightning יכולים להיות רק 483 HTLC ממתינים בכל כיוון שהוא יכול לנתב - הסיבה לכך היא שיש מגבלת גודל מקסימלית של כמה גדולה עסקת ביטקוין יכולה להיות. אם תוסיף יותר מ-483 HTLCs לכל כיוון בערוץ, העסקה לסגירת הערוץ במידת הצורך תהיה גדולה מדי ולא תקפה להגשה לרשת. זה יהפוך את כל הערוץ לבלתי ניתן לאכיפה בשרשרת.

אז, תוקף יכול לנסות ולנעול את כל הנזילות בערוץ, או לנסות לנעול את כל חריצי ה-HTLC בערוץ. כל אסטרטגיה תהפוך את הערוץ לבלתי שמיש, אבל חסימת משבצות בדרך כלל תהיה זולה יותר מאשר חסימת כמות. התוקף צריך להיות בעל מטבעות ברשת כדי לבצע את ההתקפה הזו, ולכן ניתוב הערך המינימלי המותר עבור HTCL בעל קיבולת של 483 הולך להיות חסכוני יותר מאשר ניסיון לנעול את כל הנזילות הזמינה בערוץ.

למה שמישהו ירצה לג'אם ערוץ תאורה?

ישנן סיבות רבות לבצע את ההתקפה הזו. ראשית, ישות זדונית שרוצה לתקוף בעצמה את הביטקוין עלולה לתקוע את כל הערוצים המרכזיים ב"הליבה" של הרשת כדי להפוך את רוב הרשת לבלתי שמישה לניתוב תשלומים, למעט צמתים שמחוברים זה לזה מאוד. . זה ידרוש הרבה יותר מטבעות לביצוע בקנה מידה כזה, אבל זה לא משהו שצריך להוזיל כאפשרות ככל שהביטקוין יגדל ויהפוך לאלטרנטיבה למערכות כסף ותשלומים המוענקות על ידי הממשלה.

שנית, צומת ניתוב, או סוחר, יכול לנסות לבצע את ההתקפה על מתחרה על מנת להחזיר לו עמלות בניגוד למתחרים. סוחר שמוכר מוצרים דומים עלול לסתום את הערוצים של מתחרה כדי למנוע מלקוחות לבצע רכישות שם, בתקווה לתמרץ אותם לקנות בחנות שלהם במקום. צומת ניתוב שיש לו קישוריות ערוץ דומה לצומת אחר עלול להפריע לערוצים של צומת הניתוב המתחרה כדי להפוך אותם לבלתי שמישים לניתוב תשלומים. עם הזמן זה יהרוס את המוניטין של הצומת הזה מבחינת אמינות הניתוב, ובגלל קישוריות דומה, יגרום ליותר ויותר סבירות שהארנקים של המשתמשים יבחרו את הצומת של התוקף כדי לנתב תשלומים ברחבי הרשת.

התקפות אלו יכולות להיות אפילו יותר יעילות בהון עבור התוקף אם הן מנותבות בצורה מעגלית דרך ערוץ בודד מספר פעמים. אם הם מספיק קרובים לקורבן ברשת, הם יכולים לבנות מסלול תשלום שמסתובב וממשיך לעבור בערוץ של הקורבן. יש גבולות לאורך מסלול התשלום, כך שלא ניתן לעשות זאת עד אין סוף, אבל ביצוע מסלול תשלום בלולאה כמו זה יכול להוריד באופן דרסטי את כמות המטבעות שהתוקף צריך כדי לתקוע לחלוטין את ערוציו של הקורבן.

מקל על התקפות שיבוש ערוץ

ניתן ליישם כמה אמצעים בסיסיים וחלקיים על מנת להגדיל את העלות לתוקפים ולהפחית את הנזק לקורבנות. הראשון יהיה תהליך רב-שלבי לטיפול ב-HTLCs.

נכון לעכשיו, כל HTLC מוסיף בנפרד פלט חדש בעסקת ההתחייבות עבור מצב הערוץ הנוכחי. תהליך דו-שלבי יכול ליצור פלט נוסף בודד בעסקת ההתחייבות, ולאחר מכן לקיים עסקה שנייה אחריה שנוספה לה ה-HTLC בפועל. זה יאפשר מקסימום 483 כפול 483 חריצי HTLC לערוץ (או 233,289 חריצים). עם זאת, זה לא באמת מתקן שום דבר בפני עצמו, וידרוש הארכת מנעולי הזמן מכיוון שאתה מוסיף עסקה נוספת לאכיפת דברים על השרשרת, ולמעשה יכול לעזור לתוקף יותר מאשר לקורבן אם הם ישתמשו במבנה העסקה החדש הזה וב- הקורבן לא. עם זאת, זה יעזור בשילוב עם טכניקה אחרת המוסברת לרגע.

השנייה תהיה אסטרטגיה תגובתית, שבה צומת שנפל קורבן ל-jamming יכול פשוט לפתוח ערוץ חדש לאותו עמית כמו זה שנתקע. עם זאת, הדבר ידרוש הון נוסף לשם כך, אינו מתקן את עלות ההזדמנות של תקלות הערוץ השני ואובדן הכנסות מעמלות, והערוץ החדש עלול להיתקע גם לאחר מכן אם לתוקף יש הון זמין לעשות זאת. .

הטכניקה השלישית תהיה דליית חריצי HTLC. נכון לעכשיו יש 483 משבצות, וזוהי מגבלת משבצת אחת המיושמת באופן אוניברסלי על כל התשלומים ללא קשר לערך התשלום. צמתים יכולים ליצור דליים נפרדים של מגבלות משבצות קטנות יותר ולהחיל אותן על תשלומים בעלי ערכים שונים, כלומר, לתשלומים של 100,000 נקודות או פחות תהיה גישה ל-150 משבצות בלבד. לכן, ניתוב תשלומים בעלי ערך קטן יותר לא יכול לצרוך את כל חריצי ה-HTLC הזמינים.

תשלומים של 100,000 sats ל-1 מיליון sats יכולים לקבל גישה ל-300 משבצות, ו-1 מיליון sats ל-10 מיליון סטים יכולים לקבל גישה ל-483 המשבצות המלאות. זה יעלה באופן משמעותי את עלות ההון של תוקף ל-Jam, מכיוון שהם כבר לא יוכלו לצרוך את כל 483 המשבצות בתשלום הערך הקטן ביותר האפשרי. בנוסף, מכיוון שלא ניתן אפילו לשדר ולאכוף יציאות HTLC מתחת לסף האבק (כרגע, 546 sats), כל דבר מתחת לגבול זה יכול להיות מטופל כ-"0 bucket" מכיוון שבכל מקרה לא נוצר פלט HTLC. צמתים יכולים פשוט לאכוף מגבלות על עסקאות אלו על סמך משאבי CPU בשימוש או מדדים אחרים כדי למנוע מהם להפוך לסיכוני מניעת שירות, תלוי כמה הם יכולים להרשות לעצמם להפסיד אם הם לא יוסדרו ביושר.

ניתן להשתמש ב-bucketing של חריצים בשילוב עם טיפול ב-HTLC דו-שלבי כדי לייעל את היישום של מגבלות HTLC, כלומר, תשלומים בעלי ערך גבוה יותר יכולים להשתמש במבנה הדו-שלבי כדי ליצור עבורם יותר משבצות לכל ערוץ מכיוון שערך התשלום הגבוה יותר מגדיל את העלות של שיבוש אותם עבור תוקף, מה שהופך את הסבירות לניצול לרעה של מגבלת משבצות גבוהה יותר לביצוע תוקפי שיבוש.

במחקרם שצוטטו לעיל, ריארד ונאומנקו הראו שעם השילוב האופטימלי של חריצי דליות והרחבת חריץ דו-שלבי, הסיבה לתקיעת חריצים יכולה להיות יקרה כמו חסימת כמות. זה לא יפתור באופן מקיף את הבעיה, אבל זה כן מעלה את העלות המינימלית של ביצוע המתקפה אם היא מיושמת באופן נרחב על ידי צמתים ברחבי הרשת.

שני הפתרונות המקיפים שהם בחנו הם עמלת מראש/זמן החזקה עבור נעילת נזילות, ומערכת מוניטין המשתמשת באסימוני Chaumian מסונוורים. ה-TLDR של תכנית העמלות היא שאג"ח עבור עמלה מראש תשולם עבור ניתוב HTLC שצפוי לקחת זמן רב להתיישב, וככל שהיא תישאר לא מסודרת, היא תשחרר עמלה לכל צומת ניתוב. לכל נתח זמן שחלף ללא הסדר. הבעיה היא שאכיפת זה עלולה להוביל לצורך בסגירת ערוצים אם עמלות לא יישלחו בעת הצורך, והיא תגרום למקרי שימוש לגיטימיים הדורשים זמני נעילה ארוכים לשלם את אותה עמלה גבוהה יותר שתשלם תוקף המנסה לשבש ערוצים.

ערכת המוניטין תכלול "אגב הימור" באמצעות הוכחות אפס ידע כדי להוכיח את השליטה בביטקוין כהגנה של סיביל, ולאחר מכן שימוש באגרה הקשורה למוניטין שלך כדי לרכוש אסימוני Chaumian מסונוורים מצמתי ניתוב שייפדו ויונפקו מחדש ב-HTLCs. להסתדר בהצלחה באופן ששומר על הפרטיות. צמתים היו מנפיקים אסימונים פעם אחת לכל זהות, ואם HTLC לא הוסדר או החזר בזמן, צמתים יכולים לסרב להנפיק מחדש את האסימון, ובכך למנוע ממשתמש ניתוב דרך הצומת שלו אלא אם כן הם מבזבזים את הזמן והכסף כדי ליצור חדש איגרת מניות עם מטבעות שונים שיונפקו באסימון חדש.

למי שרוצה לקרוא עוד על שני פתרונות אלו, מידע נוסף ניתן למצוא בסעיפים חמש ו שש במחקר של ריארד ונאומנקו.

ראוי גם לציין שאם צמתי ניתוב היו מאמצים מערכות נאמנות מבוססות צד שלישי או קווי אשראי מבוססי אמון, כפי שכתבתי על כאן, כל הבעיות הללו הקשורות לשיבוש ערוצים יפסיקו להשפיע עליהן. זה יהיה שינוי עצום במודל האמון לניתוב צמתים, אבל תהיה לו השפעה אפסית על אנשים שמשתמשים בערוצי Lightning אמיתיים כדי לשלוח ולקבל סטים, אבטחת הכספים שלהם או היכולת שלהם לאכוף זאת על השרשרת.

אנשים אולי לא ירצו לשמוע את זה, אבל בסופו של יום, אם הפתרונות לעיל להפחתת חסימת ערוצים עבור ערוצים בפועל אינם מספיקים, מערכות צד שלישי אלו הן תמיד אופציה פוטנציאלית.

זהו פוסט אורח מאת Shinobi. הדעות המובעות הן לגמרי שלהם ואינן משקפות בהכרח את הדעות של BTC Inc או Bitcoin Magazine.

בול זמן:

עוד מ מגזין Bitcoin