Проектирование архитектуры блокчейн-проекта
Архитектура блокчейн-проекта — это решения которые дорого менять позже: выбор сети, contract upgrade strategy, oracle integration, модель безопасности. Год разработки и аудит делают рефакторинг архитектуры практически невозможным без complete rewrite.
Архитектурные слои
Layer 1: Protocol Core (смарт-контракты)
Это неизменяемая или минимально изменяемая логика. Ошибки здесь — критические уязвимости.
Proxy Pattern selection:
Transparent Proxy (OpenZeppelin):
+ Простой, battle-tested
- Admin не может использовать протокол как пользователь
- Лишний газ на selector check
UUPS (EIP-1822):
+ Меньше gas overhead
+ Upgrade логика в implementation
- Если implementation задеплоить без upgradeToAndCall → залоченный контракт навсегда
✓ Рекомендован для production
Diamond (EIP-2535):
+ Нет лимита размера контракта (24KB)
+ Множественные facets
- Сложно в аудите
- Только для сложных протоколов с >10 логических модулей
Access Control Architecture:
Иерархия ролей:
ROOT: 3-of-5 Gnosis Safe (founding team)
↓
TIMELOCK (48h): управление параметрами, upgrade
↓
GOVERNANCE: DAO голоса (для зрелых протоколов)
├── ADMIN: critical operations (pause, emergency)
├── OPERATOR: daily ops (setFee, setOracle)
└── RELAYER: automated operations (off-chain actors)
Layer 2: Data Layer (оракулы и индексеры)
Oracle Strategy:
Price data (token prices):
Primary: Chainlink Price Feeds
Secondary: Uniswap V3 TWAP (для tokens без Chainlink)
Fallback: Pyth Network
Manipulation protection:
- TWAP (Time-Weighted Average Price) вместо spot price
- Circuit breaker: reject price если deviation > 20% от предыдущего
- Multiple oracle aggregation (медиана из 3 источников)
Custom oracle data (off-chain events):
- Chainlink Functions (HTTP requests в смарт-контрактах)
- UMA Optimistic Oracle (для спорных данных с dispute window)
Indexing:
The Graph Protocol:
- Subgraph для исторических данных
- GraphQL API для frontend и third-party integrations
- Decentralized hosting через Graph Network
Moralis / Alchemy Webhooks:
- Real-time event notifications
- Быстрый ответ (< 1 секунда)
- Резервный источник если subgraph lag
Self-hosted indexer:
- Для данных специфичных для протокола
- PostgreSQL + Node.js event listener
- Используется если The Graph недостаточно гибкий
Layer 3: Off-chain Services
Backend (если нужен):
- Relayer для gasless transactions (EIP-2771 + Gelato)
- Order matching (для DEX с off-chain orderbook)
- Notification service (email/push при событиях)
- Analytics API
Keeper/Automation:
- Chainlink Automation (Keepers) — автоматические on-chain действия
- Gelato Network — альтернатива, более гибкий
- Собственный keeper — если нужен custom logic
Layer 4: Frontend
Web3 stack:
- wagmi v2 + viem для Ethereum interactions
- RainbowKit / ConnectKit для wallet connection UI
- React Query для async state management
- The Graph для исторических данных
Performance:
- Multicall3 для batching RPC calls (1 запрос вместо 20)
- Local simulation (Tenderly / fork) перед транзакцией
- Optimistic UI updates с rollback при ошибке
Мультичейн архитектура
Для протоколов которые работают на нескольких сетях:
Hub-and-Spoke model:
Ethereum Mainnet: governance, treasury, canonical token
L2s (Arbitrum, Base, Optimism): execution, liquidity
Cross-chain messaging:
LayerZero: universal messaging, любые сети
Wormhole: token bridge + messaging
Axelar: token transfer + contract calls
CCIP (Chainlink): enterprise-grade, строже и дороже
Token bridging:
Canonical bridge (более безопасно, медленно — 7 дней для Optimism)
Third-party bridge (быстро, но bridge hack риск)
Lock-and-mint on own bridge (полный контроль, но high audit cost)
Безопасность как архитектурный принцип
Defense in depth:
- Smart contract level: Reentrancy guard, access control, pausable
- Protocol level: rate limits, circuit breakers, caps
- Governance level: timelock, multisig, guardian veto
- Monitoring level: Forta alerts, Defender autotasks
Invariants (неизменяемые свойства системы):
"Сумма всех user balances ≤ totalDeposits"
"После каждой транзакции collateral ratio ≥ minCollateral"
"Только whitelisted token addresses могут быть deposited"
Invariants проверяются через Foundry invariant tests — они запускают тысячи random transaction sequences и проверяют что инварианты никогда не нарушаются.
Процесс архитектурного проектирования
Неделя 1: Discovery — изучение requirements, анализ конкурентов, threat model.
Неделя 2: Draft architecture — диаграммы контрактов, data flows, sequence diagrams.
Неделя 3: Review и validation — discussion с командой, проверка на attack vectors, revision.
Неделя 4: Final documentation — Technical Architecture Document (TAD) с всеми решениями и rationale.
Результат: Technical Architecture Document с contract diagrams, data flow diagrams, security model, и обоснованием ключевых решений. Служит основой для ТЗ и референсом для аудиторов.