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

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

שלבים של בקשת שירות על ידי לקוח בלוקצ'יין

כדי לדבר בכנות על האיכות של כל שירות מורכב יותר או פחות, צריך לקחת בחשבון לא רק ערכים ממוצעים, אלא גם מקסימום/מינימום, חציונים, אחוזונים. תיאורטית, אנחנו יכולים לדבר על 1000 tps בבלוקצ'יין כלשהו, ​​אבל אם 900 עסקאות הושלמו במהירות עצומה, ו-100 "נתקעו" לכמה שניות, אז הזמן הממוצע שנאסף על כל העסקאות אינו מדד הוגן לחלוטין עבור לקוח שלא הצלחתי להשלים את העסקה תוך כמה שניות. "חורים" זמניים הנגרמים מסיבובי קונצנזוס שהוחמצו או פיצולי רשת יכולים להרוס מאוד שירות שהציג ביצועים מצוינים על ספסלי בדיקה.

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

1. העסקה נוצרת על הלקוח
2. העסקה נחתמת על הלקוח
3. הלקוח בוחר באחד מהצמתים ושולח אליו את העסקה שלו
4. הלקוח נרשם לעדכונים במסד הנתונים של המצב של הצומת, ממתין להופעת תוצאות העסקה שלו
5. הצומת מפיץ את העסקה ברשת p2p
6. כמה או אחד BP (מפיק בלוק) מעבד עסקאות מצטברות, מעדכן את מסד הנתונים של המדינה
7. BP יוצר בלוק חדש לאחר עיבוד מספר העסקאות הנדרש
8. BP מפיצה בלוק חדש ברשת p2p
9. הבלוק החדש נמסר לצומת שהלקוח ניגש אליו
10. צומת מעדכן מסד נתונים של מצב
11. הצומת רואה את העדכון לגבי הלקוח ושולח לו הודעת עסקה

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

הכנת עסקה בצד הלקוח

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

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

שליחת עסקה ומעקב אחר מצבה

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

בבלוקצ'יין הלקוח שולח עסקה לכל צומת בלוקצ'יין שהוא אוהב, ה-hash של העסקה לרוב ידוע ללקוח לפני השליחה, כך שכל מה שהוא צריך לעשות זה להשיג את החיבור ולאחר השידור לחכות שהבלוקצ'יין ישתנה מצבו, המאפשר את העסקה שלו. שימו לב שעל ידי מדידת "tps" תוכלו לקבל תוצאות שונות לחלוטין עבור שיטות שונות של חיבור לצומת בלוקצ'יין. זה יכול להיות HTTP RPC רגיל או WebSocket המאפשר לך ליישם את דפוס ה"הירשם". במקרה השני, הלקוח יקבל הודעה מוקדם יותר, והצומת יוציא פחות משאבים (בעיקר זיכרון ותעבורה) בתגובות לגבי מצב העסקה. אז כאשר מודדים "tps" יש צורך לקחת בחשבון את הדרך שבה לקוחות מתחברים לצמתים. לכן, כדי להעריך את הסיכונים של צוואר בקבוק זה, הבנצ'מרק בלוקצ'יין חייב להיות מסוגל לחקות לקוחות עם בקשות WebSocket ו-HTTP RPC, בפרופורציות התואמות לרשתות אמיתיות, כמו גם לשנות את אופי העסקאות וגודלן.

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

העברת עסקאות וחסימות דרך רשת p2p

ב-blockchains, רשת peer-to-peer (p2p) משמשת להעברת עסקאות וחסימות בין משתתפים. עסקאות מפוזרות ברחבי הרשת, החל מאחד הצמתים, עד שהן מגיעות ליצרני בלוק עמית, אשר אורזים עסקאות לבלוקים ובאמצעות אותו p2p, מפיצים בלוקים חדשים לכל צמתי הרשת. הבסיס של רוב רשתות ה-p2p המודרניות הוא שינויים שונים בפרוטוקול Kademlia. כאן סיכום טוב של פרוטוקול זה, ו כאן - מאמר עם מדידות שונות ברשת BitTorrent, ממנו ניתן להבין שרשת מסוג זה מורכבת יותר ופחות צפויה מרשת קשיחה של שירות מרכזי. גַם, כאן מאמר על מדידת מדדים מעניינים שונים עבור צמתי Ethereum.

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

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

עיבוד בלוקצ'יין ועדכון מסד נתונים של המדינה

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

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

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

קבלת הודעה על ידי הלקוח על הכללת עסקה בבלוקצ'יין

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

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

מסקנה

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

1. טרנספורמציות קריפטוגרפיות, בניית הוכחה
2. רשת עמית לעמית, עסקאות ושכפול בלוק
3. עיבוד עסקאות, ביצוע חוזים חכמים
4. החלת שינויים בבלוקצ'יין על מסד הנתונים של המדינה, עדכון נתונים על עסקאות וחסימות
5. בקשות לקריאה בלבד למסד נתונים מדינה, API של צומת blockchain, שירותי מנוי

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

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

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

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

מקור: www.habr.com