Репутация в 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).
Сore 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.
Что такое 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, схемы 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.
Как интегрировать 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 с базовыми attestations и API — 4-6 недель.