Интеграция Gitcoin Passport: anti-sybil защита dApp

Sybil-атаки — главная угроза для dApp, работающих с грантами, голосованиями или распределением токенов. В одном проекте мы обнаружили, что 30% активных кошельков были ботами, созданными для фарминга эирдропа. Вместо самописной KYC, которая потребовала бы 2-3 месяцев работы команды, внедрили Gitcoin Passport за 2 дня и отсекли 95% sybil-аккаунтов. Наш опыт — 5 лет в Web3, более 50 интеграций identity-решений.

Пользователь собирает stamps — подтверждения из 40+ источников (GitHub, Twitter, ENS, BrightID, on-chain активность), а протокол вычисляет identity-score от 0 до 100. dApp на основе score решает: пускать, ограничить или блокировать. Ниже — реальные блоки кода и сравнения, чтобы вы могли оценить усилия.

Почему Gitcoin Passport лучше самописной KYC?

Разработка собственной системы верификации требует 2–3 месяцев работы двух разработчиков — это $30,000–$50,000 бюджета. Gitcoin Passport решает задачу за 1–3 дня со стоимостью от $2,500. При этом он децентрализован: данные хранятся у пользователя, а score вычисляется off-chain или on-chain. Gitcoin Passport предоставляет децентрализованный набор identity credentials, который проверяется без раскрытия приватности. Газовые затраты — только при on-chain верификации (~0.001 ETH за проверку).

Сравните способы интеграции:

Какие stamps поддерживаются?

Gitcoin Passport собирает данные из двадцати провайдеров: GitHub (аккаунт старше 90 дней), Twitter (верифицирован), ENS (домен старше 30 дней), BrightID, Proof of Humanity, активность в DeFi протоколах. Каждый stamp добавляет баллы к score. Например, GitHub — 5, ENS — 3, BrightID — 7, Dework — 2. Порог доступа настраивается: обычно 15–20 баллов хватает, чтобы отсечь 95% sybil-аккаунтов. Мы помогли одному DeFi-проекту настроить порог 20 баллов — фармеры не смогли обойти, а легитимные пользователи прошли без проблем.

Что такое identity-score и как он рассчитывается?

Score вычисляется агрегатором Gitcoin по формуле с весами. Чем больше уникальных и проверяемых stamp-ов, тем выше score. Например, подключение BrightID — один из самых надёжных, даёт 7 баллов. ENS домен старше 6 месяцев — ещё 5. Если пользователь собрал 6 разных stamp-ов, score достигает 20+ — этого достаточно для доступа к грантам и голосованиям. Мы помогли проекту настроить кастомную формулу: комбинировать stamps с on-chain историей (количество транзакций, возраст кошелька).

Как мы интегрируем Gitcoin Passport: проверенный стек

Используем актуальные версии инструментов: Solidity 0.8.x, TypeScript, React (wagmi + RainbowKit), ethers.js. Ниже — код из реализованных проектов.

Интеграция через Passport SDK

import PassportVerifier from '@gitcoinco/passport-sdk-verifier';

const verifier = new PassportVerifier();

async function checkPassport(address: string) {
    const passport = await verifier.verifyPassport(address);
    const score = await verifier.getPassportScore(address);
    return { hasPassport: !!passport, score, stamps: passport?.stamps || [] };
}

On-chain интеграция через EAS

Gitcoin предоставляет scorer API и on-chain attestations через EAS (Ethereum Attestation Service). Пример смарт-контракта с порогом скора:

interface IGitcoinPassportDecoder {
    function getScore(address user) external view returns (uint256);
    function getPassport(address user) external view returns (Credential[] memory);
}

contract ProtectedFeature {
    IGitcoinPassportDecoder passport;
    uint256 public constant MIN_SCORE = 15;
    
    modifier requiresPassport() {
        require(passport.getScore(msg.sender) >= MIN_SCORE, "Gitcoin Passport score too low");
        _;
    }
    
    function accessGatedFeature() external requiresPassport { }
}

Серверная интеграция через Scorer API

const response = await fetch(
    `https://api.scorer.gitcoin.co/registry/score/${SCORER_ID}/${walletAddress}`,
    { headers: { 'X-API-Key': process.env.GITCOIN_API_KEY } }
);
const { score, passing_score } = await response.json();

Как выбрать между SDK и on-chain?

Passport SDK в 3 раза быстрее в развёртывании — не требует написания контракта и оплаты газа. On-chain даёт атомарность: проверка и действие в одной транзакции. Для большинства DeFi-приложений хватает SDK. Если нужна защита от обхода на уровне RPC или автономность от сервера — используйте on-chain.

Типичные ошибки новичков

• Установка слишком низкого порога (score < 10) — пропускает ботов.
• Отсутствие fallback на обновление stamps — пользователь не может пересчитать score после добавления новых.
• Игнорирование региональных провайдеров (BrightID) — снижает охват.

Что входит в нашу работу

• Аудит архитектуры dApp и выбор метода.
• Настройка SDK/контракта/API под ваш стек.
• Разработка кастомных порогов скора (например, разные уровни доступа).
• Тестирование устойчивости к sybil-атакам с помощью fuzzing.
• Документация и обучение команды.

Этапы работ

1. Аналитика — изучаем сценарии использования identity-score.
2. Проектирование — выбираем метод, проектируем контракты/эндпоинты.
3. Реализация — пишем код, подключаем тестовую сеть.
4. Тестирование — нагрузочное тестирование, аудит.
5. Деплой — публикуем в mainnet, настраиваем мониторинг.

Сроки и стоимость

Базовая интеграция — от 1 до 3 дней. Сложные проекты (несколько сетей, асинхронная верификация) — до 2 недель. Стоимость рассчитывается индивидуально, фиксируется до старта. Пример: одна из дефи dApp сэкономил $12,000 на разработке собственной системы, выбрав Gitcoin Passport. Защитите ваш dApp от sybil-атак уже сегодня. Свяжитесь с нами для оценки вашего проекта — наши инженеры с опытом в Web3 помогут настроить Gitcoin Passport под ваш сценарий.

Получите консультацию по интеграции Gitcoin Passport в ваш dApp. Закажите аудит и внедрение — мы предложим оптимальное решение.

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

Мы сталкиваемся с запросами, когда Web3-проект уже построил AMM-пул или lending-протокол, а потом осознаёт: сессионную авторизацию сделали через JWT и MongoDB. Это фундаментальное противоречие — приложение претендует на децентрализацию, но идентификация юзеров лежит на одном сервере. Для систем цифровой идентификации в Web3 такой подход неприемлем: он не отвечает compliance-требованиям (KYC для DeFi, accredited investors) и убивает on-chain репутацию в DAO. Мы специализируемся на разработке систем цифровой идентификации для Web3-проектов — начиная от SIWE и заканчивая полными DID/VC стеками. Наш опыт — 80+ проектов в блокчейне — показывает: архитектура 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 потеряли аккаунты из-за этого — в каждом случае восстановление стоило от $10 000 до $50 000.

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

SIWE надёжнее традиционных JWT-сессий: верификация подписи через ecrecover даёт доказательство владения ключом, а не просто знание пароля. Расходы на управление сессиями снижаются на 40–60% — не нужно хранить хеши паролей, не нужно сбрасывать сессии. Для крупного DeFi-протокола это экономия около $200 000 в год на инфраструктуре.

Что такое DID и какой метод выбрать?

DID (Decentralized Identifier) — стандарт W3C (см. Decentralized identifier в Wikipedia), строка 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) и не потребует переделки интерфейсов.

Как работает верификация через Verifiable Credentials?

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

Практический сценарий: 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. Сертифицированные инженеры нашей команды имеют опыт интеграции таких ZK-схем в реальные протоколы — клиенты экономят до 70% на KYC-расходах (средний check за год — около $200 000).

Почему Soulbound Tokens не подходят для mass adoption?

SBT (EIP-5192, концепция Vitalik Buterin) — NFT, который нельзя перевести. Реализация: стандартный ERC-721 с переопределённым transferFrom, всегда reverting. Или 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 протоколы используют его для under-collateralized loans.

Ключевое техническое ограничение: recovery mechanism. Потеря доступа к кошельку = потеря всех SBT. Без recovery нет mass adoption. Решения: social recovery wallet (Guardian, как в Argent), multi-key DID с ротацией, off-chain backup через Shamir Secret Sharing. Мы включаем проработку recovery в каждый проект SBT.

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

EAS развёрнут на Ethereum mainnet, Optimism, Arbitrum, Base. Любой адрес может выдавать on-chain или off-chain attestations по зарегистрированным схемам. Схема — ABI-encoded структура. Attester подписывает данные и записывает on-chain (с газом) или 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-инженера с профильным опытом. А также запишитесь на технический аудит вашей текущей системы идентификации — мы выявим узкие места и предложим конкретные улучшения.