פריסת Blockscout מותאם אישית עבור רשתות EVM

פריסת Blockscout לרשת: היכן אובדים הנתונים

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

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

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

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

האפקט: מהירות חיפוש, שלמות היסטוריה, שליטה בגישה

סייר שנבנה עבור רשת EVM מסוימת נותן אפקט שנמדד, לא מתווכח עליו. להלן מה בדיוק משתנה אחרי פריסת סייר בלוקים מותאם אישית מבוסס Blockscout ולפי אילו מדדים הוא מתקבל.

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

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

איך למקם את הסייר: ענן, שרתים משלכם, היברידי

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

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

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

איך עוברת פריסת Blockscout: שלבי ההטמעה

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

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

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

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

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

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

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

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

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

מארז האספקה: קונפיגורציות, סכימות, נהלים

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

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

מקרה בוחן: סייר לרשת בצמיחה, מדדים לפני ואחרי

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

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

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

מדדים לפני ואחרי

מה זה נתן

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

במה שונה סייר משלכם מסייר מוכן של ספק

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

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

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

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

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

ספקות טכניים: עומס, הרשאות, עדכונים

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

תפקידים גם מופרדים: לצומת, למסד ולחלק הווב יש הרשאות, מפתחות וגישות רשת משל עצמם. מנהל לא ניגש למסד מהדפדפן, ועדכונים נפרסים רכיב אחר רכיב עם בדיקה אחרי כל שלב. להלן תשובות למה ששואלים הכי часто לפני ההתחלה.

איך מופרדות ההרשאות?

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

איך מעדכנים את הסייר בלי לאבד נתונים?

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

מי אחראי לגיבויים ולאבטחה?

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

מה לשלוח כדי שנחזור עם תוכנית והערכה

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

• פרמטרי רשת: chain id, סוג — רשת EVM משלכם, rollup או sidechain, מצב קונצנזוס, כתובות של חוזים מערכתיים.
• גישה לצמתים: נקודות קצה RPC ו-WebSocket של צומת ארכיון, פרטי גישה, פלטפורמה לסייר והמגבלות שלה.
• עומס והיסטוריה: מספר עסקאות ביום, עומק אינדוקס — מבלוק האפס או מגובה מסוים, האם נדרשות עסקאות פנימיות ולוגים.
• פונקציונליות למשימה: אימות חוזים, דפי טוקנים וכתובות, API פתוח, ממשק מותאם אישית, תפקידי מודרטור — מזה נפח העבודה.
• מצב נוכחי: האם הסייר עובד כעת, האם צריך להעביר מסד מאונדקס ולשמור כתובות וקישורים ישנים.
• צוות והרשאות: מי מעביר צמתים והרשאות מצדכם, מי מקבל את התוצאה, באילו חלונות אפשר לבצע עבודות.
• תחזוקה: אילו אירועים קריטיים, האם נדרשות התראות ונוהל עדכונים לתחזוקת הסייר.

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