לא, השקת אפליקציה מבוזרת (dapp) בבלוקצ'יין לא תוביל לעסק מצליח. למעשה, רוב המשתמשים אפילו לא חושבים אם האפליקציה פועלת על הבלוקצ'יין - הם פשוט בוחרים במוצר זול יותר, מהיר ופשוט יותר.

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

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

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

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

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

גישה מס' 1: בלוקצ'יין כ-backend

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

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

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

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

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

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

בואו נעשה כמה חישובים גסים. Booking.com אומר שיש להם כמעט 2 מיליון מלונות רשומים אצלם. נניח שבמלון ממוצע יש 10 חדרים וכל אחד מוזמן רק 20 פעמים בשנה - זה נותן לנו ממוצע של 13 הזמנות בשנייה.

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

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

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

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

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

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

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

גישה מס' 2: אדריכלות בהשראת Blockstack

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

משמאל: הגישה הראשונה, שבה משתמשים מקיימים אינטראקציה באמצעות הבלוקצ'יין. מימין: משתמשים מקיימים אינטראקציה ישירה זה עם זה, וה-blockchain משמש רק לזיהוי וכדומה.

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

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

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

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

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

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

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

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

מסקנה

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

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

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

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

מקור: www.habr.com