By Bitcoin מגזין - לפני שנה - זמן קריאה: 1 דקות
כמה דרכים בהן נוכל לשדרג את ניתוב התשלומים ברשת Lightning
על מנת להתפתח לפרוטוקול שמיש לכל העולם, יש לשקול שיפורים מסוימים בקנה מידה עבור Lightning.
רשת Lightning היא פתרון עסקאות שכבה 2 מפותח, צומח במהירות Bitcoin רֶשֶׁת. יותר ויותר שירותים ובורסות משלבים אותו, הנזילות הזמינה לניתוב תשלומים הולכת וגדלה, ומדי שנה מפתחים עוד יישומים ודרכים למשתמשים ליצור עמו אינטראקציה. יש לו גם בעיות רבות שעליהן להתגבר בטווח הארוך:
המדרגיות מגבילה כמה ערוצים ניתן לפתוח או לסגור בשרשרת בכל פעם. יש בעיה עם הגודל המינימלי Hash Time Locked חוזה (HTLC) עולה ככל שהעמלות על השרשרת עולות גם הן, כי זה חייב להיות חסכוני להסדר. יש גם שלל בעיות פרטיות.נושא מרכזי אחד שנדון לעתים קרובות הוא דרישות הנזילות לניתוב תשלומים. כדי לנתב תשלום מוצלח, צריך להיות קישור של ערוצים, כל הדרך מהשולח למקבל, שיש לו מספיק נזילות בצד ימין של הערוץ כדי שניתן יהיה להעביר את התשלום. זה הופך את ההחלטה היכן לפרוס את המטבעות שלך ברשת להחלטה חשובה מאוד. זה גם אומר שכמות הנזילות הכוללת שאנשים מוכנים לפרוס היא מעין גבול עליון לכמות הערך שהרשת יכולה לעבד.
בסופו של דבר, מה שזה מסתכם הוא שכשאתה פותח ערוץ, אתה מחליט לנעול את הכסף הזה כך שניתן יהיה להשתמש בו רק כדי לנתב תשלומים לאותו שותף ערוץ, ולמי שהם מחוברים אליו בגרף. כן, בסופו של דבר הרעיון של רשת Lightning הוא שעל ידי ביצוע מספיק הכשות אתה יכול למצוא חיבור כמעט לכל מקום. עם זאת, המציאות היא שאם מישהו אחר יכול לבצע ניתוב תשלום ליעד תוך שימוש בפחות הקפות ממה שאתה יכול, זה הנתיב שייבחר ככל הנראה לניתוב התשלום. ברק כבר דורש ביטחונות יתר במידה רבה, כלומר, כדי לנתב תשלום של 1 BTC על פני 10 דילוגים, נדרש 10 BTC של בטחונות להיות נעולים בערוצי תשלום לאורך המסלול הזה. התחרות על קשרים טובים ליצירת הכנסות מניתוב מחמירה זאת על ידי תמריץ ביטחונות מיותרים עוד יותר.
זו בעיה הנובעת מהעובדה שערוצים של Lightning הם "צינורות" דו-צדדיים שיכולים פשוט לדחוף ערך קדימה ואחורה בשני הכיוונים הללו. אבל זה העניין: הבעיה היא סוג של בעיה דמיונית. תשלומים ב-Lightning משתמשים ב-HTLC, סקריפט ב-a Bitcoin פלט שאומר שאדם אחד יכול לתבוע את הפלט ולבזבז אותו על ידי חשיפת התמונה המוקדמת ל-hash, או שאדם אחר יכול לתבוע את הפלט ולבזבז אותו לאחר המתנה לתוקף של זמן נעילת זמן. זהו סקריפט כללי שניתן ליישם בשרשרת, בערוצי Lightning, על גבי רשתות מדינה, על רשתות צד וכו'. כל עוד אתה יכול להשתמש ב-HTLC, בתיאוריה, כל דבר יכול להשתתף בניתוב תשלום Lightning.
רשת מכוניות
A שרשרת המדינה הוא למעשה משהו כמו ערוץ Lightning, אלא שאתה יכול להעביר בעלות על כל הערוץ כולו מחוץ לרשת. מודל האמון שלהם תלוי בכך שהמפעיל (שיכול להיות פדרציה) של רשת המדינה מסרב לשתף פעולה עם בעלים קודמים ולגנוב את שרשרת המדינה מהבעלים הנוכחי. זה לא חסר אמון כמו ערוץ Lightning, אבל הוא הרבה יותר גמיש מכיוון שניתן להעביר את הבעלות ללא צורך בביצוע עסקה בשרשרת. בהתחשב בכך שרשתות מדינה מבוססות על עסקאות חתומות מראש מחוץ לשרשרת, אתה יכול להוסיף להן HTLCs.
זה מאפשר להשתמש בהם כדי לייעל את היעילות של ניתוב תשלומים ב-Lightning על ידי מתן אפשרות למפעילי צומת להקצות מחדש נזילות תוך כדי תנועה מחוץ לשרשרת. במקום צורך לפתוח ערוצים ולהטמיע בהם נזילות כדי להיות מחוברים היטב מבעוד מועד, ניתן להקצות מחדש את הכספים שלהם באופן דינמי תוך כדי תנועה מחוץ לשרשרת בתגובה לשינוי הביקוש למקומות שהם לא מחוברים אליהם (או לא מחוברים מספיק טוב) ). הדרישה היחידה היא שהצד השני ירצה להעביר את הנזילות למתן אמון במפעיל ה-statechain.
Sidechains
רשתות צד יכולים ליישם כל כללים שרירותיים שהם רוצים. זמני החסימה יכולים להיות שונים, גדלי הבלוק יכולים להיות שונים, ניתן לשנות כל דבר. הקאץ' היחיד כרגע הוא להזיז את שלך Bitcoin לרשת צדדית, אתה צריך לסמוך על פדרציה ששומרת על הכספים בשרשרת הראשית. אתה יכול להחיל HTLCs על sidechain שמשתמש Bitcoinמערכת הסקריפטים של; אתה יכול לקבל מערכת סקריפטים יותר דמוית Ethereum המאפשרת לעשרות אנשים לחלוק חשבון שמחלק יתרות ומעדכן אותן לפי אם HTLC מצליח או נכשל; אתה יכול לעשות הכל. כל עוד הבלוקצ'יין תומך במתן כסף על תנאי לצד אחד אם הם מייצרים hash, והצד השני לאחר תום נעילת זמן, הם יכולים לעזור לנתב תשלומי Lightning. בלוקצ'יין אחרים יכולים להתנסות בדרכים להפוך את הקצאת הנזילות ליעילה יותר מהעיקרית Bitcoin blockchain. אתה יכול אפילו פשוט לעשות משהו בסיסי כמו לבנות עוד רשת Lightning בשרשרת שיותר זול לפתוח ולסגור ערוצים בה. הדמיון הוא הגבול.
מבנים חדשים לגמרי
הנה רעיון אקראי משלי: אנשים רבים יכולים כולם להצטבר יחד לסינגל m-n (כלומר, 3 מ-5) כתובת multisig עם כמה סוכני נאמנות, ופשוט סומך על סוכני ההפקדה שיסדרו את העניינים כמו שצריך. כל אדם בכתובת וסוכני הנאמנות יכולים לעקוב ולעדכן "יתרות" בהתבסס על ניתוב תשלום; רשום HTLCs שבהם נעשה שימוש והאם הם סולקו בהצלחה או החזר; ולהסדיר מעת לעת את היתרות על השרשרת. אתה פשוט בונה את ה-multisig כך שמשתתף "ניתוב" יחיד וכל סוכני הנאמנות הם כל מה שצריך להוציא מה-multisig. אתה יכול אפילו ליצור עסקת החזר כספי שננעלה בזמן כדי להחזיר את הכסף של כולם לאחר תקופה מסוימת, שהחיסרון שלה יהיה כל הכסף שמישהו הרוויח במהלך חיי הבנייה יאבד אם זה היה בשימוש. זה ידרוש הסדר בשרשרת לפני שעסקת ההחזר תהיה תקפה להוצאה.
זה ידרוש אמון בסוכני הנאמנות, אבל היתרון יהיה שכל אדם ב"קבוצת UTXO" זו יוכל להעביר כספים או לנתב HTLC ל כל אדם אחר בקבוצת UTXO. זה יהיה רווח יעילות מסיבי בהקצאת נזילות.
קשרי אשראי
הדרך הפשוטה ביותר להשיג יעילות תהיה פשוט לסמוך על אנשים. אם אתה יכול להרוויח כסף בניתוב תשלום ברחבי הרשת עבור מישהו, אבל אין לך ערוץ פתוח לצומת הדרוש לניתוב תשלום זה, אז אתה יכול פשוט להבטיח לשלם להם מאוחר יותר אם הם סומכים עליך. אם היית אדם או ישות מהימנים במיוחד, ואנשים רבים ברשת היו מוכנים לסמוך עליך בדרך זו, אז אתה יכול לנתב תשלומים במידה עצומה של גמישות ולא צריך לשקוע הון בערוצי תשלום בכל רחבי הרשת. פשוט תתקבע בכנות בסופו של יום, ואנשים ימשיכו לסמוך עליך שתעביר עבורך תשלומים על בסיס מערכת כבוד.
הבעיה האחת והיתרונות
היתרון העיקרי של כל האפשרויות הללו הוא שלמרות שלכולן יש הבדלים עצומים במונחים של מודל האמון (רובם למעשה דורשים ממך במפורש אמון באנשים שאתה מקיים איתם אינטראקציה אם תבחר להשתמש בהם), זה לא משנה כלל עבור השולח והמקבל. אם יש לי ערוץ Lightning רגיל ללא אמון ואני רוצה לשלם למישהו שיש לו גם ערוץ Lightning קונבנציונלי נטול אמון, איך התשלום הזה יגיע לשם לא משנה לאף אחד מאיתנו בכלל. כשאני שולח את הכסף, התשלום הזה מתעדכן ונאכף בערוץ Lightning שלי עם עמיתיי ללא אמון, בדיוק כמו רגיל. כשהמקבל באמת מקבל את הכסף, התשלום הזה מתעדכן ונאכף בערוץ ה-Lightning שלו עם עמיתיהם, ללא אמון, בדיוק כמו רגיל. העובדה שמישהו באמצע סומך רק על הבטחה מבני גילו לשלם לו מאוחר יותר היא לגמרי לא רלוונטית לשנינו. שלחתי את הכסף שלי וכבר אין לי שליטה עליו, והכונס למעשה קיבל את הכסף שלו ועכשיו יש לו שליטה עליו, ללא אמון.
הבעיה היא, איך אני, בתור השולח, מגלה על מערכות היחסים האלה? ב-Lightning, השולח הוא זה שבוחר את המסלול לתשלום, לאחר הסתכלות בטבלת הניתוב של הערוצים הציבוריים ברשת המוכנים להעביר תשלומים. כדי לפרסם את היכולת לנתב תשלום יש להציג את ה-UTXO ברשת שמימנה את ערוץ ה-Lightning שלך ולהוכיח שזהו ערוץ בפועל. וזו הבעיה כאן, אף אחד מהרעיונות לעיל לא יוכל לספק זאת, כך ששולח התשלום יכול להיות מודע לאפשרויות האחרות הללו לנתב תשלום. אם פרוטוקול הרכילות ומבנה טבלת הניתוב עודכנו כדי לאפשר את הדברים האחרים הללו, ניתן היה להודיע להם על אפשרויות אחרות.
הדרישה האמיתית היחידה היא לוודא שפרסום דרכים אחרות "שאינן ערוצים" לניתוב תשלומים לא יפתח וקטורים של מניעת שירות. התוכנית הנוכחית, המחייבת שיתוף של ה-UTXO שמימן ערוץ, קיימת כהגנה מפני אנשים המפרסמים ערוצי פרסום שאינם קיימים, שעלולים להעמיס על הצמתים בנתוני רכילות חסרי תועלת וכן להוביל לכך שמשתמשים מנסים כל הזמן לבצע תשלומים שמעולם לא היו. הזדמנות להצליח מלכתחילה.
בסופו של יום, ישנן בעיות לפתור כדי להגביר את הגמישות כיצד ניתן לנתב תשלומים ברשת, אך הן בעיות ניתנות לפתרון. לחשוב ש-Lightning חייב להמשיך לתפקד בצורה שהיא פועלת כיום כדי לעבוד כרשת תשלומים היא חשיבה מאוד צרה, ואם לומר זאת בבוטות, להמציא בעיות שהן בעיקר דמיוניות.
זהו פוסט אורח מאת Shinobi. הדעות המובעות הן לגמרי שלהן ואינן משקפות בהכרח את הדעות של BTC Inc או Bitcoin מגזין.
מקור מקורי: Bitcoin מגזין