פיתוח בוט Discord לאימות מחזיקי NFT מקצה לקצה

אימות NFT ב-Discord: מדוע הבוט נכשל בקנה מידה

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

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

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

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

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

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

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

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

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

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

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

דרכים לאימות בעלות: השוואת גישות

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

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

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

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

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

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

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

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

מקרה בוחן: קהילת אספנים לאחר אימות אוטומטי

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

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

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

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

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

מה לעשות אם השרת כבר חי על תפקידים ידניים

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

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

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

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

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

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

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

מה יקרה אם מקור חיצוני יפסיק להגיב?

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

כיצד נמנע זיוף בעלות?

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

האם הבדיקה עומדת בשרתים גדולים?

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

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

נדון במשימה: מה להכין לשיחה הראשונה

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

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

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