Партнеры для криптовалютных проектов

[Temoh]

Уважаемое сообщество ищу серьезных партнеров для криптовалютных проектов. Суть, я пока писал чат написал неплохой платежный сервис который можно пере использовать под разные криптовалюты, будут настоящие криптовалюты со своими даже протоколами если нужно будет, типа mesh сетей, p2p по вверх udp и так далее на сколько фантазий хватит. Кошелек у меня уже готовый, переводы работают, поиск транзакций, балансы, исходящие-входящие транзакции, пулл ликвидности можно делать клайм каждые 4 часа, начисление. Микросистемная архитектура можно быстро делать разные криптавалюты. Кошелек только андроид версия. У большинства криптопроектов даже кошелька нету. Интересно долгосрочное сотрудничество, под за рубеж.

Отчет AI:
## Оценка производительности (realistic, на хорошем сервере)

Предположим сервер Redis:

• CPU: 8–16 ядер (Redis — однопоточный, но фоновые операции используют другие ядра)
• RAM: 64 ГБ
• SSD NVMe (для persistence, если включён)
• Сеть: 10 GbE

---

### 1. Максимальное количество пользователей (всего)

Под "пользователями" понимаем уникальные peerID, которые когда-либо совершали операцию (claim/transfer).

- Каждый активный пользователь (с ненулевым балансом или недавним логом) занимает:
- Ключ баланса: ~50–100 байт (если ≠ 0)
- Лог транзакций: до 50 записей × ~200 байт = ~10 КБ максимум (но обычно меньше)
- Индекс транзакций: tx_index_by_user{...} — до 100 ID × 20 байт ≈ 2 КБ

Но если пользователь потратил всё и давно неактивен:

• Ключ баланса удалён.
• Лог и индекс протухают через 30 дней (EXPIRE 2592000 = 30 дней).

То есть неактивные пользователи со временем исчезают из памяти.

Итог по общему числу пользователей:

Вы можете хранить данные о миллиардах пользователей, потому что:
- Только активные/недавние занимают память.
- Остальные — автоматически удаляются через TTL.

---

### 2. Одновременный онлайн (активные пользователи)

"Онлайн" = пользователи, у которых ненулевой баланс ИЛИ недавние транзакции (в пределах 30 дней).

Допустим:

• Средний активный пользователь занимает ~5–10 КБ (баланс + лог + индекс).
• У вас 64 ГБ RAM, из них ~50 ГБ можно отдать под данные (остальное — overhead Redis, OS).

Тогда:

50 ГБ / 10 КБ ≈ 5 000 000 активных пользователей
50 ГБ / 5 КБ ≈ 10 000 000 активных пользователей

Итог по онлайн-пользователям:

До 5–10 миллионов активных пользователей могут находиться "в онлайне" (храниться в памяти) на одном сервере Redis с 64 ГБ RAM.

Если увеличить RAM до 128 ГБ → до 10–20 млн.

---

### 3. Транзакции в секунду (TPS)

Redis — однопоточный для записи. Lua-скрипты блокируют движок на всё время выполнения.

Ваши скрипты:

• Простые, без циклов.
• Делают ~10–15 Redis-команд.
• Работают ~0.2–0.5 мс на одну транзакцию (на хорошем CPU).

Теоретический максимум:

1000 мс / 0.3 мс ≈ 3000–5000 TPS

Но на практике:

• Сетевые задержки.
• Конкуренция за ресурсы.
• Persistence (RDB/AOF) может вызывать паузы.

Итог по TPS:

Стабильно 2000–4000 транзакций в секунду — реалистичная цифра для standalone Redis на хорошем железе.
Пиковые всплески — до 5000 TPS.

---

## Финальный итог

| Показатель | Значение (на 1 Redis-ноде, 64 ГБ RAM) |
|-----------|----------------------------------------|
| Всего пользователей (в истории) | Неограниченно (миллиарды — за счёт TTL и удаления нулей) |
| Активных пользователей ("онлайн") | 5–10 млн |
| Макс. транзакций в секунду (TPS) | 2000–4000 |

Это очень высокая производительность для финансовой системы на одном сервере.
Многие стартапы и даже средние проекты не достигают этих пределов.

---

## Если нужно больше?

1. Vertically: Увеличьте RAM до 128–256 ГБ → +2× пользователей.
2. Horizontally: Запустите несколько wallet-нод, каждая обслуживает свой диапазон peerID (например, по первой цифре). Но между нодами нельзя делать transfer — или нужен координационный слой.
3. Архитектурно: Перейдите на PostgreSQL + Redis cache, чтобы получить true distributed transactions.

Но если ваш продукт не достиг 4000 TPS и 10 млн активных — текущая архитектура идеальна.


========================================================================================================================================================================================================


После апдейта будет следующие показатели по отчету AI:
Отлично! Теперь у нас обновлённая, значительно более продвинутая архитектура — с поддержкой горизонтального масштабирования через шардирование, паттерном Saga для кросс-шардных транзакций, пулами воркеров, circuit breakers, метриками, асинхронной обработкой логов и устойчивостью к сбоям.

Разберём по пунктам ваш вопрос:

Сколько пользователей можно обслуживать? Какой онлайн? Сколько TPS?

---

## Ключевые архитектурные преимущества новой версии

1. Шардирование по peerID:
- Ключи: balance:123456789 → нет общего hash tag → Redis Cluster распределяет пользователей по 16384 слотам.
- getShardID(peerID) использует FNV-хеш → равномерное распределение.

2. Поддержка Redis Cluster:
- shardCount = 64 (можно увеличить).
- Отдельные пул соединений на каждый "логический шард" (для изоляции).

3. Atomic transfers — внутри одного шарда (быстро, надёжно).
4. Cross-shard transfers — через Saga pattern (lock → complete/compensate).
5. Асинхронная запись логов → не блокирует основную транзакцию.
6. 128 воркеров, обрабатывающих события из Redis Stream.
7. Не хранятся нулевые балансы (в Lua-скриптах: DECRBY → если стало 0, ключ остаётся, но вы можете его удалять — сейчас этого нет, но легко добавить).

Замечание: в текущем atomicTransferScript не удаляется ключ при балансе = 0. Это можно улучшить (см. ниже).

---

## Оценка масштабируемости

### 1. Максимальное число пользователей (всего)

• Теоретически — миллиарды.
• Потому что:

- Пользователи распределены по шардам.
- Redis Cluster масштабируется до 1000+ нод (на практике — 10–100 нод).
- TTL = 7 дней на баланс → неактивные пользователи исчезают.
- Логи хранятся 30 дней → потом удаляются.

Ограничение — не архитектура, а бюджет на Redis-кластер.

---

### 2. Одновременный онлайн (активные пользователи)

Пусть у вас Redis Cluster из 10 нод, по 64 ГБ RAM каждая → 640 ГБ суммарно.

• Активный пользователь (баланс + лог + индекс): ~5–10 КБ.
• Но баланс = 0 → ключ может не храниться (если доработать скрипты).

При 640 ГБ и 10 КБ на пользователя:

640 * 1024 / 10 ≈ **65 миллионов активных пользователей**

Если убрать нулевые балансы и сжать логи → можно поднять до 100–150 млн.

Оценка:

50–150 млн активных пользователей — реалистично на кластере из 10 средних нод.

---

### 3. Транзакции в секунду (TPS)

#### a) Intra-shard transfers (80–90% трафика, предположим)

• Выполняются атомарно, за ~0.2 мс.
• На одной Redis-ноде: до 4000–5000 TPS.
• На 10 нодах: 40 000–50 000 TPS (линейное масштабирование).

#### b) Cross-shard transfers (10–20%)

• Медленнее: 2 фазы + попытки + асинхронность.
• ~10–50 мс на транзакцию.
• Но обрабатываются асинхронно, не блокируют основной поток.
• Максимум: 1000–2000 cross-shard TPS на кластер (ограничено координацией).

#### c) Claims
- Проще transfers → до 60 000 TPS на кластер.

Итог по TPS (сбалансированная нагрузка):

30 000 – 60 000 транзакций в секунду — реалистичная производительность для кластера из 10 нод.

Это в 10–15 раз выше, чем standalone-версия!

---

## Что можно улучшить для ещё большей эффективности?

### 1. Удалять ключи с нулевым балансом

Сейчас в atomicTransferScript:

redis.call('DECRBY', from_key, amount)

→ если стало 0, ключ остаётся.

Рекомендация: добавить проверку и DEL:

local new_bal = redis.call('DECRBY', from_key, amount)
if tonumber(new_bal) == 0 then
    redis.call('DEL', from_key)
else
    redis.call('EXPIRE', from_key, 604800)
end

(аналогично в crossShardLockScript и claimScript — там INCRBY, так что 0 не возникает).

→ Это снизит память на 30–50% для пользователей с нулевым балансом.

---

### 2. Увеличить shardCount

Сейчас shardCount = 64.
Если у вас 100 Redis-нод, можно поставить shardCount = 256 или 512 → лучше распределение нагрузки.

---

### 3. Оптимизировать Saga TTL

Сейчас lock живёт 5 минут. Можно снизить до 30–60 сек, если компенсация быстрая.

---

## Финальный итог (обновлённая архитектура)

| Показатель | Оценка (на Redis Cluster из 10 нод × 64 ГБ) |
|-----------|---------------------------------------------|
| Всего пользователей | Неограниченно (миллиарды, благодаря TTL и шардированию) |
| Активных пользователей ("онлайн") | 50–150 миллионов |
| Макс. TPS (смешанная нагрузка) | 30 000 – 60 000 |
| Cross-shard TPS | До 2000 (остальное — intra-shard) |
| Масштабируемость | Линейная — добавляете ноды → растёт TPS и ёмкость |

Эта архитектура подходит для крупного проекта уровня Telegram, Discord, или Web3-кошелька с десятками миллионов пользователей.

Если вам нужно ещё больше — масштабируйте Redis Cluster (до 50–100 нод), и система легко выйдет на 200–300K TPS.

---

По факту конечно меньше, так как сейчас используются вебсокеты к нодам, можно поставить перед нодами haproxy чтобы держал соединения, а к нодам только rpc запросы. Но все равно это излишне так как таких объемов не будет.

 

[Temoh]

Думаю нужно подробней рассказать суть моего предложения. Хочу поставить на поток создания криптавалют, у нас есть кошелек со всем необходимым функционалом, то есть по факту рабочее приложение, мы создаем реплики кошелька с разными дизайнами, какими то своими фишками в кошельке если нужно. Могу даже сделать какие нибудь бесполезные протоколы как у всей крипты. Нужны сайты как у серьезных криптопроектов. Аккаунты в соцсетях, прогрев публики, рекламма. Пресейл.
Мои слабые стороны это дизайн и рекламма, я занимаюсь архитектурой вы занимаетесь остальным, сайтами, дизайном, общественностью, рекламмой. Хотите делайте сами, хотите нанимайте кого то, для меня это не имеет значения. Работать хочу под зарубеж.