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

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

דוגמאות קלאסיות הן איירדרופ של ENS ו-Uniswap. שניהם נתנו טוקנים לכל הכתובות עם היסטוריה מסוימת. גישה מתוחכמת יותר שימשה את Arbitrum STIP ו-Optimism RPGF: הם השתמשו במדדי פעילות רטרוספקטיביים לאורך תקופה ארוכה עם קבוצות משוקללות מרובות. הגישה שלנו יכולה לחסוך עד 70% בסינון Sybil בהשוואה למודרציה ידנית. זה פי 3.3 יותר טוב משיטות ידניות.

למה סינון אנטי-Sybil הוא קריטי לאיירדרופים

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

אינדיקטורים טכניים לקלאסטר:

• זמן יצירת חשבון זהה (בתוך בלוק או שעה אחת)
• מקור מימון משותף (כולם מומנו מכתובת אחת)
• דפוסי עסקאות זהים (אותם חוזים, אותם סכומים)
• אין פעילות מחוץ לפרוטוקול היעד

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

איך בנויה הארכיטקטורה של אוטומציית איירדרופ

שכבת איסוף נתונים (off-chain)

כל האנליטיקה נעשית off-chain. אחסון קריטריונים מלאים על השרשרת בלתי אפשרי בגלל עלויות חישוב ואחסון גבוהות. התוכנית: נתונים מצמתים (דרך Alchemy/QuickNode archival nodes או The Graph subgraphs) → צינור אנליטי → עץ מרקל → שורש שפורסם על השרשרת → תביעה דרך proof. (הפניה לעץ מרקל בוויקיפדיה)

מקור נתונים טיפוסי:

• היסטוריית עסקאות — כל עסקאות הכתובת עם הפרוטוקול בתקופה
• יומני אירועים — Swap, Deposit, Borrow, Repay מחוזי הפרוטוקול
• יתרות טוקנים בצילום — יתרות ERC-20 בבלוקים ספציפיים
• ENS / Lens / Farcaster — אימות זהות אמיתית
• פעילות חוצת שרשרת — פעילות בשרשראות אחרות לאנטי-Sybil

קריטריונים ומשקלים

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

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

מפיץ מרקל

יישום סטנדרטי — MerkleDistributor (כמו של Uniswap). אלגוריתם:

1. חישוב הקצאות לכל הכתובות off-chain
2. בניית עץ מרקל: כל עלה = keccak256(abi.encodePacked(address, amount))
3. כתיבת השורש לחוזה
4. משתמש תובע על ידי מתן proof (מערך של hashes אחים)

function claim(uint256 index, address account, uint256 amount, bytes32[] calldata merkleProof) external {
    require(!isClaimed(index), "Already claimed");
    bytes32 node = keccak256(abi.encodePacked(index, account, amount));
    require(MerkleProof.verify(merkleProof, merkleRoot, node), "Invalid proof");
    _setClaimed(index);
    IERC20(token).safeTransfer(account, amount);
    emit Claimed(index, account, amount);
}

ביטים שנתבעו נארזים לתוך function claim(uint256 index, address account, uint256 amount, bytes32[] calldata merkleProof) external { require(!isClaimed(index), "Already claimed"); bytes32 node = keccak256(abi.encodePacked(index, account, amount)); require(MerkleProof.verify(merkleProof, merkleRoot, node), "Invalid proof"); _setClaimed(index); IERC20(token).safeTransfer(account, amount); emit Claimed(index, account, amount); } — 256 כתובות לכל uint256, חיסכון בגז על אחסון.

אפשרות Vesting

תביעה מיידית של הסכום המלא גורמת לדאמפ. חלופה: vesting ליניארי דרך חוזה TokenVesting או תוכנית cliff + ליניארי. דוגמה: 10% מיידית, השאר ליניארית על פני 6 חודשים. מיושם או כחוזה vesting נפרד (משתמש תובע → טוקנים נכנסים לזרם vesting) או דרך אינטגרציה עם Sablier v2 / LlamaPayV2 לחלוקה מבוססת זרמים.