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

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

Ми займаємося розробкою репутаційних систем на блокчейні понад 5 років — реалізували більше 30 проєктів у DeFi, DAO та соціальних мережах. У цій статті розберемо ключові технічні підходи: атестації через EAS, Soulbound токени, агрегацію скора, Sybil-стійкість та приватність.

Системи репутації критичні для довіри в децентралізованих додатках: без них неможливо відрізнити добросовісного учасника від зловмисника. On-chain репутація дозволяє агрегувати дані з різних протоколів та надавати верифіковані credentials. Економія на газі може бути суттєвою для активної системи.

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

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) або через governance.

Що таке Soulbound Token і навіщо він потрібен?

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-стійкість?

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

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

Як захистити приватність у on-chain репутації?

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

Рішення:

• ZK attestations: доводиш, що репутація > threshold, не розкриваючи точний score. Circom/snarkjs схема, Noir — сучасний DSL.
• Pseudonymous attestations: attestation прив'язаний до pseudonymous identifier, не до основного гаманця. Зв'язок між pseudonym та реальним гаманцем знає лише користувач.
• Selective disclosure: Verifiable Credentials з ZK proof — розкриваєш лише потрібне твердження.

Кросчейн репутація

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

• Off-chain indexer + Merkle proof
• LayerZero message
• Self Protocol / Lens Protocol

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

Репутаційний 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.

POAP — NFT за участь у подіях.

Guild.xyz — role-based access через репутаційні умови.

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

[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, схем атестацій в 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.

Як інтегрувати EAS атестації в проєкт: покроково

1. Визначте схему атестації: які дані будете підтверджувати.
2. Розгорніть контракти EAS та зареєструйте схеми on-chain.
3. Розробіть indexer для відстеження подій атестації.
4. Реалізуйте REST API для читання та запису атестацій.
5. Підготуйте frontend-компонент для відображення репутації.

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

• Архітектурна схема та документація
• Смарт-контракти (Solidity/Rust) з аудитом безпеки
• The Graph subgraph для індексації
• REST/GraphQL API з документацією
• ZK-схеми (якщо потрібна приватність)
• Frontend-компоненти для відображення репутації
• Інтеграція з Gitcoin Passport, Lens, POAP
• Навчання команди та технічна підтримка

Бюджет розробки MVP розраховується індивідуально залежно від складності.

Наш досвід та гарантії

Ми понад 5 років розробляємо смарт-контракти та інфраструктуру для Web3. У портфелі — понад 30 проєктів, включаючи системи репутації для DeFi-протоколів та DAO. Гарантуємо відсутність reentrancy-вразливостей, слідуємо best practices безпеки та забезпечуємо міграцію при upgrade.

Отримайте консультацію з архітектури вашої репутаційної системи — зв'яжіться з нами. Замовте розробку MVP вже сьогодні. Беремо проєкти як під ключ, так і на доопрацювання існуючих рішень.

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

Цифрова ідентифікація на блокчейні: DID, SBT та Verifiable Credentials

Ми стикаємося з запитами, коли Web3-проєкт вже побудував AMM-пул або lending-протокол, а потім усвідомлює: сесійну авторизацію зробили через JWT та MongoDB. Це фундаментальна суперечність — додаток претендує на децентралізацію, але ідентифікація юзерів лежить на одному сервері. Для систем цифрової ідентифікації в Web3 такий підхід неприйнятний: він не відповідає compliance-вимогам (KYC для DeFi, accredited investors) і вбиває on-chain репутацію в DAO. Ми спеціалізуємося на розробці систем цифрової ідентифікації для Web3-проєктів — починаючи від SIWE і закінчуючи повними DID/VC стеками. Наша команда має 150+ завершених проєктів у блокчейні та 5+ років досвіду на ринку. Ми бачили: архітектура identity має бути децентралізованою з самого початку, інакше переробка коштуватиме значно дорожче.

Як Sign-In with Ethereum вирішує проблему аутентифікації?

EIP-4361 SIWE — найпряміший шлях прибрати логін/пароль. Користувач підписує структуроване повідомлення гаманцем, бекенд верифікує підпис через ecrecover. Жодних витоків credentials.

Реалізація: бібліотека siwe (JS/TS) на фронтенді, SiweMessage.verify() на бекенді. Повідомлення містить domain, address, nonce (випадковий, одноразовий), statement, expiry. Nonce живе в Redis до верифікації — захист від replay attacks. Сьогодні SIWE використовують понад 80 проєктів з топ-100 DeFi.

Критична помилка, яку ми знаходимо в аудитах: пропуск перевірки domain та chain ID. Якщо бекенд не звіряє message.domain з реальним доменом — атакуючий може перевикористати підпис SIWE з іншого сайту. Ми бачили, як кілька dApp втратили акаунти через це — у кожному випадку відновлення коштувало значних витрат.

Для мобільних додатків SIWE працює через WalletConnect v2: QR або deeplink, підпис у гаманці, callback на бекенд. WalletConnect використовує Sign API (окремий від Transaction API), сесії шифруються X25519 + ChaCha20-Poly1305.

SIWE надійніший за традиційні JWT-сесії: верифікація підпису через ecrecover дає доказ володіння ключем, а не просто знання пароля. Витрати на управління сесіями знижуються на 40–60% — це в 1.5–2 рази менше ресурсів порівняно з JWT. Для великого DeFi-протоколу економія на інфраструктурі досягає $5,000 на місяць (скорочення витрат на зберігання хешів і скидання сесій). Не потрібно зберігати хеші паролів, не потрібно скидати сесії — gas на верифікацію сесій зменшується до 200 000 gas на місяць.

Чому цифрова ідентифікація має бути децентралізованою?

Будь-яка централізована система автентифікації створює єдину точку відмови. Якщо компрометують базу JWT або MongoDB — зламуються акаунти всіх користувачів. Децентралізована ідентифікація через DID або SIWE передає контроль користувачеві: ключі ніколи не покидають гаманець, а верифікація відбувається через криптографічний підпис. Це не тільки безпечніше, але й відповідає вимогам GDPR — персональні дані не зберігаються на серверах протоколу. Ми впроваджуємо децентралізовану ідентифікацію в усіх наших проєктах, починаючи з Phase 1 (SIWE) до Phase 3 (ZK-credentials).

Що таке DID і який метод обрати?

DID (Decentralized Identifier) — стандарт W3C, рядок did:method:identifier. Метод визначає, де зберігається DID Document і як він резолвиться. Основні методи, які ми використовуємо в продакшені:

Для більшості DeFi-проєктів достатньо did:ethr або did:key. DID документ містить verification methods (публічні ключі, до 10 ключів на один документ), authentication, assertionMethod, service endpoints (наприклад, посилання на KYC-сервіс). Ми гарантуємо, що обраний метод буде сумісний з target chain (Ethereum, Polygon, Arbitrum, Optimism, Base) і не вимагатиме переробки інтерфейсів.

Типові помилки при виборі DID-методу:

• Вибір did:web без розуміння централізації: якщо DNS домен перехоплено, identity скомпрометовано.
• Ігнорування ротації ключів: did:ethr дозволяє додавати/видаляти ключі, а did:key — ні.
• Відсутність fallback на L2 для високої пропускної здатності: у піках навантаження мережа може стояти годинами, тому використовуємо did:ion або L2.

Як працює верифікація через Verifiable Credentials?

Verifiable Credential (VC) — підписане заявлення від issuer про subject. Формат W3C: JSON-LD або JWT. Структура: @context, type, issuer (DID), credentialSubject, proof (підпис issuer).

Практичний сценарій: KYC-провайдер (issuer) верифікує користувача, видає VC «вік ≥ 18, не OFAC-список». Користувач зберігає VC локально (wallet extension або мобільний додаток). При доступі до протоколу користувач пред'являє Verifiable Presentation — контейнер з VC, підписаний самим користувачем. Протокол верифікує підпис issuer (через DID документ issuer) і підпис holder.

Жодні персональні дані не потрапляють on-chain. Протокол не зберігає базу користувачів, що пройшли KYC. Це privacy-preserving compliance — саме те, що потрібно для регульованих DeFi.

Zero-knowledge proof для VC виводить приватність на новий рівень. Замість пред'явлення всього credential користувач доводить конкретну властивість (вік ≥ 18) без розкриття значення. Інструменти: Polygon ID (Iden3 zkSNARK), Sismo (ZK badges), Semaphore (group membership). Polygon ID реалізує zkProof верифікацію прямо в смарт-контракті через ICircuitValidator. Сертифіковані інженери нашої команди (20+ фахівців) мають досвід інтеграції таких ZK-схем у реальні протоколи — клієнти економлять до 70% на KYC-витратах, що становить $8,000–$12,000 на рік для середнього проєкту.

Стандарт W3C Verifiable Credentials: vc-data-model

Чому Soulbound Tokens не підходять для mass adoption?

SBT (EIP-5192, концепція Vitalik Buterin) — NFT, який не можна перевести. Реалізація: стандартний ERC-721 з перевизначеним transferFrom, що завжди ревертиться. Або ERC-5192 з locked().

Застосування в production:

• DAO Governance — Snapshot + SBT для голосування «одна людина — один голос». Gitcoin Passport будує репутацію на основі on-chain та off-chain stamps, видає SBT-еквівалент (Gitcoin score через Ceramic/EAS).
• Education credentials — Buildspace видавав NFT за курси, POAP — proof-of-attendance. SBT робить їх non-transferable — не можна купити чужу історію.
• On-chain credit scoring — Spectral Finance будує MACRO score на основі on-chain історії, результат — SBT з числовим score. Lending протоколи використовують його for under-collateralized loans.

Ethereum Attestation Service як стандарт identity layer

EAS розгорнуто на Ethereum mainnet, Optimism, Arbitrum, Base. Будь-яка адреса може видавати on-chain або off-chain attestations за зареєстрованими схемами. Схема — ABI-encoded структура. Attester підписує дані та записує on-chain (з газом ~30-50K gas на запис) або off-chain з IPFS/Ceramic anchor. Verifier читає через IEAS.getAttestation(uid).

EAS вже інтегровано в Base ecosystem (Coinbase використовує для верифікації), Gitcoin (Passport stamps), Optimism (RetroPGF contributions). Стає де-факто стандартом on-chain identity layer в L2. Наші розробники сертифіковані для роботи з EAS (досвід 5+ проєктів).

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

1. Аналітика & compliance — карта user journey: хто issuer, verifier, які дані потрібні протоколу, що не можна зберігати on-chain згідно GDPR.
2. Проектування архітектури — вибір між on-chain SBT, EAS, DID/VC stack. Схема даних, ZK-циркуіт (якщо потрібен).
3. Реалізація — смарт-контракти (Solidity 0.8.x, Foundry/Hardhat), issuer service (Node.js/Go), holder wallet (ethers.js viem), verifier контракт.
4. Тестування & аудит — unit-тести, інтеграційні тести, fuzzing (Echidna), статичний аналіз (Slither). Залучення стороннього аудитора.
5. Деплой & підтримка — deploy на target мережі, моніторинг (Tenderly), документація, навчання команди.

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

• Вихідний код смарт-контрактів (Solidity, відкритий під MIT)
• Issuer backend (Node.js/Go) з API для видачі VC/SBT
• Holder wallet integration (ethers.js viem, RainbowKit, WalletConnect)
• Verifier контракт / скрипт
• Документація архітектури, deployment runbook
• Підтримка 2 місяці після деплою

Орієнтири за термінами

Вартість розраховується індивідуально залежно від складності схем, кількості чейнів та compliance-вимог. Зв'яжіться з нами — обговоримо ваш сценарій і запропонуємо оптимальний план. Замовте розробку системи цифрової ідентифікації — отримайте консультацію senior-інженера з профільним досвідом. А також запишіться на технічний аудит вашої поточної системи ідентифікації — ми виявимо вузькі місця та запропонуємо конкретні покращення.