Blockchain System Design (FAANG)

На собеседовании в Coinbase вам дают маркер и говорят: «Спроектируйте DEX, который обрабатывает $1 млрд в день». У вас 45 минут. Вы рисуете квадратики на доске - Router, Factory, Pair - и интервьюер кивает. Потом спрашивает: «Что произойдёт, если MEV-бот увидит крупный ордер в mempool?» Или: «Как ваш bridge переживёт reorg на 50 блоков?» Или: «Почему вы выбрали блокчейн, а не PostgreSQL?» За 2021-2023 годы хаки мостов стоили $2.5 млрд. Неправильная архитектура - это не абстрактная ошибка, а реальные потерянные деньги. В этом уроке - три system design задачи уровня FAANG: DEX, bridge, indexer, и фреймворк для главного вопроса: когда блокчейн вообще нужен.

• **Uniswap** - 50 строк ядра AMM обрабатывают 1-3 млрд ежедневно. На интервью в Paradigm просят воспроизвести архитектуру Factory → Router → Pair и объяснить каждый trade-off
• **Wormhole** потерял 326M из-за бага в signature verification. На собеседовании в Bridge-компании спрашивают: «Как бы вы предотвратили этот хак?» Ответ - в модели безопасности и circuit breakers
• **The Graph** индексирует 40+ блокчейнов и обрабатывает 1 млрд+ запросов в день. System design задача «build an indexer» проверяет понимание event processing, chain reorgs и database trade-offs

Предварительные знания

• AMM: Uniswap and Constant Product
• Bridges and Cross-Chain Communication
• Indexing: The Graph and Subgraphs

System Design: построить DEX

На FAANG-интервью задача «Design a DEX» проверяет понимание всей вертикали: от UX до смарт-контрактов. Начинаем, как в любом system design - с **requirements gathering**. Функциональные: обмен токенов, добавление ликвидности, просмотр цен. Нефункциональные: latency < 2 секунд для отображения цены, finality обмена за 1 блок, поддержка 10,000+ токенов.

Первое архитектурное решение: **AMM vs order book**. On-chain order book (dYdX V3, Serum) даёт привычный UX для трейдеров, но каждое размещение и отмена заявки - это транзакция с gas. На Ethereum при base fee 30 gwei одна операция стоит ~$5-15. Маркетмейкер, обновляющий заявки 10 раз в секунду, тратил бы $4.3M в день только на gas. AMM (Uniswap) решает эту проблему: одна формула `x * y = k` заменяет весь order book engine.

**Factory pattern** - краеугольный камень архитектуры. `Factory` контракт создаёт `Pair` контракты по шаблону через `CREATE2`. Каждая пара токенов - отдельный контракт с собственными резервами. `Router` - единственный контракт, с которым взаимодействует пользователь: он находит нужный `Pair` через `Factory`, рассчитывает оптимальный путь обмена (ETH → USDC → DAI, если прямого пула нет) и выполняет мультихоп-своп за одну транзакцию.

**Price Oracle - критический компонент.** DEX не может полагаться только на spot price (текущее соотношение резервов) - его слишком просто манипулировать одной транзакцией. Uniswap V2 ввёл **TWAP (Time-Weighted Average Price)** - средневзвешенную цену за N блоков. V3 использует **геометрическую среднюю** через массив observations. TWAP устойчив к flash loan атакам, потому что манипуляция требует удержания искажённой цены в течение многих блоков.

**Масштабирование DEX** - главный trade-off: L1 vs L2. На Ethereum mainnet один своп стоит $5-50 в gas. На L2 (Arbitrum, Base) - $0.01-0.50. Но ликвидность фрагментируется: ETH/USDC на Arbitrum и ETH/USDC на Base - это разные пулы с разной глубиной. Решения: **cross-chain aggregators** (1inch Fusion), **intent-based protocols** (UniswapX), и **shared sequencers** для atomic cross-L2 свопов.

System Design: построить cross-chain bridge

Cross-chain bridge - одна из самых сложных задач в blockchain system design. За 2021-2023 годы хаки мостов принесли убытков более **$2.5 млрд**: Ronin ($625M), Wormhole ($326M), Nomad ($190M), Harmony (100M). Мост - это smart contract на цепочке A, smart contract на цепочке B, и **off-chain relayer** между ними. Каждый компонент - вектор атаки.

Первый архитектурный выбор: **модель безопасности**. Существуют три фундаментальных подхода, каждый с разным trust model. **Multisig** (Multichain, Ronin) - N из M валидаторов подтверждают транзакцию. Быстро и дёшево, но требует доверия к валидаторам. **Light client** (IBC, Rainbow Bridge) - верифицирует консенсус исходной цепочки on-chain. Trustless, но дорого в gas. **ZK-proof** (zkBridge, Succinct) - генерирует криптографическое доказательство без раскрытия данных. Trustless и дешёвый для верификации, но дорогой для генерации proof.

**Key Management - самое слабое звено.** Ronin Bridge (625M) взломали через социальную инженерию: 5 из 9 валидаторов были скомпрометированы, причём 4 принадлежали одной организации (Sky Mavis). Правила: ключи на разных HSM, географическое распределение, ротация каждые 90 дней, threshold signatures (TSS) вместо обычного multisig, и mandatory delay (timelock) для крупных транзакций.

**Attack vectors и mitigation.** Помимо компрометации ключей: 1. **Replay attack** - повторная отправка старой транзакции; защита: уникальный nonce + mapping использованных nonce. 2. **Fake finality** - отправка proof до достижения finality; защита: ожидание N подтверждений, настроенных под каждую цепочку. 3. **Price oracle manipulation** - искажение курса обмена; защита: TWAP + rate limiter. 4. **Relayer censorship** - relayer отказывается передавать транзакции; защита: децентрализация relayer-сети и forced exit механизм.

**Lock-and-Mint vs Liquidity Network.** Lock-and-mint - мост «чеканит» wrapped-токен на целевой цепочке. Проблема: wrapped USDC на Arbitrum (USDC.e) и нативный USDC (bridged от Circle) - разные токены. **Liquidity Network** (Connext, Hop Protocol) решает иначе: ликвидность заранее размещена на обеих цепочках, и мост просто координирует свопы. Быстрее, но требует LP с капиталом на каждой цепочке.

System Design: построить blockchain indexer

Блокчейн - ужасная база данных для чтения. Хочешь узнать баланс ERC-20 токена? Вызови `balanceOf()` - один RPC-вызов. Хочешь историю всех переводов? Прочитай **все блоки** с момента деплоя контракта и отфильтруй нужные события. Для Ethereum это ~20M блоков, ~2B транзакций, ~50TB данных. Один запрос «покажи мне мои транзакции за последний год» занял бы часы. **Blockchain indexer** решает эту проблему: он читает блокчейн один раз, структурирует данные и предоставляет быстрый API.

**Выбор базы данных** зависит от паттернов доступа. **PostgreSQL** - для транзакционных запросов: «баланс пользователя», «история переводов по адресу», «список NFT владельца». Сильные стороны: ACID, индексы (B-tree по адресам, GIN по JSON), зрелая экосистема. Слабость: медленная аналитика по большим объёмам. **ClickHouse** - для аналитических запросов: «объём торгов за месяц», «средний gas по дням», «топ-100 контрактов по количеству вызовов». Column-oriented storage сжимает данные в 5-10x и сканирует миллиарды строк за секунды.

**API Design**: REST - для простых запросов (`GET /api/v1/transfers?address=0x...&limit=20`). **GraphQL** - для сложных запросов с произвольной вложенностью (The Graph использует именно его). **WebSocket** - для real-time подписок (`subscribe` на новые блоки, переводы, события конкретного контракта). Каждый тип API имеет свою стратегию кэширования: REST - `Cache-Control` + CDN по block number, GraphQL - response cache с invalidation по блокам, WebSocket - push при каждом новом блоке.

**Масштабирование на несколько цепочек** (Ethereum, Polygon, Arbitrum, Base) умножает каждую проблему. Разные форматы блоков, разное время блока (Ethereum ~12 сек, Polygon ~2 сек, Arbitrum ~0.25 сек), разная глубина reorg. Архитектура: один **chain adapter** на каждую цепочку (нормализует данные в единый формат), общий **processing pipeline** и **unified API** с фильтрацией по `chainId`.

**Кэширование**: данные блокчейна неизменяемы после finality. Блок 19,000,000 Ethereum никогда не изменится - его можно кэшировать навсегда. Стратегия: Redis с TTL = `block_time * confirmation_depth` для свежих данных, и бесконечный TTL для подтверждённых. Это уникальное свойство blockchain, которое не встречается в традиционных системах.

Blockchain Trilemma: масштабирование на практике

Виталик Бутерин сформулировал **blockchain trilemma** в 2017 году: из трёх свойств - **decentralization**, **security**, **scalability** - можно выбрать только два. Ethereum выбрал безопасность и децентрализацию (14 TPS, но 900,000+ валидаторов). Solana выбрала безопасность и масштабируемость (65,000 TPS, но ~2,000 валидаторов с дорогим оборудованием). BSC выбрала масштабируемость и (условную) безопасность (300 TPS, 21 валидатор - фактически centralized).

**Consistency vs Availability** - CAP-теорема применима и к блокчейну. Ethereum выбрал **consistency**: если сеть разделена (network partition), цепочка останавливается, но не создаёт конфликтующие версии состояния. Solana несколько раз демонстрировала обратный подход: при перегрузке сеть продолжала работать, но с повышенным процентом дропнутых транзакций. В 2022 году Solana останавливалась 7 раз - каждый раз выбирая consistency (остановка) вместо availability (работа с ошибками).

**Latency vs Throughput vs Decentralization** - ещё одна трёхсторонняя оптимизация. Solana достигает 400ms block time за счёт требования к hardware (256GB RAM, 12-core CPU, 10Gbps сеть). Ethereum - 12 сек, но работает на потребительском оборудовании. Cardano - 20 сек, но с формальной верификацией. Для конкретного приложения выбор зависит от UX-требований: DEX нужна низкая latency (пользователь не будет ждать 12 сек), а NFT marketplace может позволить 20 сек - пользователь ждёт минту.

**На FAANG-интервью ценится не ответ «blockchain», а обоснование.** Хороший ответ: «Для этой задачи blockchain избыточен, потому что все участники - подразделения одной компании и доверяют друг другу. PostgreSQL с append-only таблицей и цифровыми подписями даст те же гарантии в 100 раз дешевле.» Или: «Здесь blockchain необходим, потому что нужна trustless composability с существующими DeFi-протоколами - это невозможно воспроизвести вне цепочки.»

Итоги

• **DEX Architecture**: Factory создаёт Pair-контракты, Router обеспечивает маршрутизацию и slippage protection. Разделение позволяет обновлять Router без миграции ликвидности - паттерн, который интервьюеры ценят как пример separation of concerns
• **Bridge Security Model**: multisig (быстрый, но trust-based), light client (trustless, но дорогой), ZK-proof (trustless и дешёвый, но новый). При 500M+ TVL - только trustless модели, потому что компрометация ключей = потеря всего
• **Indexer Pipeline**: block fetcher → event decoder → transform → storage → API. Главная ловушка - chain reorganization: без корректной обработки reorg данные в индексе расходятся с реальным состоянием блокчейна
• **Blockchain Trilemma**: decentralization, security, scalability - выберите два. L2 rollups - попытка «сломать» трилемму, перенося execution off-chain при сохранении security L1
• В начале урока был вопрос «почему не PostgreSQL?» - и ответ не всегда «блокчейн». 95% проектов не нуждаются в trustless coordination. Хороший архитектор знает, когда НЕ использовать технологию - это ценится на FAANG-интервью не меньше, чем умение её проектировать

Связанные темы

System design объединяет все предыдущие темы и готовит к масштабированию:

• AMM: Uniswap и constant product — DEX-дизайн опирается на понимание AMM: формула x*y=k, liquidity pools, impermanent loss - всё это архитектурные решения, которые нужно объяснить на собеседовании
• Cross-chain Bridges — Bridge design требует понимания моделей безопасности (multisig, light client, ZK), finality каждой цепочки и паттернов key management
• Blockchain Indexing — Indexer design основан на event processing, chain reorgs и выборе базы данных - фундамент для любого blockchain-приложения с UI
• Blockchain at Scale — Следующий шаг: как всё это работает при 10M пользователей, multi-region deployment и real-time requirements

Вопросы для размышления

• Если бы вы проектировали DEX с нуля в 2026 году - выбрали бы AMM или on-chain order book? L2 rollup сделал gas дешёвым - меняет ли это фундаментальный trade-off, который привёл к изобретению AMM?
• Все крупные хаки мостов (2.5B+) произошли на уровне off-chain компонентов (ключи, валидаторы), а не в самих смарт-контрактах. Означает ли это, что smart contract security переоценена, а infrastructure security недооценена?
• Фреймворк «blockchain vs traditional DB» показывает, что большинство проектов не нуждаются в блокчейне. Но многие успешные компании (IBM Hyperledger, ConsenSys) строят бизнес именно на enterprise blockchain. Кто ошибается - фреймворк или рынок?

Связанные уроки

• sd-01-intro