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

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска 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 через crowdsourcing с доменными экспертами. Каждый пример размечается минимум тремя аннотаторами, 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+ проектов по классификации контента. Экономия от предотвращения потерь на фейковых новостях может достигать сотен тысяч долларов. Свяжитесь с нами для оценки вашего проекта — мы подберём оптимальное решение. Закажите разработку модели уже сегодня.

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

Когда протокол теряет $197M через 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 имеет смысл для контрактов, которые: управляют > $50M, обновляются редко, имеют чётко формализуемые инварианты. Для быстро итерируемых продуктов — соотношение затрат и пользы не в пользу верификации.

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

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 (Wikipedia).

Oracle manipulation через TWAP. Spot price — стандартная цель для flash loan атаки (Wikipedia). 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 Drain funds, unauthorized ownership transfer Всегда
High Manipulation, 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 > $3B. Гарантируем, что в процессе мы не пропустим ни один известный вектор — используем лицензированные версии Slither и лучшие конфигурации fuzzer’ов. Предотвращённые убытки для клиентов оцениваются более чем в $50M.

Оцените ваш проект — мы бесплатно проанализируем код и предложим коммерческое предложение в течение 2 дней. Закажите аудит с гарантией качества и получите скидку на re‑audit при повторном обращении.