פיתוח על Cosmos SDK: היכן שהאב־טיפוס אינו עומד בעומס
אב־הטיפוס של רשת אפליקציה נבנה בדרך כלל על כמה ולידטורים ועל זרימת עסקאות סינתטית. במצב כזה Cosmos SDK מפיק בלוקים יציבים ואישור צפוי מראש — ומייצר תחושה שכדי להגיע לרשת הראשית נותר רק להחליף קונפיגורציה. כשמספר הוולידטורים גדל והזרימה נעשית אמיתית, ההתנהגות משתנה באופן איכותי, לא כמותי.
צוואר הבקבוק הראשון — הקונסנזוס. סבב דורש חילופי הצעות והצבעות בין כל המשתתפים, ולכן עם גדילת מערך הוולידטורים זמן הסבב גדל ולא נשאר קבוע. הבלוקים מתמלאים עד הקצה, תור העסקאות אינו מתפנה בין בלוקים, השהיית האישור עוברת משניות לעשרות שניות, והעמלות נעשות בלתי צפויות עבור המשתמש.
השני — היעדר בידוד תקלות. מטפל כבד במודול אחד תופס את כל זמן הבלוק: שאר העסקאות ממתינות, המצב גדל, צמתים מפגרים אינם מספיקים להדביק.
אי־סנכרון גרסאות אצל חלק מהוולידטורים או שגיאה בלוגיקת המודול עוצרים את ייצור הבלוקים — השבתת הרשת מחייבת הפעלה מחדש מתואמת ופעולות ידניות של המפעילים.
השלישי — גבולות תפעוליים: גידול המצב, זמן הסנכרון של צומת חדש, היעדר תוכנית עדכון ללא השבתה. הדברים מתגלים כבר אחרי ההשקה, כשהקונפיגורציה קפואה. נבחן כיצד זה נסגר בשלב התכנון.
מה נותנת רשת ייעודית: עומס צפוי מראש ובידוד תקלות
רשת אפליקציה על Cosmos SDK היא בלוקצ'יין נפרד למשימה אחת, ולא מקטע בתוך רשת משותפת. המשאבים, הכללים וקצב העדכונים מותאמים לתרחיש מסוים, ולכן עומס שיא בשירות אחד אינו פוגע בשכנים. להלן ארבעה אפקטים שנראים בתפעול, לא במצגת.
בידוד תקלות
נפילת צומת או עומס יתר בשירות אחד עוצרים רק אותו: שאר הרשת ממשיכה לקלוט עסקאות, והשחזור מתבצע בהחלפת הצומת מתוך מערך מוכן. אנו מפרידים מסלולים קריטיים למערכי ולידטורים שונים, ולכן סוג התקלה «עומס יתר אחד — כל המוצר» נעלם.
תפוקה צפויה מראש
המקום בבלוק אינו מתחלק עם אפליקציות זרות, ולכן השהיית האישור מחושבת מראש. אנו קובעים מגבלת בלוק ועלות פעולות בהתאם לפרופיל העומס, מודדים את שיעור העסקאות הנדחות בשיא ושומרים אותו בסף מוסכם.
ולידטורים בלתי תלויים
אישור הבלוקים מפוזר בין ולידטורים בלתי תלויים: אין נקודה יחידה שיכולה לעצור את הרשת או לשכתב את ההיסטוריה בלי שזה ייראה. סף ההסכמה והרכב המערך נקבעים בקונפיגורציה — וזה גם הבסיס לביקורת ולדרישות הרגולטור.
זמן עדכון הרשת
עדכון הלוגיקה עובר דרך הצעת ממשל ומיושם בגובה בלוק מוסכם: לוח הזמנים נמדד בימים, לא ברבעונים, ואינו דורש השבתת הרשת. גם התרחיש ההפוך מתואר מראש — חזרה למצב הקודם לפי נוהל בדוק.
אפשרויות ארכיטקטורה לרשת: מבודדת, אפליקטיבית, משותפת
הארכיטקטורה קובעת מי משלם על העומס, כיצד מתעדכנת הלוגיקה ועד כמה הנכסים שלכם פתוחים. שלוש האפשרויות שלהלן אינן הפשטה אלא צמתי החלטה ממשיים בהשקת רשת על הענף העדכני של Cosmos SDK.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| רשת מבודדת | מסלול סגור: ניהול נכסים וסליקה בתוך מוצר אחד | חוזים חכמים חיצוניים אינם נגישים, אינטגרציות — רק דרך שער ייעודי |
| רשת אפליקציה | נדרשים לוגיקה, עמלות וסדר הכנסת עסקאות משלכם | ולידטורים, עדכונים וניטור נשארים בצד שלכם |
| רשת משותפת | התחלה מהירה, נזילות, כלים מוכנים | העסקאות חולקות תור משותף, הלוגיקה מוגבלת ליכולות החוזים החכמים |
קריטריונים לבחירה
מחשבים שלושה גדלים: עומס שיא, תדירות שינויי הכללים והצורך בחוזים חכמים חיצוניים. אם הכללים משתנים מדי חודש והוולידטורים אינם בשליטתכם, רשת משותפת חוסכת חודשים בהתחלה — במחיר של ניהול העמלות וסדר העסקאות.
מה לא כדאי להעביר לרשת שלכם
נתונים אישיים, מפתחות חתימה וחישובים כבדים נשארים מחוץ לבלוקצ'יין. אל המצב המשותף עובר רק מה שדורש תיאום בין המשתתפים: הרשאות, יתרות, תוצאות סליקה. את השאר זול ובטוח יותר להחזיק בתשתית רגילה.
שלבי הפיתוח: מתרשים הרשת ועד העברה לתפעול
פיתוח appchain אינו «לכתוב מודולים», אלא רצף שלבים שבו אנו מאמתים את התוצאה של כל שלב לפני המעבר לבא. להלן סדר העבודה שלפיו פועל הצוות שלנו: מניתוח הדרישות ועד העברת הרשת לתפעול יחד עם הכשרת הצוות שלכם.
סדר העבודה
- ניתוח דרישות. קובעים אילו פעולות באמת צריכות להתקיים בבלוקצ'יין, מי משמש ולידטור, אילו נתונים יוצאים למערכות חיצוניות. התוצר — רשימת מודולים וקריטריוני קבלה שלפיהם נמסור את הרשת בהמשך.
- תרשים הרשת. מתכננים את הטופולוגיה והתפקידים: צומתי ולידטורים, צמתים ארכיוניים וציבוריים, הרשאות גישה, גיבוי המצב. את התרשים מתאמים לפני שורת הקוד הראשונה — לשנות אותו מאוחר יותר יקר בהרבה.
- הגדרת מודולים. מרכיבים את האפליקציה ממודולים מוכנים וכותבים מודולים משלנו: פרמטרי ממשל, הרשאות לפעולות, לוגיקת עמלות. כל מה שיכול להשתנות מוציאים לממשל ולא לקוד.
- הרכבת רשת בדיקה. מרימים מסלול מקומי לאיטרציות מהירות ו-testnet ציבורי שבו התרחישים מורצים על ולידטורים אמיתיים. שגיאות קונפיגורציה נתפסות כאן, ולא ברשת הייצור.
- בדיקת עומס. מריצים פרופיל עסקאות הקרוב לזה הצפוי ובוחנים את ההתנהגות בשיא: זמן הכנסת בלוק, גידול המצב, פיגור צמתים והתאוששות לאחר הפעלה מחדש.
- העברה למצב ייצור ומסירה. משיקים בהדרגה — ממעגל מצומצם של ולידטורים ועד ההרכב המלא. מוסרים נוהלי עדכון ושחזור, מגדירים התראות ומכשירים את הצוות שלכם.
מה נשאר ללקוח: קונפיגורציות, תיעוד, נוהלים
החבילה בסיום אינה ארכיון של קוד מקור, אלא מערך של חפצי מסירה שלפיהם הצוות שלכם ממשיך לעבוד בלעדינו. אנו מוסרים אותם יחד עם הסבר: כל החלטה נדונה בשיחה ונרשמת הסיבה לכך שהפרמטר הוגדר דווקא כך.
- קונפיגורציות הרשת — קבצי התחלה, פרמטרי צמתים וערכים ששונו לעומת ברירת המחדל, עם הסבר מה יקרה אם יתוקנו.
- תרשים הרשת — הטופולוגיה של ולידטורים, צמתים מלאים וציבוריים, נקודות חיבור, אזורי כשל ונוהל השחזור בעת אובדן מקטע.
- תפקידים ומפתחות — מרשם: איזה מפתח למי שייך, היכן הוא נשמר, למי יש הרשאת חתימה וכיצד מתבצעת הרוטציה.
- מדיניות גישה — חלוקת הרשאות לפי עקרון המינימום ההכרחי, הפרדה בין מפתחות מנהל הרשת למפתחות האפליקציה, אחסון בחומרה של מפתחות קריטיים.
- נוהל עדכונים — מסלול השינוי מרשת הבדיקה לרשת הראשית: מי מכין, מי מצביע, חלון העבודה, קריטריונים לחזרה למצב הקודם.
- הוראות לצוות התורנות — מה לנטר, אילו ספים נחשבים מדאיגים, מה לעשות בעת עצירת בלוקים, אי־סנכרון צומת ונפילת שירות.
- תיעוד אינטגרציות — תיאור הממשקים החיצוניים, פורמטי הבקשות והמגבלות על העומס.
חפצי מסירה אלה הם קריטריון הקבלה: אם לפיהם מהנדס תורן יכול להרים את הרשת ולבצע עדכון בלעדינו, העבודה נמסרה. את העדכון המתוכנן הראשון עוברים יחד עם הצוות שלכם, ומכאן והלאה — לפי הנוהל.
מקרה בוחן: העברת רשת אפליקציה למצב ייצור בשתי איטרציות
מפעיל של רשת אפליקציות הגיע עם אב־טיפוס עובד על Cosmos SDK: במסלול הבדיקה הכול הסתדר, אך בזרימה אמיתית העסקאות הצטברו בתור והוולידטורים התפצלו בגובה הבלוקים. המשימה הוגדרה כך — לשמור על זמן התגובה, להפחית את שיעור העסקאות הנדחות ולהפוך את הרשת לעמידה בפני כשל של צומת בודד. להלן המדידות לפני ואחרי, ומה שהיה צריך לשנות בדרך.
מה הראו המדידות לפני ואחרי
בנקודת הפתיחה זמן אישור העסקה בשיא הגיע ל־12 שניות, נדחו 4–6% מהזרימה, ועצירה של ולידטור אחד עיכבה את העיבוד בדקות. הפרדנו בין לוגיקת האפליקציה לשכבת תיאום המצב, הוספנו עדיפויות לפעולות דחופות והגבלנו את צריכת המשאבים לעסקה אחת.
לאחר מדידה חוזרת זמן האישור הצטמצם פי שלושה, שיעור הנדחות ירד מתחת ל־0.5%, והוצאת צומת מהמערך הפעיל הפסיקה להשפיע על עיבוד הבקשות — בניית מערך הוולידטורים מחדש אורכת שניות במקום דקות.
מה שינו בדרך
האיטרציה הראשונה נשענה על סכמת אחסון מצב כללית: עם גידול מספר החשבונות הכתיבה החלה לעכב את הקריאה, וזה התגלה דווקא בשעות השיא. עבדנו מחדש את מודל המפתחות, הפרדנו נתונים חמים מארכיוניים והוספנו אינדקסים לשאילתות הנפוצות ביותר. את העברת המצב ביצענו שלב אחר שלב — בלי השבתת הרשת ובלי אובדן היסטוריית הפעולות.
מה לעשות אם חלק מהלוגיקה כבר פועל ברשת זרה?
תשובה קצרה: לעיתים נדירות יש צורך להעביר את כל הלוגיקה כולה. נקודת ההכרעה תלויה בכמה רחב הממשק של הלוגיקה שלכם עם הרשת הזרה — אם מדובר בקריאה אחת בכניסה, מועברת היא, ולא כל המוצר. להלן שלושה תרחישים שביניהם באמת בוחרים בהתחלה, ומה כל אחד מהם אומר לגבי תאימות המודולים והנתונים.
את התאימות בודקים בשני רבדים. רובד המודולים: האם הממשקים בין המודולים זהים, גרסאות הספריות בעץ התלויות של Cosmos SDK וסדר האתחול בעליית הרשת. רובד הנתונים: סכמת אחסון המצב, המפתחות, פורמט הסריאליזציה וקובץ הג'נסיס שממנו עולה הבלוקצ'יין החדש. פער כאן אינו שובר את הבנייה — הוא מניב מצב שונה לאחר ההשקה, וצף כבר בשלב ההשוואה.
| תרחיש | מתי מתאים | מגבלות |
|---|---|---|
| להשאיר כמו שזה | הלוגיקה עובדת, צריך רק מסלול חיצוני משלכם: ולידטורים, ערוץ תקשורת, כללי גישה | כללי העדכונים והעמלות של הרשת הזרה מחוץ לשליטתכם |
| סכמה היברידית | חלק מהמודולים בדוק ויציב, חלק דורש כללים משלו | יש לסנכרן שני מצבים, נדרשת שכבת אישור בין הרשתות |
| העברה מלאה | נדרשים כללי קונסנזוס משלכם והשקה עצמאית של הרשת | כל המודולים נכתבים מחדש, ובנוסף הגירת המצב המצטבר |
בפועל הולכים לעיתים קרובות יותר בסכמה היברידית: מעבירים מודול אחר מודול, כל אחד מריצים ברשת בדיקה ומשווים את ההתנהגות למקור. את הרשת הישנה משאירים פעילה עד לאישור — זו בדיוק נקודת החזרה אם ההשוואה תגלה פער במצב.
שאלות טכניות שנשאלות לפני השקת הרשת
לפני השקת הרשת הראשית הספקות הטכניים חוזרים על עצמם: האם תעמוד בעומס שיא, אפשר לשפר את הלוגיקה אחרי ההשקה, עד כמה מאובטחת הגישה למפתחות. עונים בקצרה — את הפרטים מפרטים במפגש טכני על הארכיטקטורה שלכם.
כיצד תתנהג הרשת עם גידול העומס?
ההרחבה נעשית בשני מנופים: פרמטרי הבלוק — מגבלת ה־gas, הגודל וקצב ייצור הבלוקים — והוספת ולידטורים עם פיזור התעבורה. אנו מריצים מראש מודל של הפעילות שלכם וקובעים את מרווח הביטחון עד לשחיקה, והניטור מצביע על צוואר הבקבוק לפני שהמשתמשים יבחינו בו.
האם אפשר להוסיף מודול או לשנות כללים אחרי ההשקה?
כן. לוגיקת האפליקציה על Cosmos SDK מורכבת ממודולים, ומודול חדש מחובר בעדכון מתוכנן: הצמתים עוברים בהסכמה לגרסה חדשה בגובה בלוק מוגדר, והמצב המצטבר נשמר. כללים משתנים דרך הממשל — הפרמטרים נכנסים לתוקף לפי תוצאות ההצבעה, ולא בתיקון ידני של השרת.
היכן נשמרים המפתחות וכיצד משוחזרת הגישה?
מפתחות הוולידטור והקופה נשמרים במאגרים מבודדים מסוג חומרה, והחתימה נאספת לפי סכמה עם כמה מאשרים. השחזור בנוי על פיצול הסוד בין האחראים: אובדן מדיום אחד אינו חוסם את הגישה, וסדר הפעולות קבוע בנוהל.
נדון במשימה: נחזור עם הערכה ותוכנית עבודה
כדי שהערכת המשימה תישען על עובדות ולא על ניחושים, נדרש לנו הקשר על הרשת ועל התרחיש שלה. שלחו את הנתונים בצורה חופשית — פיתוח על Cosmos SDK מתחיל לעיתים נדירות מדף חלק, ותוצרי עבודה קיימים מקצרים משמעותית את הדרך לאב־טיפוס עובד.
- מטרת הרשת והתרחיש: אילו פעולות נרשמות בבלוקצ'יין, מי המשתתפים, מה צריך להישמר במצב.
- לוגיקת המודולים והטוקנומיקה: הנפקה וחלוקה של הטוקן, עמלות, הרשאות מנהל, סדר עדכון פרמטרי הרשת.
- עומס וטופולוגיה: כמה צמתים וולידטורים צפויים, דרישות לעמידות בפני כשל, האם נדרש בידוד המסלול.
- אינטגרציות: ארנקים, שירותי בורסה וסליקה, העברות בין־רשתיות, ממשקים חיצוניים ואנליטיקה.
- תוצרי עבודה קיימים: מאגר קוד, אב־טיפוס, רשת בדיקה, סכמות נתונים, תוצאות בדיקות קודמות.
- מגבלות וקריטריוני מוכנות: לוחות זמנים, דרישות רגולטוריות, הרשאות גישה לתשתית, מי מצד הלקוח מקבל החלטות על המוצר.
מצדנו נחזור עם תוכנית עבודה לפי שלבים — אב־טיפוס, הרכבת מודולים, השקת רשת בדיקה, הכנה לרשת הראשית — עם הרכב הצוות וחלוקת התפקידים: מי מוביל את המודולים, מי את התשתית והשחרור. נציין לוחות זמנים ונקודות שבהן נדרשת החלטה שלכם, כדי שהפרויקט לא ייעצר.
תארו את המשימה — נחזור עם הערכה ותוכנית עבודה.