Продвинутые темы¶
Глубокое погружение в архитектуру ComputeChain, Proof-of-Compute и технические детали.
Архитектура¶
Трехслойный дизайн¶
ComputeChain работает как три взаимосвязанных уровня:
1. Блокчейн уровень (Состояние) - Хранит балансы аккаунтов, стейки валидаторов, делегации - Поддерживает историю транзакций и заголовки блоков - Обеспечивает неизменяемый аудит всех операций
2. Консенсус уровень (Валидаторы) - Производит блоки в режиме round-robin (PoA) - Валидирует транзакции и переходы состояний - Применяет правила протокола (gas, слэшинг, награды) - Отслеживает производительность валидаторов (uptime, пропущенные блоки)
3. Вычислительный уровень (Воркеры) - Выполняет GPU вычислительные задачи - Отправляет результаты через транзакции SUBMIT_RESULT - Результаты проверяются правилами Proof-of-Compute - Экономические стимулы награждают корректное выполнение
Топология сети¶
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│Валидатор A │────▶│Валидатор B │────▶│Валидатор C │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
└────────────────────┴────────────────────┘
│
┌───────┴────────┐
│ │
┌──────────┐ ┌──────────┐
│ Воркер 1 │ │ Воркер 2 │
└──────────┘ └──────────┘
Валидаторы образуют P2P mesh сеть используя libp2p. Воркеры подключаются через RPC для отправки результатов вычислений.
Механизм консенсуса¶
Round-Robin PoA¶
Производство блоков:
- Валидаторы производят блоки по очереди
- Proposer определяется: proposer_index = height % num_active_validators
- Время блока: ~10 секунд (настраивается)
- Не нужен выбор форка (детерминированная единственная цепь)
Жизненный цикл валидатора:
INACTIVE → ждать 100 блоков → ACTIVE → производить блоки → получать награды
↓ ↓
└─────────────────────────JAILED (uptime < 75%)
↓
оплатить unjail → ACTIVE
↓
3x jail → EJECTED (постоянно)
Система эпох¶
Длина эпохи: 100 блоков
Переходы эпох: 1. Расчет оценок uptime для всех валидаторов 2. Jail валидаторов с uptime < 75% 3. Применение штрафов слэшинга (5% → 10% → 100%) 4. Активация новых валидаторов с минимальным стейком 5. Деактивация валидаторов ниже минимальной мощности
Proof-of-Compute (PoC)¶
Концепция¶
Традиционные блокчейны используют Proof-of-Work для безопасности, но вычисления "бесполезны" (перебор хэшей). ComputeChain стремится заменить это полезными GPU вычислениями с сохранением проверяемости.
PoC v1 (Текущая)¶
Создание задачи: - Любой может отправить транзакцию SUBMIT_RESULT - Task ID (UUID) идентифицирует вычисление - Хэш результата фиксирует вывод
Верификация (Базовая): - Текущий MVP принимает результаты без глубокой проверки - Будущие версии добавят вероятностную проверку
PoC v2+ (Планируется)¶
Улучшенная верификация:
- Избыточное выполнение: Несколько воркеров выполняют одну задачу, результаты сравниваются
- Выборка: Валидаторы случайно проверяют подмножество результатов
- Период оспаривания: Окно для споров о неправильных результатах
- Экономические штрафы: Неправильные результаты слэшат стейк/репутацию воркера
Процесс:
Задача опубликована → Воркер назначен → Выполнение → Результат отправлен
↓
┌───────────────────┴──────────────┐
↓ ↓
Верификация Оспаривание
(выборка) (спор)
↓ ↓
Принято Слэшнуто
↓
Платеж выпущен
Варианты использования¶
Текущие: - Простые отправки вычислительных задач (proof-of-concept) - Отслеживание Merkle корня в заголовках блоков
Планируемые: - AI inference (LLM, модели изображений) - 3D рендеринг (Blender и т.д.) - Кодирование видео (FFMPEG, x264) - Научные вычисления (симуляции, матричные операции)
Токеномика¶
Токен CPC¶
Эмиссия: - Начальная эмиссия: Настраивается в genesis - Награды за блок: 10 CPC за блок (уменьшается вдвое каждые 1М блоков) - Макс эмиссия: Определяется расписанием halving
Утилита: 1. Стейкинг: Валидаторы блокируют CPC как залог 2. Делегирование: Пассивные держатели делегируют валидаторам 3. Gas комиссии: Все транзакции платят gas в CPC 4. Оплата вычислений: Задачи оплачиваются в CPC 5. Управление: (Будущее) голосование по параметрам протокола
Награды за блоки¶
Формула награды:
initial_reward = 10 * 10**18 # 10 CPC
halvings = height // 1_000_000
reward = initial_reward >> halvings
Расписание распределения:
| Высота | Награда за блок |
|---|---|
| 0 - 999,999 | 10 CPC |
| 1M - 1.999M | 5 CPC |
| 2M - 2.999M | 2.5 CPC |
| 3M - 3.999M | 1.25 CPC |
Распределение наград¶
Без делегаций: - Валидатор получает 100% от (награда за блок + комиссии транзакций)
С делегациями:
Общая награда = Награда за блок + Комиссии транзакций
Комиссия = Общая награда × validator.commission_rate (по умолчанию 10%)
Доля делегатора = Общая награда - Комиссия
Для каждого делегатора:
Награда = (Доля делегатора × delegation.amount) / validator.total_delegated
Пример:
Награда за блок: 10 CPC
Комиссии Tx: 0.0001 CPC
Всего: 10.0001 CPC
Комиссия (10%): 1.00001 CPC → Валидатор
Доля делегатора (90%): 9.00009 CPC
Делегатор A (60% стейка): 5.40 CPC
Делегатор B (40% стейка): 3.60 CPC
Штрафы слэшинга¶
Градуированный слэшинг:
| Количество jail | Штраф | Действие |
|---|---|---|
| 1-й | 5% стейка слэшнуто | Временный jail |
| 2-й | 10% стейка слэшнуто | Временный jail |
| 3-й | 100% стейка слэшнуто | EJECTED (постоянно) |
Штраф за Unstake: - Unstake в состоянии jailed: Дополнительный штраф 10%
Модель Gas¶
Стоимость Gas¶
Типы транзакций имеют базовые стоимости gas:
GAS_PER_TYPE = {
TxType.TRANSFER: 21_000,
TxType.STAKE: 40_000,
TxType.UNSTAKE: 40_000,
TxType.DELEGATE: 35_000,
TxType.UNDELEGATE: 35_000,
TxType.UNJAIL: 50_000,
TxType.UPDATE_VALIDATOR: 30_000,
TxType.SUBMIT_RESULT: 80_000,
}
Расчет комиссии¶
Пример:
Рынок цены Gas¶
Текущее: Фиксированная цена gas (рекомендуется 1000 wei)
Будущее: Динамическая цена gas на основе загрузки сети: - Базовая комиссия сжигается (стиль EIP-1559) - Приоритетная комиссия идет валидаторам
Криптография¶
Текущая реализация (ECDSA)¶
Подпись: - Кривая secp256k1 (как в Bitcoin/Ethereum) - 32-байтные приватные ключи - Восстанавливаемые подписи (65 байт)
Деривация адреса:
Форматы адресов:
- Обычные аккаунты: cpc1...
- Валидаторы: cpcvalcons1...
Готовность к пост-квантовой криптографии¶
Архитектура поддерживает: - Dilithium (стандарт NIST) - Falcon (компактные подписи) - Будущий путь миграции без изменений протокола
Поля зарезервированы в BlockHeader:
Управление состоянием¶
Состояние аккаунта¶
class Account:
address: str
balance: int # в wei
nonce: int
reward_history: Dict[int, int] # эпоха → награды
Состояние валидатора¶
class Validator:
address: str # cpcvalcons1...
pq_pub_key: str
power: int # застейканная сумма
is_active: bool
is_jailed: bool
reward_address: str # куда идут награды
commission_rate: float # 0.0-1.0
delegations: List[Delegation]
State Root¶
Каждый заголовок блока включает:
- tx_root: Merkle корень транзакций
- state_root: Хэш состояния аккаунта
- compute_root: Merkle корень результатов вычислений
Параметры сети¶
Devnet¶
Chain ID: computechain-devnet
Время блока: 10 секунд
Длина эпохи: 100 блоков
Мин стейк: 100 CPC
Мин Uptime: 75%
Плата Unjail: 1000 CPC
Testnet (Планируется)¶
Mainnet (Будущее)¶
Отслеживание производительности¶
Оценка Uptime¶
Расчет: - Отслеживать каждый блок в эпохе - Если валидатор был proposer но не произвел блок → пропущенный блок - Uptime < 75% → jailed при переходе эпохи
Метрики мониторинга¶
Нода предоставляет:
- /status - Текущая высота, эпоха, размер mempool
- /validators - Все валидаторы с оценками uptime
- /metrics ✅ Реализовано - Метрики совместимые с Prometheus
Prometheus метрики (Phase 1.3):
- computechain_block_height - Текущая высота блока
- computechain_transactions_total - Общее количество обработанных транзакций (по типам)
- computechain_mempool_size - Размер mempool
- computechain_validator_count - Количество валидаторов
- computechain_total_supply - Общее предложение в обращении
- computechain_total_burned - Всего сожжено токенов
- computechain_total_minted - Всего отчеканено токенов
- computechain_accounts_total - Количество аккаунтов в сети
Интеграция Grafana:
# prometheus.yml
scrape_configs:
- job_name: 'computechain'
static_configs:
- targets: ['localhost:8000']
metrics_path: '/metrics'
scrape_interval: 10s
Снепшоты состояния¶
Система снепшотов (Phase 1.3) ✅ Реализовано¶
Автоматическое создание: - Каждые N блоков (по умолчанию: 1000) - На границах эпох - Сжатие gzip (~60-80% уменьшение размера) - SHA256 верификация целостности
Fast Sync: - Загрузка состояния из снепшота - Синхронизация <5 минут (вместо часов) - Автоматическая очистка (последние 10 снепшотов)
API эндпоинты:
- GET /snapshots - Список доступных снепшотов
- GET /snapshots/{height} - Информация о конкретном снепшоте
CLI команды:
- ./cpc-cli snapshot list - Список снепшотов
- ./cpc-cli snapshot info <height> - Детальная информация
Содержимое снепшота: - Балансы всех аккаунтов - Стейки валидаторов и делегации - Очередь разблокировки (unbonding queue) - История наград - Экономическое отслеживание (total_burned, total_minted) - Состояние казначейства
Обновления протокола¶
Система обновлений (Phase 1.3) ✅ Реализовано¶
Семантическое версионирование: - MAJOR.MINOR.PATCH (например, 1.0.0) - MAJOR - breaking changes - MINOR - новые фичи (обратная совместимость) - PATCH - багфиксы
Процесс обновления: 1. Планирование: UpgradePlan создается с target_version и upgrade_height 2. Миграция: @migration декораторы для миграции состояния 3. Выполнение: На upgrade_height применяются миграции 4. Проверка: Валидация версии и совместимости
Пример миграции:
from blockchain.upgrade.migrations import migration
@migration(from_version="1.0.0", to_version="1.1.0")
def migrate_add_new_field(state):
# Логика миграции состояния
for account in state.accounts.values():
if not hasattr(account, 'new_field'):
account.new_field = default_value
Компоненты:
- blockchain/upgrade/manager.py - UpgradeManager
- blockchain/upgrade/types.py - Version, UpgradePlan, ChainVersion
- blockchain/upgrade/migrations.py - MigrationRegistry
Статус: Фреймворк готов, тестирование в testnet (Phase 3)
Управление (Phase 4 - Планируется)¶
- Голосование в цепи взвешенное по стейку
- Изменения параметров (стоимость gas, длина эпохи и т.д.)
- Обновления протокола через governance
Технические спецификации¶
Структура транзакции¶
class Transaction:
tx_type: TxType # Тип транзакции (TRANSFER, STAKE и т.д.)
from_address: str # Адрес отправителя (cpc1...)
to_address: Optional[str] # Адрес получателя (None для STAKE)
amount: int # Сумма в минимальных единицах (10^-18 CPC)
fee: int # Комиссия (Фаза 1: фиксированная, Фаза 2: gas_price * gas_limit)
nonce: int # Nonce аккаунта (предотвращает повтор)
signature: str # ECDSA подпись (hex)
pub_key: str # Публичный ключ (hex)
payload: Dict[str, Any] # Дополнительные данные (информация о задаче, метаданные)
# Поля для газа (для совместимости, применяются в Фазе 2)
gas_price: int = 0 # Wei за единицу газа
gas_limit: int = 0 # Максимум газа
Важно: Поле timestamp НЕ существует в Transaction - используется timestamp блока.
Структура блока¶
class BlockHeader:
height: int # Номер блока
prev_hash: str # SHA256 хеш предыдущего блока (hex)
timestamp: int # Unix timestamp (секунды)
chain_id: str # ID сети (например, "cpc-devnet-1")
proposer_address: str # Адрес валидатора (cpcvalcons1...)
# Merkle корни
tx_root: str # Merkle корень всех транзакций
state_root: str # Merkle корень состояния аккаунтов
compute_root: str # Merkle корень результатов вычислений (PoC)
# Отслеживание газа (Фаза 2)
gas_used: int # Всего газа использовано в блоке
gas_limit: int # Максимум газа на блок
# ZK Доказательства (заглушки для Фазы 3)
zk_state_proof_hash: Optional[str] # Zero-knowledge доказательство состояния
zk_compute_proof_hash: Optional[str] # ZK доказательство корректности вычислений
class Block:
header: BlockHeader # Заголовок блока (хешируется для ID блока)
txs: List[Transaction] # Список транзакций
# Пост-квантовая подпись (подписана proposer'ом)
pq_signature: str # Подпись Dilithium3 (hex)
pq_sig_scheme_id: int # ID схемы подписи (1 = Dilithium3)
Важно: Подпись блока хранится в Block.pq_signature, А НЕ в BlockHeader. Сам заголовок не содержит полей signature/pub_key.
Протокол P2P¶
Транспорт: libp2p с TCP/QUIC
Топики:
- /computechain/blocks/1.0.0 - Распространение блоков
- /computechain/txs/1.0.0 - Gossip транзакций
Обнаружение пиров: - Bootstrap ноды (seeds) - Kademlia DHT
Соображения безопасности¶
Векторы атак¶
Картели валидаторов: - Смягчается требованиями минимального uptime - Слэшинг за координированные атаки
Nothing-at-Stake: - Н/П (PoA имеет детерминированного proposer блоков)
Атаки Long-Range: - Смягчается социальным консенсусом на genesis - Чекпоинты (будущее)
Мошенничество результатов вычислений: - Решается верификацией PoC (v2+) - Экономические штрафы за неправильные результаты
Жизненный цикл транзакций (Phase 1.4)¶
Состояния транзакций¶
Каждая транзакция проходит следующий жизненный цикл:
1. Отправлена (Submitted)
- Транзакция отправлена через /tx/send API
- Начальная валидация (подпись, nonce, баланс)
- Добавлена в mempool если валидна
2. В ожидании (Pending)
- Транзакция ожидает в mempool
- Еще не включена в блок
- Можно запросить через /tx/{hash}/receipt
3. Подтверждена (Confirmed) - Транзакция включена в блок - Состояние обновлено (баланс переведен, стейк записан и т.д.) - Receipt доступен с высотой блока
4. Отклонена (Failed) - Невалидная транзакция (недостаточно средств, неверный nonce) - Отклонена валидатором - Сообщение об ошибке в receipt
5. Просрочена (Expired) (Phase 1.4 - НОВОЕ!) - Транзакция не подтверждена в течение TTL (Time-To-Live) - Автоматически удалена из mempool через 1 час - Предотвращает переполнение mempool
Чеки транзакций (Transaction Receipts)¶
Запрос статуса транзакции:
GET /tx/{tx_hash}/receipt
Ответ:
{
"tx_hash": "abc123...",
"status": "confirmed", // pending | confirmed | failed
"block_height": 12345,
"timestamp": 1703347200,
"confirmations": 5, // текущая_высота - block_height + 1
"error": null
}
TX TTL (Time-To-Live)¶
Проблема: Pending транзакции могли застревать в mempool навсегда.
Решение: Автоматическая очистка через 1 час (3600 секунд).
Как это работает:
1. Транзакция добавлена в mempool → записана timestamp
2. Периодическая очистка (каждые 30 секунд)
3. Если возраст > TTL → транзакция удалена и помечена как expired
4. Nonce разблокирован → пользователь может повторить с более высокой комиссией
Преимущества: - ✅ Предотвращает раздувание mempool - ✅ Разблокирует застрявшие nonce - ✅ Улучшает производительность системы
Гарантии финальности¶
Мгновенная финальность (Tendermint BFT)¶
ComputeChain использует консенсус Tendermint, который обеспечивает мгновенную финальность:
1 блок = ФИНАЛЕН ✅
Как только блок добавлен в блокчейн, он не может быть отменен (нет реорганизаций).
Сравнение с другими блокчейнами¶
| Блокчейн | Тип финальности | Время до финальности |
|---|---|---|
| Bitcoin | Вероятностная (6 блоков) | ~60 минут |
| Ethereum PoW | Вероятностная (12 блоков) | ~3 минуты |
| Ethereum PoS | Casper FFG (2 эпохи) | ~15 минут |
| Solana | На основе голосования (~32 блока) | ~13 секунд |
| ComputeChain | Мгновенная (Tendermint) | 0 секунд! ✅ |
Как работает финальность Tendermint¶
- Proposer создает блок
- Валидаторы голосуют за блок (требуется 2/3+)
- Блок добавлен в цепочку → ФИНАЛЕН
- Следующий блок ссылается на него → изменить невозможно
Byzantine Fault Tolerance (Византийская отказоустойчивость)¶
- Система безопасна если < 1/3 валидаторов Byzantine (злонамеренные)
- Если ≥ 2/3 честные → финальность гарантирована
- Невозможна реорганизация цепочки
Рекомендуемые подтверждения¶
Хотя 1 подтверждение технически финально, биржи и приложения могут хотеть дополнительную безопасность:
# Обычные переводы
MIN_CONFIRMATIONS = 1 # Мгновенная финальность!
# Критические операции (дополнительная параноя)
CRITICAL_CONFIRMATIONS = 3 # ~30 секунд
# Большие выводы (стандарт бирж)
EXCHANGE_CONFIRMATIONS = 6 # ~60 секунд
Модель газа¶
Phase 1: Фиксированная комиссия (Текущая)¶
ComputeChain в настоящее время использует простую модель фиксированной комиссии:
class Transaction:
fee: int = 0 # Фиксированная комиссия за транзакцию
gas_price: int = 0 # Зарезервировано для Phase 2
gas_limit: int = 0 # Зарезервировано для Phase 2
Почему фиксированные комиссии? - ✅ Простота для MVP - ✅ Предсказуемые расходы - ✅ Не требуется рынок комиссий (низкий TPS)
Текущая комиссия: Нулевая или минимальная (устанавливается валидаторами)
Phase 2: Динамический газ (Планируется)¶
Ценообразование газа в стиле EIP-1559 (Q2 2025+):
class Transaction:
base_fee: int # Алгоритмическая (сжигается 🔥)
priority_fee: int # Чаевые для валидаторов 💰
max_fee: int # Защитный лимит пользователя 🛡️
Как это будет работать:
- Base Fee - Алгоритмически корректируется на основе загруженности блоков
- Блоки > 50% заполнены → base fee увеличивается
- Блоки < 50% заполнены → base fee уменьшается
-
Сжигается (удаляется из обращения) → дефляционно
-
Priority Fee - Чаевые для валидаторов, устанавливаемые пользователем
- Стимулирует включение в блок
-
Идет proposer блока
-
Max Fee Cap - Защита от скачков комиссии
- TX отклоняется если
base_fee + priority_fee > max_fee
Преимущества: - ✅ Лучшая оценка комиссии - ✅ Снижение волатильности - ✅ Дефляционное давление (сжигаемые комиссии)
Стоимость газа для транзакций¶
Зарезервировано для Phase 2 (из protocol/config/params.py):
| Тип транзакции | Базовый газ |
|---|---|
| TRANSFER | 21,000 |
| STAKE | 40,000 |
| UNSTAKE | 40,000 |
| DELEGATE | 35,000 |
| UNDELEGATE | 35,000 |
| SUBMIT_RESULT | 80,000 |
| UPDATE_VALIDATOR | 30,000 |
| UNJAIL | 50,000 |
Следующие шаги¶
- Гид валидатора - Запуск ноды валидатора
- Гид по стейкингу - Стейк и получение наград
- Справочник API - RPC эндпоинты