Розробка моделі класифікації фейкових новин у крипто

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1305 послуг
Розробка моделі класифікації фейкових новин у крипто
Складний
від 2 тижнів до 3 місяців
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1374
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1256
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    965
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1208
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    667
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    954

Крипто-ринок — ідеальне середовище для дезінформації. Волатильність висока: один фейковий твіт про лістинг на Binance або про злам протоколу рухає ціну на десятки відсотків. Pump-and-dump схеми починаються з інформаційної маніпуляції. Ми розробляємо модель класифікації фейкових новин у крипто під ключ — від збору датасету до деплою. Використовуємо NLP для крипто: fine-tuning FinBERT на крипто-корпусі та on-chain верифікацію новин. Детекція дезінформації крипто — наш профіль. Оцінимо ваш проєкт і запропонуємо рішення.

Розробка такого класифікатора — задача NLP із кількома специфічними складнощами: вузькодоменна термінологія, швидкість поширення інформації (новина застаріває за години), мультимовність, навмисна обфускація тексту авторами фейків. Ми використовуємо сучасний стек: PyTorch, HuggingFace Transformers, Fine-tuning FinBERT на крипто-корпусі. У результаті ви отримуєте систему, здатну автоматично виявляти дезінформацію з recall > 0.85 та precision > 0.90.

Які типи фейків ми розрізняємо?

Перш ніж будувати модель, потрібно зрозуміти, що саме класифікуємо. «Фейкові новини» — занадто широке поняття. Ми виділяємо наступні категорії:

Категорія Приклад Верифікація
Fake listing «Токен X ліститься на Binance завтра» Перевірка пулу на Uniswap, офіційний акаунт біржі
Fake partnership «Протокол A інтегрується з B» On-chain взаємодія контрактів
Fabricated exploit «Зламано протокол C, втрачено $10M» Зміна TVL у DeFiLlama
Shill content «100x guaranteed, next bitcoin» Аналіз текстових патернів, розкриття фінансового інтересу
Impersonation Акаунт Vitalik_Buterin_ з помилкою Перевірка верифікації, граматичні помилки

Кожна категорія має свої текстові патерни, джерела та методи верифікації. Модель класифікує за категоріями, а не бінарно «fake/real».

Як ми збираємо дані для навчання?

Головна проблема — відсутність готового датасету. Існуючі датасети (LIAR, FakeNewsNet) не охоплюють крипто-специфіку.

Джерела даних:

  • Twitter/X API: Academic Research API дає доступ до історичних даних. Фільтруємо акаунти з > 1,000 follower у крипто-ніші, хештеги #bitcoin, #defi, ключові слова протоколів.
  • Telegram: Telethon для парсингу публічних каналів. Важливе джерело — pump-and-dump канали.
  • Reddit: r/CryptoCurrency, r/Bitcoin, r/CryptoMoonShots через Pushshift API.
  • Новинні агрегатори: CoinDesk, Cointelegraph, Decrypt — верифіковані новини (позитивний клас).

Автоматична крос-верифікація: якщо новина з'являється у Twitter, але не підтверджується офіційними каналами за 24 години — потенційний фейк; якщо суперечить on-chain даним — фейк з високою ймовірністю. Human labeling через краудсорсинг з доменними експертами. Кожен приклад розмічається мінімум трьома анотаторами, inter-annotator agreement > 0.7.

from datasets import Dataset
import pandas as pd

# Структура датасету
example_schema = {
    'id': str,
    'text': str,
    'source': str,
    'author': str,
    'timestamp': str,
    'label': int,
    'category': str,
    'confidence': float,
    'verification_sources': list,
    'mentioned_tokens': list,
    'mentioned_exchanges': list,
}

def balance_dataset(df: pd.DataFrame, target_ratio: float = 0.4) -> pd.DataFrame:
    fake = df[df['label'] == 1]
    real = df[df['label'] == 0]
    n_fake = len(fake)
    n_real_target = int(n_fake / target_ratio * (1 - target_ratio))
    real_sampled = real.sample(n=min(n_real_target, len(real)), random_state=42)
    return pd.concat([fake, real_sampled]).sample(frac=1, random_state=42)

Архітектура моделі

Feature Engineering: що важливо для крипто-фейків

Текстові сигнали фейків:

  • Надмірний hype без конкретики («100x guaranteed», «next bitcoin»)
  • Терміновість («buy NOW», «last chance»)
  • Імена відомих проєктів/особистостей без контексту
  • Граматичні помилки (акаунти-імітатори часто недбалі)

Metadata ознаки:

  • Вік акаунта та історія публікацій
  • Follower/following ratio (0.01 — підозріло)
  • Швидкість поширення (віральність за першу годину)
  • Часовий патерн (публікація о 3:00 UTC)

Baseline: TF-IDF + Logistic Regression / XGBoost. Основна модель: FinBERT (фінансовий BERT), fine-tuned на крипто-корпусі. Фінальний ансамбль: градієнтний бустинг на конкатенації CLS-ембедінгів та мета-ознак. Така комбінація значно точніша: ансамбль у 1.15 раза точніший за одиночний FinBERT.

from transformers import AutoTokenizer, AutoModelForSequenceClassification
import torch
import numpy as np
from sklearn.ensemble import GradientBoostingClassifier

class CryptoFakeNewsClassifier:
    def __init__(self, model_name: str = 'ProsusAI/finbert'):
        self.tokenizer = AutoTokenizer.from_pretrained(model_name)
        self.text_model = AutoModelForSequenceClassification.from_pretrained(
            model_name, 
            num_labels=6
        )
        self.meta_classifier = GradientBoostingClassifier(
            n_estimators=300,
            max_depth=6,
            learning_rate=0.05
        )
        
    def extract_text_features(self, texts: list[str]) -> np.ndarray:
        self.text_model.eval()
        all_embeddings = []
        batch_size = 32
        for i in range(0, len(texts), batch_size):
            batch = texts[i:i+batch_size]
            inputs = self.tokenizer(
                batch,
                max_length=512,
                truncation=True,
                padding=True,
                return_tensors='pt'
            )
            with torch.no_grad():
                outputs = self.text_model(**inputs, output_hidden_states=True)
                cls_embeddings = outputs.hidden_states[-1][:, 0, :]
                all_embeddings.append(cls_embeddings.numpy())
        return np.vstack(all_embeddings)
    
    def extract_meta_features(self, posts: list[dict]) -> np.ndarray:
        features = []
        for post in posts:
            account_age_days = (
                pd.Timestamp.now() - pd.Timestamp(post['account_created'])
            ).days
            feature_vector = [
                account_age_days,
                post.get('followers_count', 0),
                post.get('following_count', 1),
                post.get('followers_count', 0) / max(post.get('following_count', 1), 1),
                post.get('tweet_count', 0),
                post.get('retweet_count', 0),
                post.get('like_count', 0),
                int(post.get('verified', False)),
                len(post.get('text', '')),
                post.get('text', '').count('!'),
                post.get('text', '').count('$'),
                np.sin(2 * np.pi * pd.Timestamp(post['created_at']).hour / 24),
                np.cos(2 * np.pi * pd.Timestamp(post['created_at']).hour / 24),
                int('http' in post.get('text', '')),
                sum(1 for token in KNOWN_TOKENS if token.lower() in post.get('text', '').lower()),
            ]
            features.append(feature_vector)
        return np.array(features)
    
    def predict(self, posts: list[dict]) -> dict:
        texts = [p['text'] for p in posts]
        text_features = self.extract_text_features(texts)
        meta_features = self.extract_meta_features(posts)
        combined = np.hstack([text_features, meta_features])
        probabilities = self.meta_classifier.predict_proba(combined)
        predictions = self.meta_classifier.predict(combined)
        return {
            'predictions': predictions,
            'probabilities': probabilities,
            'labels': ['real', 'fake_listing', 'fake_partnership', 
                      'fake_exploit', 'shill', 'impersonation']
        }

Fine-tuning на крипто-домен

FinBERT навчався на фінансових новинах, але не спеціалізований для крипто. Fine-tuning на крипто-корпусі значно покращує якість: recall для фейків зростає на 5–7%. Використовуємо кастомні ваги класів для балансування: фейкові класи отримують більший штраф за пропуск.

from transformers import Trainer, TrainingArguments

training_args = TrainingArguments(
    output_dir='./crypto-fake-news-model',
    num_train_epochs=5,
    per_device_train_batch_size=16,
    per_device_eval_batch_size=32,
    warmup_steps=500,
    weight_decay=0.01,
    evaluation_strategy='epoch',
    save_strategy='epoch',
    load_best_model_at_end=True,
    metric_for_best_model='f1_macro',
)

Чому on-chain верифікація важлива?

Унікальна перевага крипто-домену: багато заяв верифіковані on-chain. Заявлений лістинг на Uniswap V3 — перевіряємо через Uniswap Subgraph, чи існує пул. Заявлений exploit — перевіряємо зміну TVL у DeFiLlama за вказаний період. Заявлене партнерство — шукаємо on-chain взаємодію між контрактами. Це детермінована перевірка, яка значно підвищує точність для категорій з on-chain слідом.

import aiohttp

async def verify_listing_claim(token_address: str, dex: str = 'uniswap_v3') -> dict:
    if dex == 'uniswap_v3':
        query = """
        query PoolsForToken($token: String!) {
            pools(where: { 
                or: [
                    { token0: $token },
                    { token1: $token }
                ]
            }, first: 5) {
                id
                token0 { symbol }
                token1 { symbol }
                liquidity
                totalValueLockedUSD
                createdAtTimestamp
            }
        }
        """
        async with aiohttp.ClientSession() as session:
            async with session.post(
                'https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v3',
                json={'query': query, 'variables': {'token': token_address.lower()}}
            ) as response:
                data = await response.json()
                pools = data.get('data', {}).get('pools', [])
                return {
                    'listing_exists': len(pools) > 0,
                    'pools': pools,
                    'total_tvl': sum(float(p['totalValueLockedUSD']) for p in pools)
                }

async def verify_exploit_claim(protocol: str, claimed_amount_usd: float, 
                                claim_timestamp: int) -> dict:
    async with aiohttp.ClientSession() as session:
        async with session.get(
            f'https://api.llama.fi/protocol/{protocol}'
        ) as response:
            data = await response.json()
            tvl_history = data.get('tvl', [])
    before_tvl = get_tvl_at_timestamp(tvl_history, claim_timestamp - 3600)
    after_tvl = get_tvl_at_timestamp(tvl_history, claim_timestamp + 3600)
    tvl_drop = before_tvl - after_tvl if before_tvl > after_tvl else 0
    return {
        'tvl_drop_detected': tvl_drop > 0,
        'detected_amount': tvl_drop,
        'claimed_amount': claimed_amount_usd,
        'plausible': abs(tvl_drop - claimed_amount_usd) / claimed_amount_usd < 0.3
    }

Як оцінити якість моделі?

Для детекції фейків accuracy — неправильна метрика. Якщо 90% прикладів реальні, модель, яка завжди передбачає «real», отримає 90% accuracy. Основні метрики: precision, recall, F1 за класами. Особлива увага — recall для fake класів: пропуск фейку гірший за хибну тривогу.

Цільові показники для production: Fake detection recall > 0.85, real precision > 0.90, F1 macro > 0.82. Моніторимо temporal stability: модель повинна зберігати якість на нових даних, тому раз на місяць проводимо перенавчання.

Порівняння підходів:

Модель Точність (F1 macro) Швидкість обробки Складність впровадження
TF-IDF + XGBoost 0.72 1000 запитів/с Низька
FinBERT (без fine‑tuning) 0.78 100 запитів/с Середня
FinBERT + ансамбль (наша) 0.85 80 запитів/с Висока

Наша архітектура дає F1 на 18% вищий, ніж TF-IDF + XGBoost. Типовий збиток від одного успішного фейкового твіту оцінюється в $10,000–$500,000.

from sklearn.metrics import classification_report, roc_auc_score
import pandas as pd

def evaluate_model(y_true, y_pred, y_proba, class_names):
    report = classification_report(
        y_true, y_pred, 
        target_names=class_names,
        output_dict=True
    )
    df_report = pd.DataFrame(report).T
    fake_classes = [c for c in class_names if c != 'real']
    fake_f1_avg = df_report.loc[fake_classes, 'f1-score'].mean()
    print(f"Fake detection F1 (macro avg): {fake_f1_avg:.3f}")
    print(f"Real precision: {df_report.loc['real', 'precision']:.3f}")
    binary_labels = (y_true > 0).astype(int)
    binary_proba = 1 - y_proba[:, 0]
    auc = roc_auc_score(binary_labels, binary_proba)
    print(f"AUC-ROC (fake vs real): {auc:.3f}")
    return df_report

Що входить у роботу

  • Збір та розмітка датасету (50 000+ прикладів) з автоматичною та ручною верифікацією
  • Fine-tuning FinBERT на вашому корпусі (або нашому публічному)
  • Розробка пайплайну з on-chain верифікацією через The Graph, DeFiLlama
  • Деплой у Docker-контейнері з FastAPI, Kafka для потокової обробки, моніторинг concept drift
  • Алертинг при виявленні фейків з налаштовуваними порогами
  • Документація по API та посібник користувача

Процес роботи

  1. Аналітика: вивчаємо ваші джерела даних, визначаємо цільові категорії фейків
  2. Проєктування: обираємо стек, проєктуємо датасет і пайплайн верифікації
  3. Реалізація: збір даних, навчання baseline та transformer моделі, ітерації
  4. Тестування: оцінка на історичних та свіжих даних, A/B-тестування
  5. Деплой: розгортання у вашій інфраструктурі, інтеграція з існуючими сервісами

Терміни орієнтовно

Від 3 до 4 місяців до production-ready системи. Збір та розмітка датасету — 6–8 тижнів, навчання моделей — 4–6 тижнів, деплой та моніторинг — 3–4 тижні. Вартість розраховується індивідуально.

Наша команда має 8+ років досвіду в NLP та блокчейні, виконала 30+ проєктів з класифікації контенту. Економія від запобігання втратам на фейкових новинах може сягати сотень тисяч доларів. Зв'яжіться з нами для оцінки вашого проєкту — ми підберемо оптимальне рішення. Замовте розробку моделі вже сьогодні.

Аудит смарт-контрактів: як знаходять те, що не бачить компілятор

Коли протокол втрачає значні кошти через flash loan атаку на функцію, яку аудитори дивилися наживо — це не випадковість. Це системна прогалина в методології. Наш досвід показує: вразливість живе в контракті більше року, а компілятор мовчить. Ми перебудували процес аудиту так, щоб ловити такі кейси до деплою.

Що не знайде статичний аналіз?

Slither — стандартний перший інструмент. Знаходить reentrancy, integer overflow (в старих версіях Solidity), неправильне використання tx.origin, shadowing змінних, неініціалізовані сховища. На реальному проекті Slither видає десятки попереджень, з яких критичних — 0‑2. Решта — інформаційний шум.

Slither не знайде логічну вразливість. Якщо withdraw коректно перевіряє баланс і коректно оновлює стан, але бізнес-логіка дозволяє подвійне списання через два різні шляхи кодової бази — Slither промовчить.

Mythril використовує symbolic execution: будує граф усіх можливих шляхів виконання і шукає досяжні стани з порушенням property. Працює добре на ізольованих контрактах. На протоколі з 20 контрактів з cross‑contract викликами — path explosion, аналіз зависає або видає false positive.

Обидва інструменти обов'язкові як перший pass. Але вони не замінюють ручний аналіз.

Fuzzing: де Echidna та Foundry знаходять реальні баги?

Echidna — property‑based fuzzer від Trail of Bits. Ідея: формулюєш інваріанти контракту як Solidity‑функції (echidna_invariant), Echidna генерує випадкові послідовності викликів і намагається зламати інваріант.

Приклад інваріанта для lending протоколу:

function echidna_total_assets_ge_liabilities() public view returns (bool) {
    return totalAssets() >= totalLiabilities();
}

Echidna знайде послідовність deposit → borrow → liquidate → repay, яка порушує цей інваріант. Руками такий кейс не побудуєш — комбінацій занадто багато.

Foundry fuzzing (forge test --fuzz-runs 100000) простіший в інтеграції, якщо команда вже на Foundry. Підтримує stateful fuzzing через invariant тести. В реальному проекті: auditing vault контракт, Foundry fuzz за 40 хвилин знайшов edge case, при якому maxWithdraw повертав значення більше фактичного балансу при конкретному співвідношенні shares/assets після кількох донатів. Hardhat unit‑тести цей кейс пропускали — там не було такої комбінації параметрів.

Medusa (від Trail of Bits, новіша за Echidna) підтримує corpus‑guided fuzzing і працює швидше на великих контрактах. Якщо обсяг кодової бази > 5000 рядків Solidity — дивимося на Medusa.

Як інваріанти допомагають виявити критичні уразливості?

Формальна верифікація доводить, що контракт задовольняє специфікації для всіх можливих вхідних даних — не для N випадкових, а математично для всіх. Інструменти: Certora Prover, K Framework, Halmos.

Certora працює з CVL (Certora Verification Language): пишеш rules і invariants, Prover транслює їх у SMT‑формули і перевіряє через Z3/CVC5. MakerDAO, Aave, Uniswap використовують Certora в CI/CD pipeline — кожен PR верифікується автоматично.

Обмеження: не працює з необмеженими циклами, складно справляється з hash functions і signature verification. Для контрактів з простою математикою (AMM, lending) — відмінно. Для контрактів з довільними зовнішніми викликами — складно написати достатньо повну специфікацію.

Formal verification має сенс для контрактів, які: керують значним TVL, оновлюються рідко, мають чітко формалізовані інваріанти. Для продуктів, що швидко ітеруються, співвідношення витрат і користі не на користь верифікації.

Вектори атак, які пропускають джуніор‑аудитори

Storage collision в proxy патерні. Transparent proxy і UUPS використовують конкретні слоти для зберігання адреси імплементації (EIP‑1967). Якщо в імплементації випадково оголошена змінна в слоті 0, яка перетинається з proxy storage — отримуємо silent override. Slither це не впіймає, якщо proxy та імплементація в різних файлах.

Read‑only reentrancy. Класичний reentrancy guard захищає від зміни стану при рекурсивному виклику. Але якщо зовнішній контракт читає стан через view-функцію в середині транзакції — guard не допомагає. Кілька років тому Curve pools стали вектором атаки саме через це: зовнішній протокол читав get_virtual_price під час reentrancy‑вразливого стану Curve.

Oracle manipulation через TWAP. Spot price — стандартна ціль для flash loan атаки. TWAP складніше маніпулювати, але не неможливо: на малоліквідних парах Uniswap v2 можна зсунути TWAP за кілька блоків при достатньому капіталі. Правильний захист — використовувати Chainlink як primary oracle з TWAP як fallback, з перевіркою deviation threshold.

Gas griefing на unbounded loop. Функція ітерується по масиву користувачів. Атакуючий додає тисячі адрес з нульовими балансами — вартість виклику функції зростає до gas limit, функція стає недоступною. Захист: pull‑pattern замість push, обмеження довжини масивів, batch‑обробка зі збереженням позиції.

Front‑running на MEV. Транзакція видна в mempool до включення в блок. MEV‑бот бачить addLiquidity на значну суму, вставляє свій swap перед нею (sandwich attack). Для AMM це частина моделі. Для протоколів з ціновими функціями — потрібен minAmountOut / deadline параметр і його обов'язкова перевірка.

Структура повного аудиту

  1. Scope definition і автоматичний аналіз (1‑2 дні). Фіксуємо commit hash, версію компілятора, список out‑of‑scope. Запускаємо Slither, Mythril, Aderyn. Triage: відокремлюємо реальні критичні баги від false positive. Складаємо карту залежностей контрактів.

  2. Ручний аналіз (5‑15 днів). Кожен контракт порядково. Особлива увага: всі external і public функції, всі transfer/call/delegatecall, всі місця, де змінюється стан перед перевіркою або після зовнішнього виклику, всі математичні операції з участю користувацьких inputs. В середньому 95% знайдених уразливостей — логічні, а не технічні.

  3. Fuzzing і тестування (2‑5 днів). Echidna або Foundry invariant tests для критичних інваріантів. Fork mainnet тести — перевіряємо поведінку в реальному оточенні з реальними оракулами. Наприклад, за 4 дні fuzzing знаходить в середньому 3 edge cases, не покритих unit‑тестами.

  4. Звіт і мітигація. Звіт з severity (Critical/High/Medium/Low/Informational), описом вектора атаки, PoC‑кодом для Critical/High. Розробники виправляють, аудитори роблять re‑audit виправлень.

Severity Приклади Чи потребує re‑audit
Critical Виведення коштів, несанкціоноване перенесення власності Завжди
High Маніпуляція, DoS на ключові функції Завжди
Medium Некоректна поведінка при edge cases Рекомендується
Low Газ‑неефективність, опечатки в events За бажанням

Аудит у CI/CD

Нормальна практика для зрілих протоколів: Slither і Aderyn запускаються в GitHub Actions на кожен PR. Certora Prover — на merge в main. Це не замінює повний аудит перед деплоєм, але ловить регресії.

# .github/workflows/audit.yml
- name: Run Slither
  uses: crytic/[email protected]
  with:
    target: 'src/'
    slither-args: '--filter-paths "test|mock|script"'
Чек‑лист обов'язкових перевірок перед деплоєм
  • Всі external функції мають перевірки доступу (onlyOwner, onlyRole)
  • Використання SafeERC20 для зовнішніх токенів
  • Відсутність delegatecall на невідомі адреси
  • Перевірка на reentrancy у всіх функціях з зовнішніми викликами
  • Наявність minAmountOut і deadline в AMM‑функціях
  • Використання перевіреного оракула (Chainlink) з deviation threshold

Інструменти аудиту: порівняння

Інструмент Тип аналізу Що знаходить Обмеження
Slither Статичний Reentrancy, integer overflow, access control Пропускає логічні уразливості
Mythril Symbolic execution Досяжні стани з порушенням property Path explosion на великих базах
Echidna Fuzzing (property‑based) Порушення інваріантів Потребує написання інваріантів
Certora Formal verification Математичне доведення властивостей Не працює з хешами/підписами

Що входить в роботу (deliverables)

  • Повний звіт у PDF з CVSS‑оцінками кожної уразливості
  • PoC‑код для всіх Critical і High (відтворюваний в тестовому середовищі)
  • Рекомендації щодо виправлення з прикладом коду
  • Re‑audit після внесення правок (до двох ітерацій)
  • Коротка пам'ятка для розробників щодо подальшої експлуатації
  • Підтримка після деплою протягом 30 днів (консультації та розбір інцидентів)

Терміни

Аудит простого токена або NFT‑контракту — 3‑5 робочих днів. DeFi протокол з lending/AMM — 2‑4 тижні. Повний стек з кількома протоколами, cross‑chain, proxy upgrades — 4‑8 тижнів. Re‑audit виправлень — 3‑7 днів окремо.

Наша команда має 7+ років досвіду в безпеці смарт‑контрактів, перевірила 100+ проектів з сумарним TVL понад значну суму. Гарантуємо, що в процесі ми не пропустимо жоден відомий вектор — використовуємо ліцензовані версії Slither та найкращі конфігурації fuzzer'ів. Запобігнуті збитки для клієнтів оцінюються в значну суму.

Оцініть ваш проект — ми безкоштовно проаналізуємо код і запропонуємо комерційну пропозицію протягом 2 днів. Замовте аудит з гарантією якості та отримайте знижку на re‑audit при повторному зверненні.