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

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

תאימות היא נקודת פתיחה, לא קו הסיום

ממשק ה־provider של Ethereum מספק ליישומים אבני בניין משותפות. EIP-3085 מגדיר בקשה שבה יישום מציע לארנק להוסיף רשת. EIP-3326 מגדיר בקשה למעבר אל הרשת הפעילה. אלה מנגנוני תאימות חשובים, אך הם משאירים את ההחלטה הסופית בידי הארנק והמשתמש — כולל האפשרות לדחות את הבקשה.

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

רשתות הן תצורת מוצר

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

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

התיעוד הרשמי ממחיש מדוע התצורה חייבת להיות מפורשת. Ethereum Sepolia משתמשת ב־chain ID ‏11155111. Base Sepolia משתמשת ב־84532 וב־ETH כגז. Polygon Amoy משתמשת ב־80002 וב־POL. שלושתן רשתות בדיקה מבוססות EVM, אבל המשתמש עדיין זקוק לנכס הגז, לנתיב ה־RPC ולסייר הנכונים בכל סביבה. לכן ״תואם EVM״ הוא יתרון הנדסי, לא חוויית משתמש שלמה.

מעבר רשת הוא שינוי מצב מוצרי

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

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

שלוש רשתות יוצרות יותר משלושה תרחישי בדיקה

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

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

בוחרים רשת לפי תוצאת משתמש

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

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

עיקרון המוצר

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

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