פיתוח L3/שרשרת אפליקציה מבוסס Arbitrum Orbit מקצה לקצה

פיתוח appchain: כאשר רשת משותפת הפכה לצוואר בקבוק

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

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

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

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

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

אנחנו מתכננים ומשיקים רשתות כאלה על בסיס Arbitrum Orbit — הלוגיקה והנתונים נשארים שלכם, והרשת החיצונית הופכת לגשר לנזילות ולנכסים.

האפקט של רשת L3 ייעודית: מה משתנה עבור המוצר

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

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

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

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

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

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

השוואת אפשרויות: רשת משותפת, L3 ייעודית, מסלול פרטי

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

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

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

פיתוח appchain: שלבי העבודה ההנדסית

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

1. ניתוח עומס ופרופיל פעולות. הרכב הקריאות, יחס קריאה לכתיבה, חלונות שיא, דרישות לזמן תגובה. התוצאה — מודל עומס ובדיקת ארכיטקטורה: היכן התכנון יתקל במגבלה הראשונה.
2. תכנון הסכמה. תפקידי הצמתים, סדר ביצוע הטרנזקציות, אחסון נתונים, כללי משיכת כספים לרשת הראשית, פרמטרי עמלות.
3. פריסת המסלול. רשת בדיקה שמשחזרת את רשת הייצור העתידית; העברת חוזים ובדיקת תאימות לשירותים שכבר פועלים.
4. התאמת הרשת למשימה ולנהלי גישה. הפרדת תפקידים, חתימה מרובה לפעולות קריטיות, נוהל רוטציית מפתחות — הרשאות מנהל לא נשארות בידי אדם אחד.
5. בדיקה תחת עומס. תרחישים שמשחזרים פרופיל פעולות אמיתי: בודקים זמן בלוק, תורים ותגובה בשיא.
6. מסירה לתפעול. ניטור עם התראות, תיעוד לתרחישי חירום, הדרכת הצוות. בהמשך — תמיכה ועדכונים.

ארטיפקטים ותיעוד שנשארים אצל הלקוח

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

מה בדיוק אנחנו מוסרים:

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

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

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

מה היה

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

מה עשינו

את עומס האפליקציה העברנו ל-appchain ייעודי על בסיס Arbitrum Orbit: מרחב בלוקים משלו, כללי עמלות משלו וסדר הכללת טרנזקציות משלו. את המסלול הראשי השארנו כשכבת סליקה — לשם עובר רק המצב הסופי, ולכן התפוקה שלו הפסיקה להיות צוואר בקבוק.

מה קרה בסוף

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

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

במה רשת ייעודית שונה מרשת משותפת ומערוץ?

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

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

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

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

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

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

שאלות נפוצות על תצורה ותפעול של רשת

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

מי מחזיק את ההרשאות לרשת אחרי המסירה?

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

מה יקרה כשהעומס יגדל פי כמה?

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

למה לפצל מוצר למספר מסלולים?

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

נדבר על המשימה: מה לשלוח להערכה מדויקת

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

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

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

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