פיתוח מערכת בדיקת אנטי-סיביל מקצה לקצה

מערכת Anti-sybil: מדוע רכישות מזויפות עוברות את המסננים

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

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

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

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

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

אפקט ההגנה: פחות רכישות מזויפות, פחות חסימות שווא

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

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

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

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

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

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

אפשרויות לבניית מערכת anti-sybil ומגבלותיהן

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

מה נותן שילוב הגישות

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

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

שלבי ההטמעה: מניתוח נתונים ועד לתקנות

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

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

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

חפצי ההטמעה: כללים, ספים, סכמות, ערעורים

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

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

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

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

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

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

מה היה לפני ההטמעה

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

מה שינינו

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

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

מה נהיה

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

במה נבדלת בדיקה לפי כללים ממודל התנהגותי?

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

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

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

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

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

מקרים שנויים במחלוקת, פרטיות נתונים ועדכון כללים

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

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

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

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

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

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

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

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

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