Lightning For Life - כיצד ברק יכול להשתלב באינטרנט

צומת המקור: 1332590

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

רוי שיינפלד הוא המייסד והמנכ"ל של Breez, חברת ביטקוין המתמקדת בתשלומי Lightning.

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

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

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

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

כפי שלמדתי ב האקתון bolt.fun (צעקה לגבר שלי ג'ונס!), מפתחי אינטרנט רבים ישמחו לבנות אפליקציות עם פונקציונליות של Lightning. הרצון להשתלב קיים בחוץ, אבל נראה שרבים אינם מבינים שיש גם דרך. למעשה, ישנן מספר דרכים להביא את Lightning לרשת וכל אחת מתפתחת עם החוזקות שלה ומקרי השימוש שלה. אולי העולם פשוט לא יודע או מבין אותם?

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

מקור תמונה

LNURL: שמירה על פשטות

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

LNURL הוא סט פשוט מאוד של מפרטים כדי לגשר על חלק מפערי ה-UX שנותרו, כולל הפקת חשבוניות. היופי של LNURL הוא הפשטות שלו. כפי שהשם מרמז, מפרטי LNURL מבוססים על קישורים, או בצורה של כתובות URL ללחיצה או קודי QR הניתנים לסריקה. קישורי URL הם חלק מהרקע הטכנולוגי שלנו. כבר ראיתם ארבעה בפוסט הזה, כנראה בלי ששמתם לב אליהם. קודי QR הם אותו דבר, רק ייצוג חזותי שונה:

קודי QR הם קלים ומוכרים. אני לא רואה שאנחנו מוותרים עליהם בזמן הקרוב.

יש כמה LNURL מפרטים שם בחוץ, אבל אלה רלוונטיים במיוחד לשילוב האינטרנט של Lightning:

  • LNURL-Pay: נניח שאתה מנהל בלוג ביטקוין. אתה רוצה לאסוף עצות אבל אתה לא רוצה ליצור ולעבד חשבונית עבור כל טיפ, וגם לא ליצור אינטראקציה עם כל קורא בנפרד עבור כל טיפ. LNURL-Pay מאפשר לך ליצור קודי QR לתשלומים בטווח מוגדר, נניח, 2,500 - 10,000 נקודות. משתמש יכול פשוט לסרוק קוד, להזין את הסכום המדויק ולשלם. המשתמש לא מודע לשפת התמונות המוקדמות והחשבוניות, במקום זאת פשוט סורק קוד ומגיב להנחיה.
  • LNURL-נסיגה: זה התרחיש ההפוך: אתה רוצה לשלם למשתמשים עבור אינטראקציה עם האתר שלך, אבל אתה רוצה לחסוך מהם את הטרחה של הפקת חשבונית. LNURL-Withdraw מאפשר למשתמשים לסרוק קוד או ללחוץ על קישור שינחה את הארנקים שלהם להפיק את סוג החשבונית המתאים ולשלוח אותה לצומת שלך לתשלום.
  • LNURL-Auth הוא עוד כלי LNURL מגניב. זה יוצר ערכת מפתחות ציבורית-פרטית המבוססת על ביטויי הזרע בארנקי המשתמשים כדי לאפשר להם להיכנס לאתרים בדוי. זה פרטי כמו ביטוי הזרע עצמו וקשה יותר לכוח גס מאשר "סיסמה123" או "סוללת_סוס_סוס נכונה." והכי חשוב, הוא משתמש בנתונים שכבר נמצאים בארנקים של המשתמשים, מוכן לשימוש עם מעט קלט.

כתובות ברק

הדוא"ל אולי כל כך מוכר שאנחנו לוקחים את היתרונות שלו כמובן מאליו. כתובות דואר אלקטרוני הן ייחודיות בהחלט (בניגוד ל טביעות אצבע), ודוא"ל הופכים את השליחה והקבלה של מידע בדיוק לאדם הנכון לקלה ביותר. כתובות ברק יש את אותו פורמט xxx@yyy.zzz כמו אימייל, אבל הם מאפשרים למשתמשים להעביר כספים מבלי להתעסק עם קוד QR.

נכון לעכשיו, LNURL-Pay הוא האמצעי הפופולרי ביותר ליישום כתובות Lightning אך פרוטוקול Lightning Address פתוח לחדשנות. לדוגמה, ניתן להרחיב כתובות Lightning לשימוש בחשבוניות סטטיות או BOLT12 (בסיס טכנולוגיית Lightning; המקבילה ל-Lightning של מפרטי ה-Bitcoin Improvement Proposal [BIP]), לאחר אימוץ אלה.

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

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

WebLN

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

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

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

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

קישור לסרטון יוטיוב כאן.

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

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

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

ממשקי API

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

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

שיקול מרכזי בבחירת שירות Lightning ואיזה API מתאים לאיזה אינטרנט או אפליקציה לנייד הוא האם לבחור פתרון מתארח בעצמו כמו שרת BTCPay, LNPay or LNbits, או פתרון משמורת כמו זבדי or שביתה. שוב, חלים פשרות.

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

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

בחר מה שמתאים לך.

LNC

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

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

LNC מאפשר גישה לממשק ה-gRPC (grpc remote procedure call) של הצומת, כך שהמפעילים יכולים לפתוח, לסגור ולאזן מחדש ערוצים בנוסף לפונקציות מתקדמות אחרות. מסוף אינטרנט ברק הוא דוגמה טובה לאיך זה יכול להיראות בפועל. מסוף זה הוא בעצם שלט רחוק לצמתים של משתמשי כוח שהם יכולים לגשת אליהם מכל מקום.

אתה מכיר את הקומיקס הזה "ואז מתרחש נס". ובכן, LNC הוא הנס. 

מקור תמונה

מה הקאץ? יש שני. ראשית, LNC הוא פרי היצירה של Lightning Labs ועובד רק עם LND לעת עתה. שנית, ככל שיש לך יותר שליטה על הצומת שלך מבחוץ, כך תצטרך להעניק יותר הרשאות לממשק החיצוני הזה; וככל שתעניק יותר הרשאות, כך משטח ההתקפה שלך עשוי להיות גדול יותר. Lightning Labs מפרטת מספר איומים אפשריים עצמם, כולל בני אדם עם גישה לדמון, ניסיונות דיוג, פגיעויות בדפדפן והרחבות של צד שלישי. בעוד שאנשי הטכנולוגיה ב-Lightning Labs הם מהנדסים רציניים, כל אפליקציה עם הרשאות כה רחבות יכולה להוות הזמנה לקבל "pwned".

LSATs

אסימוני אימות של Lightning Service (LSATs) הם האמצעי הסופי לשילוב Lightning עם האינטרנט שעליו נדון. לא, הם לא דרך לבדוק מי מעצבן מספיק כדי להפוך עורך דין. הרעיון הבסיסי מאחורי LSATs הוא שימוש מוגדר בקפידה מקרונים כדי לאמת את המשתמש ולהגדיר את יכולות התשלום שלו באתר.

בחוכמה, פרוטוקול LSAT משתמש בקוד HTTP 402 שהוא קוד שגיאה בצד הלקוח שפירושו "נדרש תשלום"או"שמור לשימוש עתידי," תלוי את מי שואלים (מפרט Lightning Labs LSAT מדהים, אך באופן פרדוקסלי, קובע "המסמך הזה מניח שהעתיד הגיע"). קוד 402 זה משמש להפעלת "כרטיס" - מקרון המזהה בו זמנית את המשתמש ומגדיר כיצד אותו משתמש יכול לקיים אינטראקציה עם השירות.

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

הטעימה ביותר מכל טכנולוגיות האינטגרציה של Lightning.

מקור תמונה

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

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

נשמע נפלא! טכנולוגיה מהפכנית האוסרת בוטים ומשלבת את Lightning והאינטרנט! הַלְלוּיָה! מה הקאץ? אני לא יודע, אבל אני לא יכול להבין איך LSATs קיימים כבר כמה שנים ובכל זאת אני לא יכול לנקוב בשירות מרכזי אחד שיישם אותם. האם זו רק שאלה של אפקטים ברשת וכולם מחכים שכולם יעשו את הצעד? או שיש איזו עיכוב עמוק יותר, מהותי יותר? אולי אתה, קורא יקר, תוכל לחנך אותי בנושא הזה.

העתיד הוא הרחבה של ההווה

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

האם לא ברור ש-Lightning מיועדת לחדור לרשת ושהרשת נועדה להשתמש ב-Lightning כטכנולוגיית התשלום המובילה שלה? או שזה רק אני?

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

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

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

בול זמן:

עוד מ מגזין Bitcoin