Приватность по умолчанию

Проблема приватности в блокчейнах

Блокчейны по своей природе публичны. Каждая транзакция в Bitcoin, Ethereum, Solana видна всем. Любой может посмотреть:

• Адреса отправителя и получателя
• Сумму перевода
• Время транзакции
• Весь баланс кошелька
• Историю всех операций

Это создаёт фундаментальную проблему: финансовая жизнь пользователя полностью прозрачна. Любой — от рекламодателя до правоохранительных органов — может построить полный профиль spending habits.

Для решения этой проблемы сообщество придумало несколько костылей:

1. Миксеры (Tornado Cash, Wasabi Wallet) — смешивают монеты разных пользователей
2. Mix-сети (CoinJoin, Dandelion++) — маскируют IP-адреса
3. Privacy-коины (Monero, Zcash) — используют криптографию для скрытия данных
4. Zero-knowledge proofs (zk-SNARKs, zk-STARKs) — доказывают факт транзакции без раскрытия деталей
5. Layer-2 решения (Lightning Network, Aztec) — проводят транзакции вне основного блокчейна

Что видит сервер MEMORIA

Давайте посмотрим, что реально видит сервер MEMORIA при обработке транзакции. Вот полный набор данных для P2P-перевода:

─────────────────────────────────────────────────────┐
│  Данные транзакции (89 байт)                        │
├─────────────────────────────────────────────────────┤
│  FromPeer: [20]byte  →  "00000000001234567890"      │
│  ToPeer:   [20]byte  →  "00000000009876543210"      │
│  Amount:   int64     →  1000                        │
│  ReqID:    [8]byte   →  0x4A3B2C1D                  │
│  Sig:      [32]byte  →  BLAKE3 signature            │
└─────────────────────────────────────────────────────┘

Что это значит на практике:
  • Нет имён
  • Нет email
  • Нет телефонов
  • Нет IP-адресов (не сохраняются)
  • Нет геолокации
  • Нет истории браузера
  • Нет связей с другими аккаунтами
  
  Только числа. Анонимные числа.Go

Сервер физически не может связать транзакцию с реальным человеком, потому что эта информация никогда не передаётся на сервер.

PeerID: анонимный идентификатор

PeerID — это 20-значное число, которое генерируется случайным образом при регистрации:

func (w *Worker) generateRegistrationOnFly(ipStr string, nowSec int64) ([20]byte, []byte, bool) {
    hash := xxhash.Sum64String(fmt.Sprintf("%d", time.Now().UnixNano()))
    newIDStr := fmt.Sprintf("%020d", hash%10000000000000000000)
    // ...
}Go

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

• Случайный — генерируется из UnixNano, невозможно предсказать
• Одноразовый — создаётся один раз при регистрации
• Не связан с IP — IP не сохраняется, не хэшируется, не логируется
• Не связан с email — email не запрашивается при регистрации
• Не связан с телефоном — телефон не требуется
• Не связан с KYC — верификация личности не проводится

PeerID — это просто число. Как номер банковского счёта, но без привязки к личности. Сам по себе он не является персональными данными.

Отсутствие связей

Даже если злоумышленник получит доступ к серверу MEMORIA, он увидит только:

Почему это работает

В традиционных системах приватность достигается через шифрование данных. В MEMORIA приватность достигается через отсутствие данных.

Разница фундаментальная:

• Шифрование — данные есть, но они защищены. Если ключ скомпрометирован — данные раскрыты.
• Отсутствие данных — данных нет вообще. Нечего компрометировать.

Почему не нужны миксеры

Миксеры (mixers) — это сервисы, которые смешивают монеты разных пользователей, чтобы разорвать связь между отправителем и получателем. Пример: Tornado Cash в Ethereum.

Как работают миксеры

1. Пользователь A отправляет 1 ETH в миксер
2. Пользователь B отправляет 1 ETH в миксер
3. Миксер перемешивает монеты
4. Пользователь A выводит 1 ETH на новый адрес
5. Пользователь B выводит 1 ETH на новый адрес

Проблема: наблюдатель видит, что A и B использовали миксер, и может сделать выводы. Плюс миксеры стоят денег (комиссия 0.1-1%).

Почему в MEMORIA это не нужно

В MEMORIA изначально нет связи между PeerID и личностью. Нечего "разрывать" — связи просто не существует.

Почему не нужны ZK-proofs

Zero-knowledge proofs (доказательства с нулевым разглашением) — это криптографический протокол, который позволяет доказать факт, не раскрывая информацию. Например: "я знаю пароль" без показа пароля.

Где используются ZK-proofs

• Zcash — скрытие сумм и адресов транзакций
• Aztec Network — приватные смарт-контракты
• StarkNet — масштабируемость через ZK-rollups
• Semaphore — анонимное голосование

Проблемы ZK-proofs

1. Вычислительная сложность — генерация proof занимает секунды-минуты
2. Размер proof — от 1 KB до нескольких MB
3. Стоимость — ZK-транзакции в 10-100 раз дороже обычных
4. Сложность реализации — требует глубоких знаний криптографии
5. Аудит — сложно проверить корректность реализации

Почему в MEMORIA это не нужно

ZK-proofs решают проблему: "как доказать факт транзакции, не раскрывая детали". В MEMORIA эта проблема не существует, потому что:

• Сервер и так не видит деталей (только числа)
• Нет публичного реестра, который нужно "обмануть"
• Приватность обеспечивается отсутствием данных, а не криптографией

Пользователь контролирует раскрытие

Ключевой принцип MEMORIA: приватность по умолчанию, раскрытие по выбору. Пользователь сам решает, кому показать свои транзакции.

Как это работает

Каждый пользователь хранит свой снапшот локально. Снапшот содержит:

• PeerID (20 байт)
• Balance (8 байт)
• UserKey (32 байта)
• Signature (32 байта)
• Transaction log (до 640 байт)

Если пользователь хочет показать свои транзакции (например, для аудита, налоговой, или просто другу), он может:

1. Экспортировать снапшот — бинарный файл 128+ байт
2. Показать transaction log — последние 10 транзакций
3. Подписать заявление — используя свой приватный ключ
4. Раскрыть связь PeerID ↔ личность — только если сам захочет

Пример: пользователь хочет доказать доход для кредита

1. Экспортирует снапшот из приложения
2. Показывает баланс: 50 000 MEMO
3. Показывает transaction log:
   - Входящие: +10 000 (от работодателя)
   - Входящие: +5 000 (фриланс)
   - Исходящие: -2 000 (аренда)
4. Подписывает заявление своим ключом
5. Банк верифицирует подпись через BLAKE3

Результат: доказательство дохода без раскрытия 
всех транзакций за всю историю.

Контроль полностью у пользователя.Сценарий

Сравнение с блокчейнами

Сравнение подходов к приватности

Сценарии использования

Сценарий 1: Микроплатежи между друзьями

Проблема: Alice хочет отправить Bob $5 за обед. В Bitcoin это публично — все увидят сумму и адреса. В Venmo — Venmo увидит всё и продаст данные рекламодателям.

Решение MEMORIA: Alice отправляет Bob 5 MEMO. Сервер видит только два числа (PeerID Alice и PeerID Bob) и сумму (5). Никто — ни сервер, ни наблюдатели, ни рекламодатели — не знает, кто такие Alice и Bob.

Сценарий 2: Оплата услуг фрилансера

Проблема: Компания платит фрилансеру. В блокчейне все видят сумму и адреса. Фрилансер не хочет раскрывать свой доход конкурентам.

Решение MEMORIA: Компания отправляет оплату на PeerID фрилансера. Сервер видит только числа. Фрилансер может показать снапшот только налоговой (если нужно), но не конкурентам.

Сценарий 3: Донаты и чаевые

Проблема: Пользователь хочет отправить донат блогеру. В блокчейне все увидят сумму — это может быть использовано для доксинга или шантажа.

Решение MEMORIA: Донат отправляется на PeerID блогера. Сумма видна только серверу (как число) и самому блогеру. Никто другой не знает размер доната.

Сценарий 4: Корпоративные расходы

Проблема: Сотрудник оплачивает командировку. Компания хочет видеть расходы, но не хочет, чтобы конкуренты видели финансовые потоки.

Решение MEMORIA: Сотрудник использует корпоративный PeerID. Компания может запросить снапшот для аудита. Конкуренты не видят ничего, потому что данных нет в публичном доступе.

Сценарий 5: Анонимные опросы и голосования

Проблема: Нужно провести голосование, где каждый голос анонимен, но результат можно верифицировать.

Решение MEMORIA: Каждый участник получает одноразовый PeerID. Голоса отправляются как транзакции. Сервер считает результаты, но не может связать голос с участником. После голосования PeerID удаляются.

Выводы

MEMORIA решает проблему приватности на архитектурном уровне, а не через надстройки:

1. Нет PII на сервере — только числа (PeerID, балансы, timestamps)
2. Нет связей с личностью — PeerID не связан с email, телефоном, IP
3. Не нужны миксеры — нечего смешивать, связи нет
4. Не нужны ZK-proofs — нечего скрывать, данных нет
5. Пользователь контролирует раскрытие — может показать снапшот кому нужно
6. Приватность по умолчанию — не нужно ничего настраивать

В следующей статье мы разберём, как MEMORIA интегрируется в существующие продукты — от мобильных игр до платёжных систем — и какой экономический эффект это даёт.