Проектування архітектури блокчейн-проекту
Архітектура блокчейн-проекту — це рішення, які дорого змінювати пізніше: вибір мережі, contract upgrade strategy, oracle інтеграція, security model. Рік розробки і аудит роблять рефакторинг архітектури практично неможливим без повного переписування.
Архітектурні шари
Layer 1: Protocol Core (Smart Contracts)
Це immutable або мінімально змінювана логіка. Помилки тут — критичні уразливості.
Вибір Proxy Pattern:
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 архітектура:
Ієрархія ролей:
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 (Oracles та Indexers)
Oracle Strategy:
Price data (ціни токенів):
Primary: Chainlink Price Feeds
Secondary: Uniswap V3 TWAP (для токенів без Chainlink)
Fallback: Pyth Network
Manipulation protection:
- TWAP (Time-Weighted Average Price) замість spot price
- Circuit breaker: відхилити ціну якщо deviation > 20% від попередньої
- Multiple oracle aggregation (медіана з 3 джерел)
Custom oracle data (off-chain события):
- Chainlink Functions (HTTP requests в smart contracts)
- UMA Optimistic Oracle (для спорних даних з dispute window)
Indexing:
The Graph Protocol:
- Subgraph для історичних даних
- GraphQL API для frontend і third-party інтеграцій
- Децентралізований хостинг через 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 — альтернатива, більш гнучкий
- Custom keeper — якщо потрібна custom логіка
Layer 4: Frontend
Web3 stack:
- wagmi v2 + viem для Ethereum взаємодії
- 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 при ошибці
Multi-chain архітектура
Для протоколів, які работають на кількох мережах:
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 на власному bridge (повний контроль, але high audit cost)
Безпека як архітектурний принцип
Defense in depth:
- Smart contract рівень: Reentrancy guard, access control, pausable
- Protocol рівень: rate limits, circuit breakers, caps
- Governance рівень: timelock, multisig, guardian veto
- Monitoring рівень: Forta alerts, Defender autotasks
Інваріанти (неізмінні властивості системи):
"Сума всіх user balances ≤ totalDeposits"
"Після кожної транзакції collateral ratio ≥ minCollateral"
"Тільки whitelisted token addresses можуть бути deposited"
Інваріанти перевіряються через Foundry invariant tests — вони запускають тисячі random transaction sequences і перевіряють, що інваріанти ніколи не нарушаються.
Процес архітектурного проектування
Тиждень 1: Discovery — вивчення requirements, аналіз конкурентів, threat modeling.
Тиждень 2: Draft архітектури — contract діаграми, data flows, sequence діаграми.
Тиждень 3: Review і validation — обговорення з командою, перевірка на attack vectors, revision.
Тиждень 4: Final документація — Technical Architecture Document (TAD) з усіма рішеннями і rationale.
Результат: Technical Architecture Document з contract діаграмами, data flow діаграмами, security model і обґрунтуванням ключових рішень. Служить основою для ТЗ і референцю для аудиторів.