- רשתות אפליקציות (Appchains) הן בלוקצ'יין המתמחים ביישום או תחום ספציפי, עם פרמטרים טכניים וכלכליים המותאמים לצרכיהם.
- הארכיטקטורה המודולרית שלה משפרת את המדרגיות, הביצועים, האבטחה ויכולת הפעולה ההדדית בהשוואה לשכבה 1 לשימוש כללי.
- מערכות אקולוגיות כמו Polkadot, Cosmos ו-Avalanche מאפשרות יצירת רשתות אפליקציות בקלות באמצעות מצנחים, אזורים ותת-רשתות עם כלים ואבטחה משותפים.
- למרות שהן מציעות יתרונות גדולים, רשתות אפליקציות מתמודדות עם אתגרים טכניים, רגולטוריים ואימוץ שעדיין נמצאות בפתרון.
רשתות אפליקציות הפכו לאחד המושגים החזקים ביותר במערכת האקולוגית של הבלוקצ'יין . אם שמעתם על רשתות מצנחים, תת-רשתות או אזורים כבר זמן מה ואתם לא בטוחים מה הקשר שלהם לכל זה, הישארו בסביבה, כי אנחנו הולכים לנתח אותם כאן, תוך כדי שמירה על הזמן שלנו בלי להסתבך.
בשורות הבאות, נחקור בדיוק מהי אפליקציית רשת (appchain), כיצד היא פועלת באופן פנימי, כיצד היא שונה מבלוקצ'יין שכבה 1 או מרשת צדדית (sidechain) , יתרונותיה, חסרונותיה, ומקרי השימוש שבהם היא הגיונית ביותר. נסקור גם את המערכות האקולוגיות העיקריות (Polkadot, Cosmos, Avalanche, בין היתר) כדי לתת לכם סקירה מקיפה ומעשית.
מהי אפליקציית רשת: הגדרה פשוטה ומדוע היא חשובה
כשאנחנו מדברים על רשתות אפליקציות, אנחנו מתייחסים לבלוקצ'יין שתוכננו במיוחד עבור יישום מסוים או קבוצת פונקציונליות מסוימת . הן אינן רשתות "אחת המתאימה לכולם", אלא רשתות המתמקדות בצרכים של אפליקציית אפליקציה או תעשייה ספציפית (פיננסים, משחקים, שרשרת אספקה, מדיה חברתית וכו').
במקום לשתף תשתית אחת עם אלפי פרויקטים המתחרים על אותם משאבים, מה שיכול ליצור צווארי בקבוק ברשת , כל רשת יישומים שומרת כוח מחשוב, רוחב פס ואחסון עבור מקרה השימוש שלה . זה מאפשר להתאים פרמטרים כמו גודל בלוק, עמלות, מודל אבטחה וסוג חוזה חכם לצרכים הספציפיים של אותה אפליקציה.
דוגמאות ברורות לגישה זו הן מצנחי Polkadot, תת-הרשתות של Avalanche ואזוני Cosmos . כולם פועלים לפי אותה פילוסופיה: שרשראות ייעודיות, המחוברות למערכת אקולוגית גדולה יותר, אך עם אוטונומיה ניכרת בקביעת הכללים שלהן.
דרך פשוטה לדמיין זאת היא לחשוב על רשת ראשית ככביש מהיר גדול ועל רשתות האפליקציות כעל נתיבים השמורים ומותאמים לסוגי תנועה מסוימים : אחד רק למשאיות, אחר רק לאוטובוסים, אחר רק למכוניות חשמליות... הכביש הראשי עדיין שם, אך כלי רכב מסוימים משתמשים בנתיבים המותאמים לתנועה יעילה יותר.
מושגים בסיסיים ואבולוציה של רשתות אפליקציות
הבלוקצ'יין הציבוריים הראשונים נולדו כתשתיות כלליות : כולם פרסו את החוזים והיישומים שלהם על אותה שכבת בסיס. זה עבד לזמן מה, אך ככל שמספר המשתמשים וה-DApps גדל, צצו הבעיות הקלאסיות של רוויה, עמלות גאות והשהייה גבוהה.
מכאן עלה הרעיון של יצירת שרשראות ייעודיות אשר שומרות על אבטחת מערכת אקולוגית משותפת, אך מקלות על הלחץ על הרשת הראשית . לפיכך, רשתות אפליקציות נולדו כתגובה לשתי מגבלות ברורות: גמישות (מספר עסקאות לשנייה) וחוסר התאמה אישית עמוקה (פרמטרים של הרשת, כלכלה פנימית, ממשל וכו').
עם הזמן, הקונספט שוכלל, וכיום אנו מדברים על מערכות אקולוגיות שלמות המכוונות לרשתות אפליקציות . Polkadot עושה זאת באמצעות מרכז אבטחה משותף ומצנחים המחוברים לשרשרת Relay; Cosmos, באמצעות קבוצת אזורים המתקשרים זה עם זה באמצעות IBC; Avalanche, באמצעות תת-רשתות המקבצות אימותים עבור שרשראות ספציפיות.
התפתחות זו אפשרה למגזרים כמו פיננסים מבוזרים, משחקים ולוגיסטיקה לפרוס רשתות אופטימליות משלהם מבלי לבנות בלוקצ'יין מאפס , תוך מינוף כלים, ערכות SDK ומסגרות פיתוח המסופקות על ידי הרשתות העיקריות.
איך רשתות אפליקציות עובדות מבפנים
מבחינה טכנית, רשת אפליקציות (appchain) חולקת את הבסיס של כל בלוקצ'יין (בלוקים, צמתים, קונצנזוס, קריפטוגרפיה), אך מתאימה את המבנה הכללי הזה לצורכי האפליקציה . לא כל רשתות האפליקציות בנויות באותו אופן, למרות שהן בדרך כלל מסתמכות על ארכיטקטורה שכבתית דומה למדי.
ביישומים רבים אנו יכולים להבחין בין לפחות חמש שכבות מפתח ב-appchain , לכל אחת תפקיד מוגדר היטב בתוך המערכת.
שכבת רשת : שכבה זו אחראית על כל תקשורת עמית לעמית בין צמתים, חילופי הודעות והפצת בלוקים ועסקאות. היא מנהלת את האופן שבו צמתים מתחברים זה לזה, כיצד מידע מועבר וכיצד נתונים הנמצאים ברשת עוברים אימות ראשוני, בנוסף לטיפול בבעיות ברשתות IP ו-DNS.
שכבת יישומים : כאן נמצאים אפליקציות DApp. שכבה זו מספקת ממשקים וממשקי API למפתחים, ניהול לוגיקת יישומים ברמה גבוהה, ניטור לוחות מחוונים וכלים לפריסת עדכונים או גרסאות חוזים חדשות.
שכבת נתונים : שכבה זו מטפלת באופן שבו נתונים מאוחסנים ומאורגנים בשרשרת האפליקציות. זה כולל את המצב הכללי של השרשרת, היסטוריית עסקאות ומידע הקשור לחוזים חכמים . העיצוב שלה משפיע על הביצועים, גודל השרשרת ויעילות הקריאה/כתיבה.
שכבת קונצנזוס : זהו לב ליבה של אבטחת רשת האפליקציות. הוא מגדיר את המנגנון המשמש להסכמה על איזה בלוק תקף (PoW, PoS, גרסאות BFT וכו'), כיצד נבחרים מאמתים, אילו תמריצים הם מקבלים ואילו עונשים הם סופגים אם הם פועלים בחוסר יושר.
שכבת חוזים חכמים : שכבה זו מספקת את סביבת זמן הריצה שבה נפרסים, מאומתים ומבוצעים חוזים חכמים . היא קובעת את שפת התכנות הנתמכת, את מודל הגז או העמלה, וכיצד לתקשר עם מודולים אחרים בשרשרת.
היופי של רשתות אפליקציות טמון בעובדה שכל אחת מהשכבות הללו ניתנת להתאמה או מודולריזציה בהתאם למקרה השימוש . פרויקט DeFi ידרוש תכונות אבטחה מסוימות והשלמה מהירה; משחק בלוקצ'יין עשוי לתת עדיפות להשהייה מינימלית (ראה אופטימיזציה של השהיית אינטרנט ) ועלויות נמוכות מאוד על פני ביזור קיצוני.
רשתות אפליקציות, רשתות ראשיות ורשתות צד: במה הן שונות
חשוב להבהיר נקודה מרכזית אחת: לא כל השרשראות הפועלות במקביל לרשת ראשית הן רשתות אפליקציות . כאן המונח מתבלבל לעתים קרובות עם רשתות צד, מה שמוביל לבלבול.
בלוקצ'יין שכבה 1 היא רשת בסיס רב-תכליתית: יש לה סט שלם משלה של מאמתים, מנגנוני קונצנזוס וכללים, ועליה נבנים יישומים שונים. ביטקוין, את'ריום וסולאנה הן דוגמאות קלאסיות לבלוקצ'יין שכבה 1.
לעומת זאת, רשתות אפליקציות (Appchains) מתוכננות לשרת יישום או תחום ספציפי . הארכיטקטורה שלהן גמישה הרבה יותר: הן יכולות להתחבר לשכבה 1 כדי לרשת אבטחה, לשתף מרכז קונצנזוס עם רשתות אחרות, או אפילו להשתמש בגשרים ספציפיים כדי להתחבר למערכת האקולוגית הראשית.
בנוגע למנגנוני קונצנזוס, בלוקצ'יין שכבה 1 נוטים לשמור על מודל סטנדרטי נוקשה יחסית (PoW, PoS) כדי לשמר יציבות ופשטות. עם זאת, רשתות אפליקציות יכולות להתנסות במנגנוני קונצנזוס המותאמים לשימושן: החל מגרסאות PoS במהירות גבוהה עבור DeFi ועד לתכניות BFT קלות משקל עבור יישומים לוגיסטיים.
מה לגבי שרשראות צד? גם שרשראות צד וגם שרשראות אפליקציות יכולות להתחבר לשרשרת ראשית ולהעביר נכסים ביניהן , אך שרשראות צד הן בדרך כלל רב-שימושיות: הן משמשות להורדת עומס עבודה מרשת הבסיס, הוספת פונקציונליות חדשה או בדיקת שיפורים, מבלי להצטרך להיות כל כך ממוקדים באפליקציה אחת.
לעומת זאת, רשת אפליקציות (appchain) נולדת עם מטרה מוגדרת מאוד: היא מתוכננת סביב אפליקציה, עם פרמטרי רשת, טוקונומיקס וממשל המותאמים לשימוש זה . התמחות זו היא שעושה את ההבדל, אם כי ברמה הטכנית היא יכולה למנף מושגים דומים לרשתות צד.
רכיבים עיקריים: שרשרת ראשית, שרשרת אפליקציות וגשר דו-כיווני
בעיצובים רבים, אפליקציה אינה חיה בבידוד, אלא חלק ממערכת אקולוגית גדולה יותר המורכבת משלושה חלקים עיקריים : השרשרת הראשית (או הרכזת), האפליקציה עצמה, ומנגנון עיגון או גשר דו-כיווני.
השרשרת הראשית משמשת כשכבת בסיס האחראית על האבטחה הכוללת, ובמקרים רבים, על קונצנזוס משותף. נקודות ביקורת, הודעות בקרה ומצבי שרשרת אפליקציות מצטברים נרשמים שם כדי לחזק את האבטחה ולהקל על יכולת פעולה הדדית.
שרשרת האפליקציות היא שרשרת ייעודית, עם כללים משלה, לוגיקת אפליקציות, ולעתים קרובות גם טוקן, מודל ממשל ומדיניות כלכלית משלה . היא יכולה לפעול באופן עצמאי למדי, כל עוד היא דבקה בפרוטוקולי התקשורת שסוכמו עם הרשת הראשית.
הגשר או העוגן הדו-כיווני הם מה שמאפשר להעביר נכסים ומידע בין הרשת הראשית לשרשרת האפליקציות. הוא מיושם בדרך כלל באמצעות חוזי נעילה בשרשרת הבסיס וייצוגים אסימוניים בשרשרת האפליקציות, או באמצעות פרוטוקולי העברת הודעות המאפשרים אימות, ללא אמון עיוור, שנכס ננעל בצד אחד לפני שהונפק בצד השני.
מנגנון זה מבטיח שלא יאבדו ערך או אבטחה בעת מעבר בין שרשראות . במקביל, הוא מאפשר ביקורת של מה שקורה בשרשרת האפליקציות דרך שכבת הבסיס על ידי ניתוח יומני רישום , גילוי התנהגות זדונית או חוסר עקביות, ובכך מספק שכבת הגנה נוספת למערכת.
יתרונות של רשתות אפליקציות: מדוע כל כך הרבה עניין
הסיבה לכך שרשתות אפליקציות הפכו כל כך פופולריות היא שהן פותרות כמה מצווארי הבקבוק העיקריים של רשתות בלוקצ'יין מסורתיות , במיוחד כשמדובר באירוח יישומים רבים ושונים באותה רשת.
ראשית, ישנה יכולת הרחבה וביצועים . על ידי הקדשת בלוקצ'יין שלם לאפליקציה או תחום יחיד, אתם מגדילים את מספר העסקאות שניתן לעבד מבלי להתחרות עם אפליקציות DApp אחרות על שטח בלוקים. זה מתורגם לזמני אישור קצרים יותר ולזמן השהייה צפוי הרבה יותר עבור המשתמש הסופי.
שנית, רשתות אפליקציות מעדיפות ארכיטקטורה מודולרית וגמישה . כל פרויקט יכול לבחור את סוג מנגנון הקונצנזוס, את מודל העמלות, את כללי הממשל ברשת, את סכמת ההרשאות (פתוחה יותר או סגורה יותר), ואפילו את שפת החוזים החכמים. זה שובר את הגישה המונוליטית הקלאסית של "רשת אחת, סט אחד של כללים לכולם".
נקודה מרכזית נוספת היא יכולת פעולה הדדית משופרת . רשתות אפליקציות (Appchains) נולדות בדרך כלל עם מנגנונים שנועדו לתקשר זה עם זה בתוך אותה מערכת אקולוגית (לדוגמה, דרך IBC ב-Cosmos או דרך Relay Chain ב-Polkadot), מה שמאפשר למשתמשים לעבור מאפליקציה אחת לאחרת ללא חיכוכים ולנצל סינרגיות בין שירותים.
לבסוף, מנקודת מבט של מפתח ועסקי, יצירת רשת אפליקציות משלך פירושה היכולת להתאים ביצועים טכניים לתמריצים כלכליים . ניתן להגדיר טוקונומיקה ספציפית, מודלי תמחור, תגמולים לאימות וממשל המותאמים לקהילה הספציפית הזו, מבלי להיות תלויים בתכנון הכלכלי של שכבה 1 גנרית.
אמצעי אבטחה ותפקיד הבלוקצ'יין ברשתות אפליקציות
רק בגלל שרשת אפליקציות היא יותר מיוחדת, זה לא אומר שהיא צריכה להיות פחות מאובטחת. למעשה, העיצוב שלה מבוסס בדרך כלל על אותם מאפיינים בסיסיים של טכנולוגיית הבלוקצ'יין : ביזור, אי-יכולת שינוי וקריפטוגרפיה חזקה.
הרשת הראשית (כאשר היא קיימת) משמשת כעוגן אבטחה וכשכבת ביקורת . ניתן להקליט שם סיכומי מצב, גיבובי בלוקים והודעות אימות, מה שמאפשר זיהוי של ניסיונות ארגון מחדש או התקפות על שרשרת האפליקציות. משמעות הדבר היא שתוקף יצטרך גם לפגוע בשכבת הבסיס כדי להצליח, מה שמגדיל באופן דרסטי את עלות ההתקפה.
בתוך שרשרת האפליקציות, אלגוריתמים של קונצנזוס הם קו ההגנה הראשון. באמצעות מנגנונים כמו Proof-of-Stake (PoS), עיבוד עסקאות בלוק (BFT) או מערכות היברידיות אחרות, צמתים חייבים להסכים אילו בלוקים תקפים ואילו עסקאות מתקבלות . תמריצים כלכליים, עונשים (slashing) וכללי השתתפות הם המפתח להרתעת התנהגות זדונית.
בנוסף לקונצנזוס, רשתות אפליקציות משתמשות בהצפנה כדי להגן על סודיות ושלמות הנתונים , בטכניקות חתימה דיגיטלית לאימות עסקאות, וביקורות חוזים חכמים כדי למזער פגיעויות קוד. רשתות רבות דורשות ביקורות חיצוניות לפני פריסת חוזים קריטיים ועמידה בשיטות עבודה מומלצות בפיתוח אבטחת תוכנה.
השקיפות הטבועה בבלוקצ'יין גם משפרת את האבטחה: הכל מתועד וניתן לעקוב אחריו . כל משתמש או גוף רגולטורי יכולים לעיין בהיסטוריית העסקאות, דבר הרלוונטי במיוחד במגזרים שבהם עקיבות ואחריותיות הם בסיסיים, כגון פיננסים או ניהול שרשרת אספקה.
מערכות אקולוגיות של אפליקציות: פולקדוט, קוסמוס ואוואלנש
מספר פרויקטים אימצו באופן מלא מודל המתמקד ברשתות אפליקציות, והציעו כלים ומסגרות עבור אחרים לבנות על התשתית שלהם. שלושה מהבולטים שבהם הם Polkadot, Cosmos ו-Avalanche.
במקרה של Polkadot , הרשת מאורגנת סביב שרשרת ממסר המספקת אבטחה וקונצנזוס משותף. לשרשרת ממסר זו מחוברים מצנחים , שהם בלוקצ'יין עצמאיים עם לוגיקה, טוקן וממשל משלהם. מצנחים אלה פועלים במקביל, מתקשרים זה עם זה באמצעות הודעות ונהנים מאבטחת שרשרת הממסר מבלי שיהיה צורך לבנות אותה מאפס.
קוסמוס , מצידה, מגדירה את עצמה כ"אינטרנט של בלוקצ'יין". היא משתמשת ב- SDK של קוסמוס כדי לאפשר למפתחים ליצור שרשראות מותאמות אישית משלהם, הנקראות אזורים . כל אזור הוא רשת אפליקציות עצמאית שיכולה להתחבר ל- Cosmos Hub ולאזורים אחרים באמצעות פרוטוקול התקשורת הבין-בלוקצ'יין (IBC), מה שמקל על העברות נתונים ונכסים מקוריים.
ב- Avalanche , הגישה מבוססת על תת-רשתות . תת-רשת היא קבוצה של מאמתים הפועלים כקבוצה האחראית על אבטחת בלוקצ'יין אחד או יותר. זה מאפשר לכל רשת אפליקציות להגדיר את הכללים שלה, החל מסוג הקונצנזוס ועד לדרישות החומרה וסמכות השיפוט של המאמתים, תוך מינוף הביצועים הגבוהים והשהייה הנמוכה של מנוע Avalanche.
מערכות אקולוגיות אלו מקלות מאוד על החיים עבור כל מי שרוצה להשיק רשת אפליקציות: הן מספקות תבניות, ערכות SDK, תיעוד וקהילה קיימת , מה שמפחית את המורכבות של יצירת בלוקצ'יין מאפס ומשפר את אפשרויות יכולת הפעולה ההדדית מהיום הראשון.
מקרי השימוש החשובים ביותר של רשתות אפליקציות
הרבגוניות של רשתות אפליקציות הופכת אותן למתאימות למגוון רחב של תעשיות וסוגי יישומים . חלק ממקרי השימוש הנפוצים ביותר מייצגים במיוחד את הפוטנציאל של מודל זה.
במימון מבוזר (DeFi) , רשתות אפליקציות מאפשרות תכנון של רשתות אופטימליות עבור מסחר, הלוואות, נגזרים או שווקי נזילות בעלי ביצועים גבוהים. על ידי העברת פעולות אלו לרשת אפליקציות ייעודית, עמלות מופחתות, צווארי בקבוק ברשתות כלליות נמנעים, וניתן ליישם כללי סיכון ספציפיים לפרוטוקול .
בתחום משחקי הבלוקצ'יין , הצורך לטפל באלפי עסקאות קטנות (רכישות בתוך המשחק, העברות נכסים, תגמולים) הופך שרשרת אפליקציות לשימושית במיוחד. השהייה נמוכה, עמלות מינימליות וחוויית משתמש חלקה הם בעלי חשיבות עליונה כאן - היבטים ששרשרת משותפת ועמוסה קשה להבטיח.
עבור רשתות חברתיות מבוזרות , רשת אפליקציות פותחת את הדלת למודלים של ממשל משתף יותר, ניהול קהילתי ובעלות אמיתית של המשתמש על נתונים . היא גם מאפשרת הגדרה של הרשאות ורמות פרטיות שונות מאלה של שכבה ציבורית 1 סטנדרטית.
בניהול שרשרת אספקה , ניתן להתאים אפליקציות לתיעוד אירועים לוגיסטיים, שינויים במשמורת, אישורים או בקרות איכות לאורך כל התהליך. זה מספק מעקב אחר מוצרים מפורט ביותר, מפחית הונאות ומשפר את השקיפות עבור יצרנים, מפיצים וצרכנים.
מעבר לתחומים אנכיים אלה, ישנם מקרים מתעוררים בזהויות דיגיטליות, הצבעה אלקטרונית, ניהול נתונים רפואיים או תשתיות IoT, שבהם בלוקצ'יין המותאם לצורכי המגזר עושה הבדל גדול בהשוואה לשימוש ברשתות גנריות.
אתגרים וחסרונות פוטנציאליים של רשתות אפליקציות
לא הכל שמש וורדים. רשתות אפליקציות מגיעות גם עם מספר אתגרים טכניים, רגולטוריים ואימוץ שיש לקחת בחשבון לפני השקתן.
מבחינה טכנית, יישום ותחזוקה של רשת אפליקציות דורשים ידע מתקדם בפיתוח בלוקצ'יין, אבטחה, רשתות מבוזרות וקריפטוגרפיה . לא מספיק רק לכתוב חוזה חכם: צריך להגדיר צמתים, לתכנן מנגנוני קונצנזוס, לתכנן שדרוגים ולהבטיח תשתית יציבה בטווח הארוך.
יתר על כן, כל שרשרת אפליקציות חדשה מוסיפה מורכבות למערכת האקולוגית הגלובלית: יש לתאם שרשראות מרובות, להבטיח יכולת פעולה הדדית חלקה ולתחזק גשרים מאובטחים . כל שגיאה ברכיבי ביניים אלה (גשרים, אורקלים, פרוטוקולי העברת הודעות) הופכת לווקטור תקיפה פוטנציאלי.
מנקודת מבט רגולטורית, רשתות אפליקציות מעלות שאלות דומות לאלו של פתרונות בלוקצ'יין אחרים, אך עם כמה ניואנסים. הרגולטורים עדיין מסתגלים לקצב החדשנות של המגזר , ודרישות משפטיות יכולות להשתנות באופן משמעותי בין תחומי שיפוט. פרויקטים המנפיקים טוקנים, מנהלים נכסים פיננסיים או מאחסנים נתונים רגישים חייבים לשים לב במיוחד לתאימות לתקנות.
לבסוף, ישנו אתגר האימוץ. למרות שרשתות אפליקציות מציעות יתרונות ברורים, משתמשים ועסקים רבים עדיין אינם מכירים את המושג . יש צורך בחינוך, סיפורי הצלחה ושיתוף פעולה בין פרויקטים כדי להדגים את ערכם האמיתי ולמנוע מהם להיתפס כעוד גחמה חולפת בעולם הקריפטו.
שאלות נפוצות על רשתות אפליקציות
מהי בעצם רשת אפליקציות? זוהי בלוקצ'יין שתוכנן ומוגדר כדי לענות על הצרכים של יישום או מקרה שימוש ספציפי מאוד. היא פועלת באופן עצמאי אך בדרך כלל מתחברת לרשת ראשית או לשרשראות אחרות כדי לרשת אבטחה ויכולת פעולה הדדית.
כיצד פועלת רשת אפליקציות ביחס לרשת הראשית? עסקאות מעובדות ומאומתות בתוך רשת האפליקציות, באמצעות קבוצת צמתים ומנגנון קונצנזוס משלה. לאחר מכן, ניתן לעגן מידע רלוונטי מסוים (כגון מצבים או הודעות מצטברים) לרשת הראשית , מה שמספק אבטחה נוספת ומאפשר תנועת נכסים בין השתיים.
אילו יתרונות מציעה שימוש ברשתות אפליקציות בהשוואה לרשתות כלליות? בעיקר, יעילות רבה יותר, גמישות, התאמה אישית ויכולת פעולה הדדית . בכך שהיא אינה חולקת משאבים עם אלפי יישומים שונים, רשת אפליקציות יכולה להציע עמלות נמוכות יותר, עסקאות מהירות יותר וכללים המתאימים יותר לשימוש המיועד שלה.
מהם החסרונות המשמעותיים ביותר? הבעיה העיקרית היא המורכבות הטכנית והתפעולית : תכנון, השקה ותחזוקה של שרשרת אפליקציות אינם עניין של מה בכך. לכך מתווספים סיכונים בגשרים בין שרשראות, אי ודאות רגולטורית והצורך למשוך מספיק משתמשים ומאמתים כדי להפוך את הפרויקט לבר קיימא.
האם לרשתות אפליקציות יש עתיד? הכל מצביע על כך שכן. ככל שמערכת האקולוגית של הבלוקצ'יין מתבגרת, הגיוני להפריד תשתיות לפי סוג האפליקציה , בדיוק כפי שבעולם המסורתי אותו שרת לא משמש להכל. עם כלים משופרים, סטנדרטים של יכולת פעולה הדדית ומסגרות רגולטוריות, לרשתות אפליקציות יש סיכוי חזק להפוך למרכיב מפתח בנוף Web3.
במבט על התמונה המלאה, רשתות אפליקציות ממצבות את עצמן כגשר בין הגמישות הנדרשת על ידי יישומים מודרניים לבין המגבלות של בלוקצ'יין לשימוש כללי . הן מציעות מגרש משחקים שבו ניתן להרחיב, להתאים אישית ולנסות מבלי לוותר על האבטחה ויכולת הפעולה ההדדית שמספקת מערכת אקולוגית רחבה יותר, מה שהופך אותן לאחד הנתיבים האבולוציוניים המעניינים ביותר בתוך יקום הבלוקצ'יין.

