בדיקה ציבורית: פתרון לפרטיות ומדרגיות ב-Ethereum

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

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

כדי להבטיח ביזור, אבטחה ומדרגיות בבלוקצ'יין, ובכך לפתור את ה-Scalability Trilemma, צוות הפיתוח הזדמנות יצרה את Plasma Cash, רשת בת המורכבת מחוזה חכם ורשת פרטית המבוססת על Node.js, המעבירה מעת לעת את מצבה לשרשרת השורש (Ethereum).

תהליכי מפתח בפלזמה קאש

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

2. צמתי Plasma Cash המנויים לאירועי חוזים חכמים מקבלים אירוע על יצירת הפקדה ומוסיפים עסקה על יצירת אסימון למאגר.

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

4. צמתים שמקבלים את אירוע הגשת החסימה מתחילים להחיל את העסקאות שנוספו לבלוק.

5. בשלב מסוים, הבעלים (או שאינו הבעלים) של האסימון רוצה למשוך אותו מפלזמה קאש. לשם כך הוא קורא לפונקציה `startExit`, ומעביר לתוכה מידע על 2 העסקאות האחרונות על האסימון, אשר מאשרות שהוא הבעלים של האסימון. החוזה החכם, באמצעות ה-Hash של Merkle, בודק נוכחות של עסקאות בבלוקים ושולח את האסימון למשיכה, שתתרחש בעוד שבועיים.

6. אם פעולת משיכת האסימון התרחשה עם הפרות (האסימון הוצא לאחר תחילת הליך המשיכה או שהאסימון כבר היה של מישהו אחר לפני המשיכה), הבעלים של האסימון יכול להפריך את המשיכה תוך שבועיים.

הפרטיות מושגת בשתי דרכים

1. שרשרת השורש אינה יודעת דבר על העסקאות שנוצרות ומועברות בתוך השרשרת הבת. מידע על מי שהפקיד ומשך ETH מפלזמה קאש נשאר ציבורי.

2. שרשרת הילד מאפשרת עסקאות אנונימיות באמצעות zk-SNARKs.

ערימת טכנולוגיה

• NodeJS
• Redis
• אתריום
• מוצק

בדיקה

תוך כדי פיתוח Plasma Cash, בדקנו את מהירות המערכת והשגנו את התוצאות הבאות:

• עד 35 עסקאות בשנייה מתווספות למאגר;
• ניתן לאחסן עד 1 עסקאות בבלוק.

בדיקות בוצעו ב-3 השרתים הבאים:

1. Intel Core i7-6700 Quad-Core Skylake כולל. NVMe SSD - 512 GB, 64 GB DDR4 RAM
הועלו 3 צמתים מאמתים של פלזמה קאש.

2. AMD Ryzen 7 1700X Octa-Core "Summit Ridge" (זן), SATA SSD - 500 GB, 64 GB DDR4 RAM
צומת ETH של Ropsten testnet הועלה.
הועלו 3 צמתים מאמתים של פלזמה קאש.

3. Intel Core i9-9900K Octa-Core כולל. NVMe SSD - 1 TB, 64 GB DDR4 RAM
צומת הגשת פלזמה מזומן הועלה.
הועלו 3 צמתים מאמתים של פלזמה קאש.
הושקה בדיקה להוספת עסקאות לרשת Plasma Cash.

סך הכל: 10 צמתי Plasma Cash ברשת פרטית.

מבחן 1

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

מצב התחלתי: בלוק אחרון #7; מיליון עסקאות ואסימונים מאוחסנים במסד הנתונים.

00:00 - תחילת תסריט יצירת העסקה
01:37 - 1 מיליון עסקאות נוצרו והחלה השליחה לצומת
01:46 - צומת ההגשה לקח 240 עסקאות מהמאגר והטפסים בלוק מס' 8. אנו רואים גם ש-320 אלף עסקאות מתווספות למאגר תוך 10 שניות
01:58 - בלוק מס' 8 נחתם ונשלח לאימות
02:03 - בלוק מס' 8 מאומת ופונקציית 'submitBlock' של החוזה החכם נקראת עם ה-Hash של Merkle ומספר החסימה
02:10 - סקריפט הדגמה סיים לעבוד, ששלח מיליון עסקאות ב-1 שניות
02:33 - צמתים החלו לקבל מידע שבלוק #8 נוסף לשרשרת השורש, והחלו לבצע 240 עסקאות
02:40 - 240 אלף עסקאות הוסרו מהמאגר, שכבר נמצאות בבלוק מס' 8
02:56 - צומת הגשה לקח את 760 העסקאות הנותרות מהמאגר והחל לחשב את ה-Hash של Merkle ובלוק החתימה מס' 9
03:20 - כל הצמתים מכילים מיליון 1 אלף עסקאות ואסימונים
03:35 - בלוק מס' 9 נחתם ונשלח לאימות לצמתים אחרים
03:41 - אירעה שגיאת רשת
04:40 - תם הזמן הקצוב להמתנה לאימות בלוק מס' 9
04:54 - צומת הגשה לקח את 760 העסקאות הנותרות מהמאגר והחל לחשב את ה-Hash של Merkle ובלוק החתימה מס' 9
05:32 - בלוק מס' 9 נחתם ונשלח לאימות לצמתים אחרים
05:53 - בלוק מס' 9 מאומת ונשלח לשרשרת השורש
06:17 - צמתים החלו לקבל מידע שבלוק מס' 9 נוסף לשרשרת השורש והתחיל לבצע 760 עסקאות
06:47 - המאגר פינה עסקאות שנמצאות בבלוק מס' 9
09:06 - כל הצמתים מכילים 2 מיליון עסקאות ואסימונים

מבחן 2

יש הגבלה של 350 אלף לבלוק. כתוצאה מכך, יש לנו 3 בלוקים.

מצב התחלתי: בלוק אחרון #9; 2 מיליון עסקאות ואסימונים מאוחסנים במסד הנתונים

00:00 - סקריפט ליצירת עסקאות כבר הושק
00:44 - 1 מיליון עסקאות נוצרו והחלה השליחה לצומת
00:56 - צומת ההגשה לקח 320 עסקאות מהמאגר והטפסים בלוק מס' 10. אנו רואים גם ש-320 אלף עסקאות מתווספות למאגר תוך 10 שניות
01:12 - בלוק מס' 10 נחתם ונשלח לצמתים אחרים לצורך אימות
01:18 - סקריפט הדגמה סיים לעבוד, ששלח מיליון עסקאות ב-1 שניות
01:20 - בלוק מס' 10 מאומת ונשלח לשרשרת השורש
01:51 - כל הצמתים קיבלו מידע משרשרת השורש שבלוק מס' 10 נוסף ומתחילים להחיל 320 עסקאות
02:01 - המאגר פינה עבור 320 עסקאות שנוספו לבלוק מס' 10
02:15 - צומת ההגשה לקח 350 עסקאות מהמאגר והטפסים בלוק מס' 11
02:34 - בלוק מס' 11 נחתם ונשלח לצמתים אחרים לצורך אימות
02:51 - בלוק מס' 11 מאומת ונשלח לשרשרת השורש
02:55 - הצומת האחרון השלים עסקאות מבלוק מס' 10
10:59 — העסקה עם הגשת בלוק מס' 9 ארכה זמן רב מאוד בשרשרת השורש, אבל היא הושלמה וכל הצמתים קיבלו מידע עליה והחלו לבצע 350 אלף עסקאות
11:05 - המאגר פינה עבור 320 עסקאות שנוספו לבלוק מס' 11
12:10 - כל הצמתים מכילים מיליון 1 אלף עסקאות ואסימונים
12:17 - צומת ההגשה לקח 330 עסקאות מהמאגר והטפסים בלוק מס' 12
12:32 - בלוק מס' 12 נחתם ונשלח לצמתים אחרים לצורך אימות
12:39 - בלוק מס' 12 מאומת ונשלח לשרשרת השורש
13:44 - כל הצמתים קיבלו מידע משרשרת השורש שבלוק מס' 12 נוסף ומתחילים להחיל 330 עסקאות
14:50 - כל הצמתים מכילים 2 מיליון עסקאות ואסימונים

מבחן 3

בשרת הראשון והשני, צומת אימות אחד הוחלף בצומת הגשה.

מצב התחלתי: בלוק אחרון #84; 0 עסקאות ואסימונים נשמרו במסד הנתונים

00:00 - הושקו 3 סקריפטים שמייצרים ושולחים מיליון עסקאות כל אחד
01:38 - 1 מיליון עסקאות נוצרו והשליחה לצומת מס' 3 החלה
01:50 — צומת הגשה מס' 3 לקח 330 עסקאות מהמאגר והטפסים בלוק מס' 85 (f21). אנו רואים גם ש-350 עסקאות מתווספות למאגר תוך 10 שניות
01:53 - 1 מיליון עסקאות נוצרו והשליחה לצומת מס' 1 החלה
01:50 — צומת הגשה מס' 3 לקח 330 עסקאות מהמאגר והטפסים בלוק מס' 85 (f21). אנו רואים גם ש-350 עסקאות מתווספות למאגר תוך 10 שניות
02:01 — צומת הגשה מס' 1 לקח 250 עסקאות מהמאגר ובלוק טפסים מס' 85 (65e)
02:06 - בלוק #85 (f21) נחתם ונשלח לצמתים אחרים לצורך אימות
02:08 - סקריפט הדגמה של שרת מס' 3, ששלח מיליון עסקאות תוך 1 שניות, סיים לעבוד
02:14 - בלוק #85 (f21) מאומת ונשלח לשרשרת השורש
02:19 - בלוק #85 (65e) נחתם ונשלח לצמתים אחרים לצורך אימות
02:22 - 1 מיליון עסקאות נוצרו והשליחה לצומת מס' 2 החלה
02:27 - בלוק #85 (65e) אומת ונשלח לשרשרת השורש
02:29 — צומת הגשה מס' 2 לקח 111855 עסקאות מהמאגר וטפסים בלוק מס' 85 (256).
02:36 - בלוק מס' 85 (256) נחתם ונשלח לצמתים אחרים לצורך אימות
02:36 - סקריפט הדגמה של שרת מס' 1, ששלח מיליון עסקאות תוך 1 שניות, סיים לעבוד
02:38 - בלוק מס' 85 (256) מאומת ונשלח לשרשרת השורש
03:08 - סקריפט מס' 2 של שרת סיים לעבוד, ששלח מיליון עסקאות תוך 1 שניות
03:38 - כל הצמתים קיבלו מידע משרשרת השורש שחסימות #85 (f21), #86(65e), #87(256) נוספו והחלו להחיל עסקאות 330k, 250k, 111855
03:49 - המאגר סולקה ב-330k, 250k, 111855 עסקאות שנוספו לבלוקים #85 (f21), #86(65e), #87(256)
03:59 — הגשת צומת מס' 1 לקחה 888145 עסקאות מהמאגר והטפסים בלוק מס' 88 (214), צומת ההגשה מס' 2 לקחה 750 עסקאות מהמאגר וטפסים בלוק מס' 88 (50a), צומת הגשה מס' 3 לקחה 670 עסקאות מ בלוק המאגר והטפסים #88 (d3b)
04:44 - בלוק מס' 88 (d3b) נחתם ונשלח לצמתים אחרים לצורך אימות
04:58 - בלוק מס' 88 (214) נחתם ונשלח לצמתים אחרים לצורך אימות
05:11 - בלוק #88 (50a) נחתם ונשלח לצמתים אחרים לצורך אימות
05:11 - בלוק #85 (d3b) מאומת ונשלח לשרשרת השורש
05:36 - בלוק מס' 85 (214) מאומת ונשלח לשרשרת השורש
05:43 - כל הצמתים קיבלו מידע משרשרת השורש שבלוקים #88 (d3b), #89(214) נוספו ומתחילים להחיל עסקאות של 670k, 750k
06:50 - עקב כשל בתקשורת, בלוק מס' 85 (50a) לא אומת
06:55 — צומת שלח מס' 2 לקח 888145 עסקאות מהמאגר והטפסים בלוק מס' 90 (50a)
08:14 - בלוק #90 (50a) נחתם ונשלח לצמתים אחרים לצורך אימות
09:04 - בלוק מס' 90 (50a) מאומת ונשלח לשרשרת השורש
11:23 - כל הצמתים קיבלו מידע משרשרת השורש שנוסף בלוק #90 (50a), ומתחילים להחיל 888145 טרנזקציות. במקביל, שרת מס' 3 כבר החיל טרנזקציות מבלוקים מס' 88 (d3b), מס' 89(214)
12:11 - כל הבריכות ריקות
13:41 - כל הצמתים של שרת מס' 3 מכילים 3 מיליון עסקאות ואסימונים
14:35 - כל הצמתים של שרת מס' 1 מכילים 3 מיליון עסקאות ואסימונים
19:24 - כל הצמתים של שרת מס' 2 מכילים 3 מיליון עסקאות ואסימונים

מכשולים

במהלך הפיתוח של Plasma Cash, נתקלנו בבעיות הבאות, אותן פתרנו בהדרגה ופותרות:

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

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

3. לא היה ברור איך ואיפה לאחסן נתונים על מנת להגיע לתוצאות גבוהות.

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

5. עבודה במצב חוט יחיד מנתקת את הקשר בין צמתים כאשר מתרחשים חישובים ארוכים (לדוגמה, בניית עץ מרקל וחישוב ה-hash שלו).

איך התמודדנו עם כל זה?

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

1. הפעל מספר תהליכי NodeJS, שכל אחד מהם מבצע פונקציות ספציפיות.

2. השתמש ב-worker_threads והעבר את הביצוע של חלק מהקוד לשרשורים.

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

1. צומת הגשה, שמקבל עסקאות לתוך המאגר ויוצר בלוקים.

2. צומת אימות שבודק את תקפות הצמתים.

3. צומת API - מספק API לגישה לנתונים.

במקרה זה, ניתן להתחבר לכל צומת באמצעות שקע יוניקס באמצעות cli.

העברנו פעולות כבדות, כמו חישוב עץ מרקל, לשרשור נפרד.

לפיכך, השגנו פעולה תקינה של כל פונקציות Plasma Cash בו זמנית וללא תקלות.

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

מלכתחילה, התחלנו לבדוק את מנגנון התקשורת עם Plasma Cash כדי לגלות את יכולת השיא של המערכת. כתבנו קודם שצומת Plasma Cash מספק ממשק שקע יוניקס. בתחילה זה היה מבוסס טקסט. אובייקטי json נשלחו באמצעות `JSON.parse()` ו-`JSON.stringify()`.

```json
{
  "action": "sendTransaction",
  "payload":{
    "prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
    "prevBlock": 41,
    "tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
    "newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
    "type": "pay",
    "data": "",
    "signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
  }
}
```

מדדנו את מהירות ההעברה של עצמים כאלה ומצאנו ~ 130k לשנייה. ניסינו להחליף את הפונקציות הסטנדרטיות לעבודה עם json, אך הביצועים לא השתפרו. מנוע ה-V8 חייב להיות מותאם היטב לפעולות אלו.

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

רישום במסד הנתונים

בתחילה, Redis נבחרה לאחסון נתונים כאחד הפתרונות הפרודוקטיביים ביותר שעונה על הדרישות שלנו: אחסון מפתח-ערך, עבודה עם טבלאות גיבוב, סטים. השקנו Redis-benchmark וקיבלנו ~80 פעולות בשנייה במצב צנרת 1.

לביצועים גבוהים, כיוונו את Redis בצורה עדינה יותר:

• נוצר חיבור לשקע יוניקס.
• השבתנו את שמירת המצב בדיסק (לצורך אמינות, ניתן להגדיר רפליקה ולשמור בדיסק ב-Redis נפרד).

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

בעת שימוש ב-NodeJS סטנדרטי, ספריות Redis השיגו ביצועים של 18 עסקאות בשנייה. המהירות ירדה פי 9.

מכיוון שהמדד הראה לנו שהאפשרויות היו גדולות בבירור פי 5, התחלנו לבצע אופטימיזציה. שינינו את הספרייה ל- ioredis וקיבלנו ביצועים של 25k לשנייה. הוספנו עסקאות אחת אחת באמצעות הפקודה `hset`. אז יצרנו הרבה שאילתות ברדיס. עלה הרעיון לשלב עסקאות לאצוות ולשלוח אותן בפקודה אחת `hmset`. התוצאה היא 32k לשנייה.

מכמה סיבות, אותן נתאר להלן, אנו עובדים עם נתונים באמצעות `Buffer` וכפי שמסתבר, אם תמיר אותם לטקסט (`buffer.toString('hex')`) לפני הכתיבה, תוכל לקבל עוד ביצועים. לפיכך, המהירות הוגדלה ל-35k לשנייה. נכון לעכשיו, החלטנו להשעות אופטימיזציה נוספת.

היינו צריכים לעבור לפרוטוקול בינארי כי:

1. המערכת לרוב מחשבת גיבוב, חתימות וכו', ולשם כך היא זקוקה לנתונים ב-`Buffer.

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

3. שינוי מתמיד של נתונים משפיע על הביצועים.

לכן, לקחנו כבסיס את הפרוטוקול הבינארי שלנו לאחסון והעברת נתונים, שפותח על בסיס ספריית `בינארי-נתונים` הנפלאה.

כתוצאה מכך, קיבלנו את מבני הנתונים הבאים:

-עִסקָה

  ```json
  {
    prevHash: BD.types.buffer(20),
    prevBlock: BD.types.uint24le,
    tokenId: BD.types.string(null),
    type: BD.types.uint8,
    newOwner: BD.types.buffer(20),
    dataLength: BD.types.uint24le,
    data: BD.types.buffer(({current}) => current.dataLength),
    signature: BD.types.buffer(65),
    hash: BD.types.buffer(32),
    blockNumber: BD.types.uint24le,
    timestamp: BD.types.uint48le,
  }
  ```

- אסימון

  ```json
  {
    id: BD.types.string(null),
    owner: BD.types.buffer(20),
    block: BD.types.uint24le,
    amount: BD.types.string(null),
  }
  ```

-לַחסוֹם

  ```json
  {
    number: BD.types.uint24le,
    merkleRootHash: BD.types.buffer(32),
    signature: BD.types.buffer(65),
    countTx: BD.types.uint24le,
    transactions: BD.types.array(Transaction.Protocol, ({current}) => current.countTx),
    timestamp: BD.types.uint48le,
  }
  ```

עם הפקודות הרגילות `BD.encode(block, Protocol).slice();` ו-`BD.decode(buffer, Protocol)` אנו ממירים את הנתונים ל`Buffer` לצורך שמירה ב-Redis או העברה לצומת אחר ואחזור ה- נתונים בחזרה.

יש לנו גם 2 פרוטוקולים בינאריים להעברת נתונים בין שירותים:

- פרוטוקול לאינטראקציה עם Plasma Node באמצעות שקע יוניקס

  ```json
  {
    type: BD.types.uint8,
    messageId: BD.types.uint24le,
    error: BD.types.uint8,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

שם:

• 'סוג' - הפעולה שיש לבצע, למשל, 1 - sendTransaction, 2 - getTransaction;
• `מטען` - נתונים שיש להעביר לפונקציה המתאימה;
• 'מזהה הודעה' - מזהה הודעה כדי שניתן יהיה לזהות את התגובה.

- פרוטוקול לאינטראקציה בין צמתים

  ```json
  {
    code: BD.types.uint8,
    versionProtocol: BD.types.uint24le,
    seq: BD.types.uint8,
    countChunk: BD.types.uint24le,
    chunkNumber: BD.types.uint24le,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

שם:

• `קוד` — קוד הודעה, למשל 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
• `versionProtocol` - גרסת פרוטוקול, מכיוון שניתן להעלות צמתים עם גרסאות שונות ברשת והם יכולים לעבוד אחרת;
• `seq` - מזהה הודעה;
• `countChunk` и `chunkNumber` הכרחי לפיצול הודעות גדולות;
• 'אורך' и `מטען` אורך והנתונים עצמם.

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

אם הצלחנו להגיע למהירות 35 000 עסקאות בשנייה, עלינו גם לעבד אותן בזמן האופטימלי. מכיוון שזמן יצירת הבלוק המשוער לוקח 30 שניות, עלינו לכלול בבלוק 1 000 000 עסקאות, כלומר לשלוח יותר 100 MB של נתונים.

בתחילה, השתמשנו בספריית `ethereumjs-devp2p` כדי לתקשר בין צמתים, אך היא לא יכלה להתמודד עם כל כך הרבה נתונים. כתוצאה מכך, השתמשנו בספריית `ws` והגדרנו שליחת נתונים בינאריים דרך websocket. כמובן שנתקלנו בבעיות גם בשליחת חבילות נתונים גדולות, אבל חילקנו אותן לנתחים וכעת הבעיות הללו נעלמו.

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

מסקנות:

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

• שימוש בתכנות פונקציונלי במקום תכנות מונחה עצמים משפר את הפרודוקטיביות.
• המונוליט גרוע יותר מארכיטקטורת שירות עבור מערכת NodeJS פרודוקטיבית.
• שימוש ב-worker_threads לחישוב כבד משפר את היענות המערכת, במיוחד כאשר עוסקים בפעולות I/O.
• שקע יוניקס יציב ומהיר יותר מבקשות http.
• אם אתה צריך להעביר נתונים גדולים במהירות דרך הרשת, עדיף להשתמש ב-websockets ולשלוח נתונים בינאריים, מחולקים לנתחים, אותם ניתן להעביר אם הם לא מגיעים, ואז לשלב אותם להודעה אחת.

אנו מזמינים אתכם לבקר GitHub פּרוֹיֶקט: https://github.com/opporty-com/Plasma-Cash/tree/new-version

המאמר נכתב בשיתוף אלכסנדר נשיבאן, מפתח בכיר Clever Solution Inc.

מקור: www.habr.com