Разработка системы репутации на блокчейне

Разработка системы репутации на блокчейне

Репутация в Web3 — одна из нерешённых задач. В Web2 репутация централизована: рейтинг Uber хранится у Uber, отзывы Amazon принадлежат Amazon. При смене платформы история обнуляется. Блокчейн-репутация должна решить это: verifiable, portable, censorship-resistant. Но реализовать её правильно значительно сложнее, чем кажется.

Модели репутационных систем

Attestation-based репутация

Наиболее распространённый подход — репутация как набор attestations (подтверждений) от других участников или протоколов. EAS (Ethereum Attestation Service) — стандартная инфраструктура для этого.

Attestation в EAS — это подписанная запись: "аттестатор X утверждает, что субъект Y имеет свойство Z". Свойство Z определяется схемой — структурированными данными, зарегистрированными on-chain.

// Схема для репутации разработчика
// "address developer, uint8 skill_level, bool verified_audit, string project_ref"

// Аттестация выглядит так:
{
    schemaUID: bytes32("..."),
    recipient: address("разработчик"),
    attester: address("протокол или DAo"),
    data: abi.encode(developer, skill_level, verified_audit, project_ref),
    time: block.timestamp,
    revocable: true
}

On-chain attestation — публична и верифицируема. Off-chain attestation (через EAS off-chain) — дешевле, но требует хранения вне сети (IPFS, Arweave).

Сcore vs derived репутация

Важная архитектурная концепция: core signals (первичные данные) vs derived scores (производные оценки).

Core signals — конкретные измеримые факты:

• Количество successful транзакций за N месяцев
• TVL под управлением (для DeFi позиций)
• Возраст кошелька
• Attestations от верифицированных источников
• Gitcoin Passport score
• Lens Protocol follower count

Derived scores — агрегация core signals в числовой рейтинг. Проблема: формула агрегации — политическое решение, и её централизованное изменение меняет репутацию задним числом. Решение: хранить core signals on-chain, агрегацию делать off-chain (upgradeable) или through governance.

Token-based репутация (SBT)

Soulbound Tokens (EIP-5192, EIP-4973) — non-transferable токены, привязанные к адресу. Нельзя купить, продать, передать — только заработать.

interface IERC5192 {
    event Locked(uint256 tokenId);
    event Unlocked(uint256 tokenId);
    function locked(uint256 tokenId) external view returns (bool);
}

contract ReputationSBT is ERC721, IERC5192 {
    mapping(uint256 => bool) private _locked;
    
    function _beforeTokenTransfer(
        address from,
        address to,
        uint256 tokenId,
        uint256 batchSize
    ) internal override {
        // Разрешаем только mint (from == 0) и burn (to == 0)
        require(from == address(0) || to == address(0), "Soulbound: non-transferable");
    }
    
    function locked(uint256 tokenId) external view override returns (bool) {
        return _locked[tokenId];
    }
}

SBT хорошо работает для дискретных credential (завершил аудит, участвовал в governance). Плохо — для непрерывных метрик (рейтинг постоянно меняется).

Ключевые технические проблемы

Sybil resistance

Главная атака на репутационные системы — создание множества адресов для накручивания репутации. Защита требует привязки к чему-то scarce: биометрия (WorldCoin), социальный граф (Proof of Humanity), PoW-подобная работа (BrightID).

Для большинства проектов: комбинация минимального on-chain age (кошелёк старше 6 месяцев), минимального activity threshold, и опционального social verification (ENS домен, Twitter/X верификация).

Privacy: публичная репутация как DoS

Полностью публичная on-chain репутация — проблема. Зная адрес, можно видеть всю историю действий. Для business-критических данных это неприемлемо.

Решения:

• ZK attestations: доказываешь что репутация > threshold, не раскрывая точный score. Circom/snarkjs схема, Noir — современный DSL.
• Pseudonymous attestations: attestation привязан к pseudonymous identifier, не к основному кошельку. Связь между pseudonym и реальным кошельком знает только пользователь.
• Selective disclosure: Verifiable Credentials (W3C стандарт) с ZK proof — раскрываешь только нужное утверждение.

Cross-chain репутация

Репутация на Ethereum не видна контракту на Polygon без bridge. Решения:

• Off-chain indexer + Merkle proof: индексируем все attestations, строим Merkle tree, пользователь предъявляет proof на любой чейн.
• LayerZero message: репутационный контракт на Ethereum посылает state через LayerZero на другие чейны.
• Self Protocol / Lens Protocol: cross-chain reputation примитивы с готовой инфраструктурой.

Агрегация и веса

Репутационный score — взвешенная сумма сигналов. Пример модели:

Логарифмическое масштабирование предотвращает доминирование крупных holders. Cap на каждый сигнал — нет single point of manipulation.

Decay функция

Репутация должна отражать текущее поведение, не только прошлое. Временной decay:

function getDecayedScore(score: number, lastActivityTimestamp: number): number {
  const daysSinceActivity = (Date.now() / 1000 - lastActivityTimestamp) / 86400;
  const decayFactor = Math.exp(-daysSinceActivity / HALF_LIFE_DAYS); // экспоненциальный decay
  return score * decayFactor;
}

HALF_LIFE_DAYS — параметр системы. 180 дней: через полгода без активности репутация уполовинивается.

Интеграция с существующими протоколами

Gitcoin Passport — агрегатор Web2/Web3 identity signals (GitHub, Twitter, ENS, POAP). Паспорт выдаёт score как Stamp-based репутацию. API для проверки: GET https://api.scorer.gitcoin.co/registry/score/{scorer_id}/{address}.

Lens Protocol — on-chain социальный граф. Followers, publications, mirrors — всё on-chain на Polygon. Подписка на Lens profile как сигнал репутации.

POAP — Proof of Attendance Protocol. NFT за участие в реальных и виртуальных событиях. POAP коллекция — косвенный сигнал активности в сообществе.

Guild.xyz — role-based access через репутационные условия. Интеграция Guild позволяет добавить репутационный gate без кастомной разработки.

Архитектура системы

[Core Signals Layer]
  On-chain: transaction history, token holdings, SBTs
  Off-chain: ENS, social graphs, POAP, Gitcoin Passport

[Attestation Layer]
  EAS on-chain attestations (схемы + записи)
  Off-chain EAS (подписанные, хранятся в IPFS)

[Aggregation Layer]
  Off-chain indexer (The Graph subgraph)
  Score calculation service (updatable algorithm)
  ZK proof generation (для privacy-preserving queries)

[Consumer Layer]
  On-chain: smart contract queries (Merkle proof или oracle)
  Off-chain: REST API, GraphQL
  Frontend: reputation display components

Процесс разработки

Фаза 1 — Архитектура (1-2 недели): определение core signals, схемы attestations в EAS, privacy модель, cross-chain требования.

Фаза 2 — Core contracts (2-3 недели): EAS схемы, SBT контракты (если нужны), on-chain aggregation если требуется.

Фаза 3 — Indexer и API (2-3 недели): The Graph subgraph для индексирования событий, score calculation сервис, REST/GraphQL API.

Фаза 4 — ZK layer (2-4 недели, если нужен): Circom схемы для privacy-preserving proof, verifier контракты.

Фаза 5 — Frontend (1-2 недели): reputation dashboard, attestation UI, интеграция с consumer dApps.

Полная production-ready система с privacy layer и cross-chain поддержкой — 3-4 месяца разработки. MVP с базовыми attestations и API — 4-6 недель.