CONTEXT Whitepaper

1. Аннотация

CONTEXT — это открытая децентрализованная P2P-сеть передачи сообщений, построенная поверх протокола libp2p с использованием криптографии Ed25519 и транспортного шифрования Noise Protocol. Система устраняет единую точку отказа традиционных мессенджеров: сообщения реплицируются между сетью независимых relay-узлов, работа которых мотивируется нативным токеном CTX.

Ключевые свойства системы:

• Отсутствие центрального сервера: все участники равнозначны, нет владельца инфраструктуры
• Криптографическая идентичность: PeerID = хеш от публичного ключа Ed25519
• E2E-совместимость: payload передаётся в зашифрованном виде на уровне приложения
• Экономическая мотивация: relay-операторы получают вознаграждение в CTX пропорционально uptime
• Устойчивость к цензуре: Tor-транспорт, Circuit Relay v2, DHT-discovery без центральных DNS
• Блокчейн-верифицируемость: каждое сообщение регистрируется в цепочке блоков (без payload)

---

2. Введение и мотивация

2.1 Проблема централизованных мессенджеров

Современные коммуникационные платформы (Telegram, WhatsApp, Signal) хранят метаданные и/или содержимое сообщений на серверах компании-оператора. Это создаёт системные риски:

2.2 Ограничения существующих децентрализованных решений

Существующие децентрализованные решения (Matrix, Session, Briar) имеют собственные компромиссы:

• Matrix: федеративная, но не P2P; сервер-домохозяин хранит все данные
• Session: onion-сеть с высокой задержкой; сложная UX
• Briar: работает без интернета через Bluetooth, но ограничена в масштабируемости
• XMPP: децентрализован, но федеративная модель воспроизводит доверие серверу

2.3 Подход CONTEXT

CONTEXT использует relay-архитектуру: специализированные узлы (relay) принимают сообщения от клиентов, временно хранят их и реплицируют между собой. Relay не являются «серверами» в традиционном смысле — любой может запустить собственный узел, а экономика сети мотивирует операторов к честному поведению через механизм стейкинга и slashing.

Клиент A → Relay-1 ←→ Relay-2 ←→ Relay-3 → Клиент B
                 ↕ DHT Discovery ↕
               (Kademlia / mDNS)

---

3. Архитектура системы

3.1 Топология сети

Сеть CONTEXT состоит из трёх типов узлов:

Ключевые ограничения топологии:

• Клиент ↔ Клиент: прямое соединение запрещено — весь трафик через relay
• Клиент подключается одновременно к 1–3 relay-узлам
• В пуле клиента обязательно минимум 1 публичный relay

3.2 Многоуровневая архитектура relay-узла

┌────────────────────────────────────────────────────┐
│                    Уровень 1: Транспорт              │
│   TCP + QUIC │ AutoNAT │ Circuit Relay v2 │ Tor      │
├────────────────────────────────────────────────────┤
│                    Уровень 2: Discovery              │
│   Kademlia DHT │ mDNS (LAN) │ GossipSub │ PubSub    │
├────────────────────────────────────────────────────┤
│                    Уровень 3: Протокол               │
│   /ctx/1.2  │  Framing  │  Stream Mux  │  Noise     │
├────────────────────────────────────────────────────┤
│                  Уровень 4: Бизнес-логика            │
│  Message Handler │ Replicator │ Auth Module │ VClock │
├────────────────────────────────────────────────────┤
│                    Уровень 5: Хранение               │
│   SQLite │ Unit of Work │ Message Repo │ Tombstones  │
└────────────────────────────────────────────────────┘

3.3 Компонентная схема

[libp2p Host]
     │
     ├─ [CTX Protocol Handler /ctx/1.2]
     │        ├─ [Auth Verifier] ← Ed25519 sig check
     │        ├─ [Rate Limiter] ← Token Bucket / PeerID
     │        ├─ [Unit of Work] ← транзакционность
     │        └─ [Replicator] → другие relay
     │
     ├─ [DHT Module] ← Kademlia peer discovery
     ├─ [GossipSub] ← pub/sub топики
     ├─ [AutoNAT] ← NAT type detection
     ├─ [Health Server] ← HTTP /health /ready
     └─ [Blockchain Node] ← Phase 2
              ├─ [TxPool]
              ├─ [BFT Validator]
              ├─ [EmissionService]
              ├─ [UptimeTracker]
              └─ [ContractEngine]

3.4 Жизненный цикл сообщения

1. Клиент формирует сообщение:
   - Генерирует UUID
   - Вычисляет SHA-256(payload) → hash_sum
   - Подписывает Ed25519(privkey, message_hash)

2. SEND /ctx/1.2 → Relay-1:
   - Relay валидирует подпись
   - Проверяет hash_sum
   - Rate-limit check (Token Bucket)
   - Проверяет timestamp ± 5 мин (replay protection)

3. Relay-1 сохраняет в SQLite:
   - UnitOfWork.Begin()
   - MessageRepo.Save(msg)
   - UnitOfWork.Commit()
   - ACK → Клиент

4. Eager Push репликация:
   - Relay-1 → Relay-2, Relay-3 асинхронно
   - REPLICATE action (relay→relay)
   - Дедупликация по MessageID на принимающей стороне

5. Push-уведомление (Phase 3):
   - Relay отправляет APNS/FCM/Huawei push
   - Получатель получает уведомление офлайн

6. Получатель онлайн:
   - FETCH /ctx/1.2 → любой Relay в пуле
   - Получает сообщения since_ts
   - Расшифровывает payload локально

7. Регистрация в блокчейне (Phase 2):
   - TxTypeMessageRegistration (без payload)
   - FullMessageHash = SHA-256(всё сообщение с payload)
   - Верифицируемость без раскрытия содержимого

---

4. CTX-протокол v1.2

4.1 Спецификация транспорта

CTX работает поверх libp2p streams с идентификатором /ctx/1.2/{ReceiverPeerID}.

Framing: каждое сообщение предваряется 4-байтовым big-endian length prefix:

┌──────────────┬─────────────────────────────────────┐
│   4 bytes    │           N bytes                    │
│  Big-Endian  │         JSON Payload                 │
│    Length    │                                      │
└──────────────┴─────────────────────────────────────┘

---

5. Криптография и безопасность

5.1 Идентификация узла

Каждый relay и клиент идентифицируется через Ed25519 keypair:

Ed25519 keypair → PeerID = multihash(SHA-256(pubkey))
Multiaddr: /ip4/{IP}/tcp/{PORT}/p2p/{PeerID}

Ключевая пара генерируется при первом запуске и сохраняется в файл identity.key. Утеря ключа означает потерю идентичности.

5.2 Транспортное шифрование

Noise Protocol (XX handshake pattern) обеспечивает:

• Взаимную аутентификацию обоих сторон
• Совершенную прямую секретность (PFS)
• Защиту от MITM-атак

Noise встроен в libp2p как дефолтный security transport — все соединения в сети CONTEXT зашифрованы автоматически.

5.3 Целостность сообщений

Каждое сообщение содержит:

• hash_sum = SHA-256(payload) — проверяется relay при приёме
• signature = Ed25519(privkey, message_bytes) — верифицирует отправителя

5.4 Connection Gater

Connection Gater работает на уровне TCP/QUIC-соединений:

• Blocklist PeerID, создавших повторные нарушения
• Блокировка выполняется до установки libp2p stream
• Минимальные вычислительные затраты на отклонение

5.5 Anti-Fraud (7 уровней) — Phase 2

При активированном блокчейн-режиме добавляется 7-уровневая система защиты от мошенничества:

---

6. Модели конфиденциальности

6.1 Публичный режим

В публичном режиме relay принимает и реплицирует любые сообщения без дополнительных проверок. Транспорт зашифрован (Noise), payload может быть зашифрован приложением, но relay не налагает ограничений.

Публичные каналы всегда работают в публичном режиме — их сообщения распространяются по всей сети.

6.2 Приватный режим

Приватный режим активируется на уровне relay через RELAY_PRIVATE_MODE=true. Работает на основе групповой аутентификации с тремя ключами:

Верификация принимающего relay:

Verify(AUTH_SERVICE_PUBKEY_src, ID_dst, NETSIGN_stored) = True

Верификация клиента:

Verify(AUTH_SERVICE_PUBKEY_relay, ID_client, NETSIGN_relay) = True

6.3 Правила маршрутизации приватных сообщений

Клиент отправляет IsPrivate=true → только на верифицированные приватные relay
Relay получает IsPrivate=true → реплицирует только в приватный кластер
Публичный relay получает IsPrivate=true → отклоняет при PRIVATE_MODE=true

6.4 Типы чатов

---

7. Блокчейн-ядро

7.1 Концепция

CONTEXT использует линейный блокчейн (не DAG, не шардинг в Phase 2) с характеристиками:

• Блок каждые 1 секунду
• До 10 000 транзакций в блоке
• Proof of Stake консенсус с BFT-валидацией
• Минимальный стейк: 100 CTX

Принцип разделения хранилищ:

• SQLite (data/peer.db) — сообщения и пиры (Phase 1, неизменно)
• Pebble (data/blockchain/, data/state/, data/contracts/) — блокчейн (Phase 2)

7.2 Структура блока

Block {
  Height:       uint64          // Монотонный номер
  Timestamp:    int64           // Unix nanoseconds
  PrevHash:     [32]byte        // SHA-256 предыдущего блока
  TxRoot:       [32]byte        // Merkle root транзакций
  StateRoot:    [32]byte        // Merkle root балансов
  ContractRoot: [32]byte        // Merkle root контрактов
  Transactions: []*Transaction  // Упорядоченный список
  ProposerAddr: Address         // Адрес валидатора-proposer
  Signatures:   []BlockSig      // BFT подписи валидаторов (≥⅔)
  Hash:         [32]byte        // SHA-256 блока (без Signatures)
}

7.3 Типы транзакций

7.4 Структура транзакции

Transaction {
  Hash:      [32]byte  // SHA-256(все поля без Signature)
  Type:      uint8     // Тип транзакции
  Timestamp: int64     // Unix nanoseconds
  Sender:    [20]byte  // Адрес из Ed25519 pubkey
  Recipient: [20]byte  // Адрес получателя
  Amount:    uint64    // В наименьших единицах (1 CTX = 10^8)
  Nonce:     uint64    // Порядковый номер (anti-replay)
  Data:      []byte    // Protobuf-данные (зависит от Type)

  // TxTypeMessageRegistration:
  MessageID:       string   // UUID сообщения
  FromPeer:        string   // libp2p PeerID
  FullMessageHash: [32]byte // SHA-256(full message with payload)
  IsPrivate:       bool
  LifeTime:        int

  // Подпись:
  SenderPubKey: []byte  // Ed25519 pubkey (32 байт)
  Signature:    []byte  // Ed25519 signature (64 байт)
}

7.5 BFT-консенсус

CONTEXT использует Byzantine Fault Tolerant консенсус:

Валидаторы = топ-N relay по размеру стейка
Proposer = детерминированный выбор из валидаторов (round-robin)
Commit = ≥⅔ подписей валидаторов за блок
Устойчивость: сеть продолжает работу при ≤⅓ недобросовестных нод

Checkpoint создаётся каждые N блоков и содержит:

• Merkle root транзакций
• Merkle root состояния (балансы)
• Merkle root контрактов
• Ed25519 подписи авторитетных нод

7.6 Регистрация сообщений в блокчейне

Каждое сообщение регистрируется в блокчейне без payload для экономии места:

TxTypeMessageRegistration:
  ✓ MessageID     → UUID сообщения
  ✓ FromPeer      → отправитель
  ✓ FullMessageHash → SHA-256(полное сообщение с payload)
  ✗ Payload       → НЕ записывается в блокчейн

FullMessageHash позволяет верифицировать целостность сообщения при репликации без хранения содержимого в публичном реестре.

---

9. Токеномика CTX

8.1 Параметры токена

8.2 Механизм эмиссии (Uptime Rewards)

Epoch = 24 часа. Эмиссия распределяется пропорционально uptime:

reward_i = emission_per_epoch × (uptime_i / total_uptime_eligible_peers)

Условия для получения вознаграждения:

• Uptime ≥ 1 час (3 600 секунд) за epoch
• Активна стейк-позиция ≥ 100 CTX
• Нет активных slash-санкций

Если нет подходящих пиров за epoch — эмиссия сжигается (направляется на Burn Address).

8.3 Halving-расписание

После 24 лет эмиссия фиксируется на символических 2 CTX/день как поощрение за поддержание инфраструктуры.

8.4 Стейкинг

Минимальный стейк:     1000 CTX
Lock-up период:        Эпоха (24 часа)
Вывод стейка:          После завершения epoch без нарушений
Slashing (double-sign): -100% стейка (сжигается)
Slashing (downtime):    -5% стейка при даунтайме > 1 часа

8.5 Механизм сжигания (Burn)

Burn создаёт дефляционное давление и обеспечивает утилизацию нераспределённой эмиссии:

Burn Address — детерминированный адрес без известного приватного ключа:

BurnAddress = SHA-512("CTX-Burn-Address-v1")[:20]

Любые токены, отправленные на этот адрес, безвозвратно выводятся из обращения. Попытки потратить средства с Burn Address отклоняются на уровне валидаторов.

8.6 Экономические стимулы

Сценарий роста сети (год 1):
  Эмиссия:              +46 720 CTX
  Burn (переводы):      -500 CTX (оценка)
  Burn (контракты):     -300 CTX (оценка)
  Burn (slashing):      -200 CTX (оценка)
  Чистая инфляция:      ≈ +45 720 CTX

Сценарий зрелой сети (год 10):
  Эмиссия:              +11 680 CTX
  Burn (все каналы):    -3 000 CTX (оценка)
  Чистая инфляция:      ≈ +8 680 CTX

---

9. Смарт-контракты

9.1 Концепция

CTX смарт-контракты — детерминированные, не-Turing-complete конструкции для управления сервисными сессиями. В отличие от EVM-контрактов:

• Нет произвольного исполняемого кода
• Нет циклов и сложного VM
• Фиксированные типы операций (escrow, settle, dispute)
• Хранятся в Pebble, регистрируются через транзакции

9.2 Типы сервисных нод

9.3 Жизненный цикл сессии

Провайдер публикует ServiceContract:
  └─ TxTypeContractDeploy → blockchain
     - ServiceType, Name, PricePerUnit
     - MinDeposit, SessionTTL
     - ProviderAddr, ProviderPubKey

Пользователь открывает сессию:
  └─ TxTypeContractCall → blockchain
     - DepositTxHash (заморозка CTX в escrow)
     - UserAddr, UserPubKey
     - ContractID

Использование сервиса:
  - Пользователь взаимодействует с сервисной нодой
  - Провайдер отслеживает потребление (UnitsConsumed)

Закрытие сессии:
  └─ TxTypeContractSettle → blockchain
     - Провайдер получает: Amount - 10% burn
     - Пользователь получает: Deposit - Amount
     - BurnAddress получает: 10% от Amount

Разрешение споров:
  └─ DisputeContract (оракул или голосование валидаторов)

9.4 Реестр контрактов

Все активные сервисные контракты хранятся в Registry:

• Поиск по ServiceType, ProviderAddr, PeerID
• Сортировка по репутации, цене, uptime
• Автоматическое исключение истёкших контрактов

---

10. Защита от мошенничества

10.1 Uptime Anti-Fraud

Uptime Tracker реализует 7-уровневую проверку heartbeat-сообщений для предотвращения фальсификации времени активности:

Уровень 1: Signature     — Ed25519 подпись heartbeat
Уровень 2: Sequence      — Monotonic counter (anti-replay)
Уровень 3: Timestamp     — Delta validation (Clock Skew ≤ 30s)
Уровень 4: Challenge     — Случайный challenge-response
Уровень 5: PoW micro     — Лёгкий hashcash для Sybil-защиты
Уровень 6: Attestation   — Верификация через другие ноды
Уровень 7: Auto-ban      — Исключение нарушителей

10.2 Double-Sign Protection

Если валидатор подписывает два разных блока на одной высоте:

1. BFT-валидаторы детектируют двойную подпись
2. TxTypeSlash транзакция → 100% стейка сжигается
3. PeerID включается в blocklist

10.3 Downtime Slashing

При отсутствии heartbeat более 1 часа и активном стейке:

• Uptime Tracker фиксирует нарушение
• -5% от стейка → TxTypeBurn
• Уведомление оператора через healthcheck endpoint

---

12. Desktop-кошелёк

12.1 Технологический стек

CTX Wallet — десктопное приложение с архитектурой:

• Backend: Go
• Нативные: macOS, Windows, Linux

11.2 Криптографические стандарты

Мнемоника (12/24 слова BIP-39)
         ↓ SLIP-0010
Ed25519 Master Key
         ↓ Derivation Path m/44'/CTX'/0'/0/0
Ed25519 Account Key → CTX Address (20 байт)

12.3 Функциональность

• Создание и импорт кошельков (мнемоника / keystore JSON)
• Просмотр баланса и истории транзакций
• Переводы CTX с подписью Ed25519
• Управление стейкингом (stake/unstake)
• Просмотр статуса relay-оператора и uptime

---

12. Сравнительный анализ

---

13. Дорожная карта

Phase 1 — Базовая инфраструктура ✅ Завершено

• Relay-серверы на go-libp2p с протоколом /ctx/1.2
• SQLite-хранилище с системой миграций
• Аутентификация по Ed25519 keypairs
• Kademlia DHT и Circuit Relay v2 для NAT traversal
• Docker Compose кластер для деплоя

Phase 2 — Безопасность и репликация ✅ Завершено

• Приватный режим с NETSIGN/NETSIGN верификацией
• Межузловая eager-push репликация
• Очереди с retry-логикой
• Rate-limiting и Connection Gater
• Vector Clock для причинностного порядка

Phase 3 — Push и мобильные клиенты ✅ Завершено

• APNS, FCM и Huawei Push Kit интеграция
• Flutter iOS/Android клиент (ctx_mobile)
• Tombstone-репликация для удалений
• Метрики и мониторинг Prometheus
• Публичные каналы через GossipSub

Phase 4 — Блокчейн и токеномика 🔵 В разработке

• Линейный BFT-блокчейн с Merkle-деревьями
• Стейкинг, slashing и эмиссия CTX
• Смарт-контракты: Payment, Session, Dispute
• Desktop-кошелёк на Wails + Svelte
• Exchange API с WebSocket и webhooks

Phase 5 — Экосистема ○ Запланировано

• BLE (Bluetooth Low Energy) режим без интернета
• Публичная тестовая сеть (testnet)
• SDK для интеграции сторонних приложений
• Открытый реестр публичных relay-операторов
• Governance — управление сетью через CTX

---

14. Технический стек

14.1 Ключевые архитектурные решения

---

15. Заключение

CONTEXT представляет собой архитектурно завершённое решение для децентрализованных коммуникаций, объединяющее несколько ключевых инноваций:

1. Relay-архитектура устраняет единую точку отказа, сохраняя при этом практичность (Push-уведомления, офлайн-доставка)
2. Криптографическая идентичность на основе Ed25519 дает пользователям полный суверенитет над своей личностью без зависимости от телефонных номеров или email
3. Токеномика CTX создаёт устойчивую экономическую модель для операторов инфраструктуры через механизм uptime-rewards с halving и дефляционным burn
4. Блокчейн-верифицируемость обеспечивает прозрачный аудит без раскрытия содержимого сообщений
5. Многоуровневая безопасность от транспортного уровня (Noise) до прикладного (Ed25519 подписи, приватный режим) защищает от различных классов атак

Проект развивается открыто под MIT-лицензией. Участие сообщества приветствуется на всех уровнях: от запуска relay-узлов до вклада в протокол.

---

17. Ссылки

• go-libp2p: https://github.com/libp2p/go-libp2p
• libp2p Specifications: https://github.com/libp2p/specs
• Noise Protocol Framework: https://noiseprotocol.org/noise.html
• Kademlia DHT: Maymounkov & Mazières (2002), "Kademlia: A Peer-to-Peer Information System Based on the XOR Metric"
• BFT Consensus: Castro & Liskov (1999), "Practical Byzantine Fault Tolerance"
• Ed25519: Bernstein et al. (2011), "High-speed high-security signatures"
• BIP-39: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
• SLIP-0010: https://github.com/satoshilabs/slips/blob/master/slip-0010.md
• Circuit Relay v2: https://docs.libp2p.io/concepts/nat/circuit-relay/
• GossipSub: https://github.com/libp2p/specs/blob/master/pubsub/gossipsub
• Wails: https://wails.io
• Flutter: https://flutter.dev