הנדסת צינורות נתונים און-צ'יין ל-ML

לעתים קרובות אנו נתקלים בבקשה: "אנחנו רוצים לחזות פעילות של לווייתנים" או "אנחנו צריכים מודל סיכון אשראי on-chain." מאחורי זה עומדת בעיה הנדסית שרוב הצוותים מזלזלים בה: נתוני בלוקצ'יין גולמיים אינם שמישים ישירות עבור מודלי ML. מבני בלוקים, calldata גולמי מקודד hex, כתובות bytes20 — אלה אינם features; הם חומרי גלם. בין צומת RPC לבין מערך נתונים לאימון מונחים מספר שבועות של עבודת תשתית. לדוגמה, כדי לבנות מודל יציאת נזילות עבור פרוטוקול DeFi, אתה צריך לא רק אירועי Transfer אלא גם קריאות פנימיות, מידע trace, וחותמות זמן מנורמלות לאזור זמן אחד. כל אחת מהפעולות הללו דורשת צינור נתונים נפרד עם בקרת שגיאות ויכולת שחזור. בפועל, ללא צינור נתונים נכון, אתה מסתכן ביצירת features זבל שמפחיתים את איכות המודל.

תשתית ה-ML ה-on-chain שלנו מטפלת בכל דבר, החל מצינור נתוני Ethereum ועד פרופילינג של ארנקים וזיהוי MEV, תוך שימוש ב-features נקודתיים בזמן ו-Feast feature store לעיבוד נתוני בלוקצ'יין. אנו מתמחים בבניית צינורות נתונים on-chain עבור ML, הפחתת עלויות תשתית והבטחת נכונות נקודתית בזמן.

מדוע נתוני בלוקצ'יין גולמיים אינם מתאימים ל-ML

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

• פענוח — פענוח ABI של topics ונתונים
• נורמליזציה של כתובות — uint256 → hex עם checksum, מיפוי תוויות (בורסות, פרוטוקולים, בוטים של MEV)
• נורמליזציה מוניטרית — value / 10^decimals, המרה ל-USD באמצעות עדכון מחירים היסטורי
• פתרון ישויות — EOA אחד עשוי להיות בעל מאות עסקאות אך להיות סוכן כלכלי יחיד; חוזים חכמים — proxies, implementations, multisigs

דילוג על כל שלב מוביל ל-features זבל.

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

מקורות נתונים: מ-RPC לספקים מתמחים

RPC ציבורי (eth_getLogs, eth_getBlockByNumber) הוא הנגיש ביותר אך הכי פחות מתאים ל-ML. המגבלות שלו: מגבלות קצב (Infura/Alchemy — 10-333 בקשות/שנייה בתוכניות בתשלום), אין עסקאות פנימיות ללא מרחב השמות trace_, אין מצב לפני/אחרי ללא צומת ארכיון. צומת ארכיון עם trace API מספק היסטוריה מלאה אך דורש Erigon עם כ-2.5 TB שטח דיסק עבור Ethereum mainnet ו-3-5 ימי סנכרון. פורמטי ה-trace_ שונים בין Erigon ל-Geth/Besu — המפענח חייב להיות מותאם. Firehose (StreamingFast/The Graph) מייצא כל בלוק עם עץ הקריאות והבדלי מצב בתוך <500ms, ומשיג 100k+ בלוקים לדקה — מהיר פי 20-100 מ-RPC. ספקים מתמחים (Nansen, Dune, Flipside, Allium) מציעים טבלאות מנורמלות מראש אך עם השהיית עדכון של 1-24 שעות ושליטה מוגבלת בסכימה. עבור ML בייצור, אנו ממליצים לשלב: Firehose לטעינה היסטורית וצומת ארכיון לסטרימינג בזמן אמת.

כיצד נכונות נקודתית בזמן מובטחת בקצה האחורי

זו הבעיה המרכזית. יש לחשב features רק מנתונים זמינים לפני רגע החיזוי. טעות אופיינית: שימוש ב-total_tx_count של כתובת במקום tx_count_at_time_T. דפוס: features של עקביות זמנית. כל שורה ב-feature store מכילה entity_id, feature_timestamp, ו-feature_value. בעת יצירת נתוני אימון, הצטרף לפי entity_id ו-feature_timestamp <= label_timestamp.

-- Point-in-time join SELECT l.wallet_address, l.label, l.label_timestamp, f.tx_count, f.unique_contracts, f.volume_usd_30d FROM labels l ASOF JOIN wallet_features f ON l.wallet_address = f.wallet_address AND f.feature_timestamp <= l.label_timestamp 

ASOF JOIN הוא מקורי ב-ClickHouse ו-TimescaleDB; ב-PostgreSQL הוא מחוקה באמצעות LATERAL.

חנות אופליין — features היסטוריים לאימון. ClickHouse או Parquet על S3 עם חלוקת Hive לפי תאריך. חנות אונליין — features נוכחיים להסקה. מבני Redis Hash: HGETALL wallet:{address}:features. מתעדכן עם כל בלוק חדש עבור כתובות פעילות.

ארכיטקטורת צינור ייצור

שכבת קליטה

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

[Archive Node / Firehose] ↓ [Kafka / Redpanda] ← hot path: < 1s latency ↓ [Stream Processor] ← Flink или кастомный consumer / \ [Raw Store] [Feature Store] ← cold: S3/Parquet, hot: Redis/Feast 

נושא Kafka לכל chain, מפתח = block_number:log_index. זה מבטיח סדר ומאפשר replay בשגיאות עיבוד. שמירה תלויה במשימה: 7 ימים ל-features בזמן אמת, ארכיון מלא ב-S3 לאימון מחדש. עבור Ethereum mainnet: ~6000 עסקאות/בלוק × ~6500 בלוקים/יום = ~39M עסקאות/יום. גודל עסקה ממוצע עם trace ~2KB = ~75GB/יום נתונים גולמיים. תכנן אחסון בהתאם.

הנדסת features וחנויות

זה החלק עתיר העבודה ביותר. features בלוקצ'יין אופייניים למשימות ML שונות: פרופילינג ארנקים (ניקוד אשראי DeFi, זיהוי Sybil):

זיהוי MEV:

• דפוס מתקפת סנדוויץ': שלוש עסקאות בבלוק אחד, אותה כתובת, סביב עסקת מטרה
• ארביטראז': העברות אסימונים מחזוריות שחוזרות לשולח בתוך עסקה אחת
• Flashloan: אירוע FlashLoan + דלתא מיקום = 0 בסוף הבלוק

חיזוי פעילות לווייתנים:

• העברות גדולות מכתובות הפקדה בבורסות → הסתברות ללחץ מכירה
• דפוס צבירה: מספר רכישות קטנות מכתובות שונות → נמען אחד

# Пример feature engineering для wallet scoring import polars as pl def compute_wallet_features(txs: pl.DataFrame) -> pl.DataFrame: return txs.group_by("from_address").agg([ pl.col("block_number").min().alias("first_seen_block"), pl.col("block_number").max().alias("last_seen_block"), pl.count("hash").alias("tx_count"), pl.col("to_address").n_unique().alias("unique_contracts"), pl.col("gas_price").quantile(0.5).alias("gas_price_median"), pl.col("value_usd").sum().alias("total_volume_usd"), pl.col("block_timestamp").diff().dt.total_seconds() .mean().alias("avg_interval_seconds"), ]) 

Polars על פני Pandas — הפרש המהירות על מערכי נתונים גדולים (מיליוני שורות) הוא פי 5-20.

טיפול בארגון מחדש ו-MLOps

Reorgs ברמת נתוני ML הם בעיה רצינית. אם features מחושבים מבלוק שמאוחר יותר הופך ליתום, מערך האימון מכיל נתונים לא מציאותיים. פתרונות:

• השהיית אישור — אינדקס רק בלוקים ישנים מ-N בלוקים (בדרך כלל 12-32 לסופיות ב-PoS Ethereum). מוסיף השהיה אך פותר את הבעיה.
• features עם גרסאות — אחסון (entity, block_hash, features), סימון ערכים יתומים בעת reorg. מורכב יותר אך מאפשר פעולה עם השהיה נמוכה.

אינטגרציית MLOps. הצינור חייב להשתלב עם מחסן ה-ML הקיים שלך: יצירת features → אימון: ייצוא ל-Parquet/CSV עבור DVC או MLflow artifacts. גרסת מערך נתונים היא קריטית — מודל שאומן על נתונים מתקופה מסוימת חייב להיות ניתן לשחזור. צינור הסקה: בלוק חדש → חישוב features דלתא → עדכון חנות אונליין → הפעלת הסקה. תקציב השהיה הוא בדרך כלל 1-10 שניות מבלוק לחיזוי. ניטור סחיפת מודל: נתוני בלוקצ'יין משתנים מבחינה מבנית (מיזוגים, פרוטוקולים חדשים, שינויי דפוסים). אנו מגדירים ניטור של התפלגות features קלט — Evidently AI או מותאם אישית.

שלבי פרויקט אופייניים

1. ביקורת נתונים (1-2 שבועות) — זיהוי אותות נדרשים, מקורותיהם וזמינות נתונים היסטוריים. אב טיפוס של קולט על טווח בלוקים קטן.

2. השלמה היסטורית (2-4 שבועות) — טעינת נתונים היסטוריים, נורמליזציה, מיפוי תוויות. השלב עתיר הזמן ביותר.

3. צינור features (2-3 שבועות) — יישום הנדסת features, לוגיקת עקביות זמנית, אחסון.

4. נתיב בזמן אמת (1-2 שבועות) — סטרימינג מהצומת, חנות אונליין, אינטגרציית הסקה.

5. MLOps (1-2 שבועות) — ניטור סחיפה, גרסת מערך נתונים, אימון מחדש אוטומטי.

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

מה כלול

• עיצוב ארכיטקטורה לבעיה הספציפית שלך
• הקמת תשתית (Kafka, ClickHouse, Redis)
• הנדסת features לאותות מטרה
• אינטגרציית MLOps (MLflow, DVC)
• תיעוד והדרכת צוות

נוסדה ב-2019, יש לנו 5+ שנות ניסיון שוק ורקורד של 20+ פרויקטי נתונים on-chain מוצלחים. לצוות שלנו יש 10+ שנות ניסיון בפיתוח בלוקצ'יין. שימוש בצינור הנתונים ה-on-chain שלנו יכול להפחית עלויות תשתית בעד 40% — לקוחות בדרך כלל חוסכים $10,000–$20,000 בחודש. לדוגמה, לקוח אחד חסך $15,000 בחודש לאחר מעבר למערכת שלנו. בקש ביקורת על נתוני הבלוקצ'יין שלך — קבל צינור אב טיפוס תוך שבועיים. צור קשר לייעוץ.