Репутація в 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 атестації в проєкт: покроково
- Визначте схему атестації: які дані будете підтверджувати.
- Розгорніть контракти EAS та зареєструйте схеми on-chain.
- Розробіть indexer для відстеження подій атестації.
- Реалізуйте REST API для читання та запису атестацій.
- Підготуйте 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 тижнів.







