Koto Protocol — Technical Whitepaper

Koto Messenger — децентрализованная система обмена сообщениями, спроектированная для максимальной анонимности. Архитектура состоит из 12 микросервисов: API Gateway, Auth, Key Service, User, Chat, Group, Media, Push, Presence, WS Gateway, Anti-Spam и Search. Ключевой принцип: Zero-Trace Identity. Система не хранит и не обрабатывает персональные данные (телефон, email, IP). Идентификация пользователей основана исключительно на криптографических ключах Ed25519, выводимых из BIP-39 seed-фраз.

Регистрация: генерация 128-битной энтропии → BIP-39 мнемоника (12 слов) → Ed25519 keypair. Публичный ключ служит уникальным идентификатором пользователя (fingerprint). Аутентификация: challenge-response протокол. Сервер отправляет случайный nonce, клиент подписывает его приватным ключом. Сервер проверяет подпись по публичному ключу. Никаких паролей, OTP или SMS. Приватный ключ никогда не покидает устройство пользователя. При переносе на новое устройство используется E2E-зашифрованный QR-код.

Личные чаты: Signal Protocol — комбинация X3DH (Extended Triple Diffie-Hellman) для установки сессии и Double Ratchet для обмена сообщениями. Обеспечивает forward secrecy и break-in recovery. Групповые чаты: MLS (Messaging Layer Security, RFC 9420). Масштабируемый протокол с O(log n) стоимостью обновления ключей. Каждый участник генерирует KeyPackage, дерево Ratchet обновляется при каждом изменении состава. Хранение: сообщения хранятся в ScyllaDB в зашифрованном виде. Сервер не имеет ключей дешифровки. Метаданные минимизированы: timestamp + chat_id (обфусцированный).

Технология скрытия отправителя. Клиент шифрует конверт сообщения публичным ключом получателя, включая свой идентификатор внутрь шифротекста. Сервер маршрутизирует сообщение по chat_id, но не знает fingerprint отправителя. Реализация: ECIES (Elliptic Curve Integrated Encryption Scheme) на Curve25519. Серверу доступен только recipient_id и размер зашифрованного пакета.

Для скрытия IP-адреса используется OHTTP (RFC 9458). Архитектура: Client → OHTTP Relay → OHTTP Gateway → Koto API Relay видит IP клиента, но не видит содержимое запроса (зашифровано для Gateway). Gateway видит запрос, но не видит IP (получает запрос от Relay). Ни одна сторона не имеет полной картины. Доступные реле: EU (Франкфурт), US (Вирджиния), Asia (Сингапур). Пользователь выбирает реле в настройках.

Проблема: как предотвратить спам без раскрытия личности? Решение: Zero-Knowledge Proofs на базе gnark (Groth16). Пользователь генерирует ZKP, доказывающий владение валидным ключом и наличие «кредитов активности» без раскрытия самого ключа. Сервер верифицирует proof за O(1) и разрешает отправку. ZKP-кредиты начисляются за время присутствия в сети. Новые аккаунты проходят Proof-of-Work при первой отправке. Это эквивалент «возраста аккаунта» без привязки к личности.

Основной транспорт: QUIC/HTTP3 — низкая латентность, встроенное шифрование (TLS 1.3), мультиплексирование потоков. Fallback: WebSocket через gnet/epoll (до 300K соединений на ноду). Присутствие (presence): Lazy/Pull модель. Клиент запрашивает статус конкретного контакта, а не получает broadcast всех изменений. Это снижает нагрузку и предотвращает утечку метаданных. Целевая нагрузка: 3 000 000 одновременных подключений (PCU). Достигается горизонтальным масштабированием WS Gateway нод + DragonflyDB (4M+ ops/sec) для кеша сессий.

Трёхуровневая система хранения медиа: • SSD (hot) — недавние файлы, быстрый доступ • HDD (warm) — файлы старше 7 дней • B2/S3 (cold) — архивные файлы, минимальная стоимость Все файлы шифруются клиентом перед загрузкой (AES-256-GCM). Ключ шифрования передаётся в E2E-сообщении, сервер хранит только зашифрованные blob'ы. База данных: PostgreSQL (метаданные аккаунтов, без PII), ScyllaDB (сообщения, Multi-DC кластер), DragonflyDB (presence, sessions, cache).