פיתוח מערכת הגנת אנטי-בוט בעת מינט

הגנת אנטי-בוט ל-NFT במינט: היכן נשברת השקה הוגנת

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

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

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

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

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

מה נותן סינון מנוהל של המינט: זמן, כיסוי, דחיות

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

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

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

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

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

סינון אנטי-בוט בכניסה: השוואת גישות

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

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

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

שלבי יישום: מביקורת התור ועד מסירת נהלים

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

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

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

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

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

ניתוח השקה: מדדי מינט לפני ואחרי היישום

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

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

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

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

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

המינט כבר רץ, והבוטים עוברים: מה לעשות קודם כל?

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

הפרקטיקה של מודולים מוכחים כמו OpenZeppelin היא בדיוק לצמצם את המקומות ה«בלתי ניתנים לשינוי» למינימום.

ללא עצירה обычно מפעילים:

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

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

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

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

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

ספקות טכניים בהשקת מינט: תשובות מהנדסים

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

האם הבוטים בכל זאת ימצאו דרך לעקוף את הבדיקה?

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

מה קורה עם נתוני המשתתפים?

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

האם הבדיקה תאט את המינט ותיצור תור?

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

נדון במשימה שלכם: נאסוף דרישות ונחזור עם הערכה

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

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

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית.