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

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

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

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

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

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

Attestation в EAS — підписана запись: "attester X стверджує, що subject Y має властивість Z". Властивість Z визначається схемою — структурованими даними зареєстрованими on-chain.

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

// Attestation виглядає так:
{
    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 — конкретні вимірні факти:

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

Derived scores — агрегація core signals у числовий рейтинг. Проблема: формула агрегації — політичне рішення, і її централізована зміна змінює репутацію задним числом. Рішення: зберігати core signals on-chain, агрегацію робити off-chain (upgradeable) або через 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 добре працює для дискретних credentials (завершив аудит, брав участь у 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-critical даних неприйнятно.

Рішення:

• 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 primitives з готовою інфраструктурою.

Агрегація та ваги

Репутаційний 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 днів: через 6 місяців без активності репутація уполовинюється.

Інтеграція з існуючими протоколами

Gitcoin Passport — агрегатор Web2/Web3 identity сигналів (GitHub, Twitter, ENS, POAP). Passport видає 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 (upgradeable алгоритм)
  ZK proof generation (для privacy-preserving запитів)

[Consumer Layer]
  On-chain: smart contract запити (Merkle proof або oracle)
  Off-chain: REST API, GraphQL
  Frontend: репутаційні компоненти дисплею

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

Фаза 1 — Архітектура (1-2 тижні): визначення core signals, EAS attestation схем, privacy модель, cross-chain вимоги.

Фаза 2 — Core Contracts (2-3 тижні): EAS схеми, SBT контракти (якщо потрібні), on-chain агрегація якщо потрібна.

Фаза 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 тижні): репутаційний dashboard, attestation UI, інтеграція з consumer dApps.

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