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

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

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

Часті запитання

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

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

Репутація в 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 — зважена сума сигналів. Приклад моделі:

Сигнал Максимальна вага Логіка
Wallet age > 1 year 20 log(days / 365) * 20
Transaction volume 25 log10(volume_usd) * 5, cap 25
Governance participation 15 votes_cast / eligible * 15
Attestations from trusted 30 sum(attester_weight)
SBT count 10 min(sbt_count * 2, 10)

Логарифмічне масштабування запобігає домінуванню великих 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 вже сьогодні. Беремо проєкти як під ключ, так і на доопрацювання існуючих рішень.

Компонент Технологія Складність
Attestations EAS Середня
SBT ERC-5192 + OpenZeppelin Низька
Indexing The Graph (AssemblyScript) Середня
ZK proofs Circom + snarkjs або Noir Висока
Cross-chain LayerZero або Merkle bridge Висока
API Node.js + TypeScript Низька

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