Техническая спецификация блокчейн‑сети GoodLuckCoin

Автор: Морыганов Дмитрий АндреевичДата публикации: 17 декабря 2025 г. Статус документа: финальная версия

1. Общие положения

1.1. Назначение документа

Документ определяет:

1. архитектуру блокчейн‑сети GoodLuckCoin (GLC);
2. принципы работы алгоритма консенсуса Proof‑of‑Fortune (PoF);
3. форматы данных и протоколы взаимодействия;
4. экономические и защитные механизмы системы.

1.2. Термины и определения

1. GLC — нативный токен сети GoodLuckCoin.
2. PoF — алгоритм консенсуса Proof‑of‑Fortune.
3. VRF — Verifiable Random Function (проверяемая случайная функция).
4. Смарт‑контракт — программный код, исполняющий логику сети на TVM.
5. Участник — владелец ≥ 10 GLC, участвующий в раунде PoF.
6. Победитель раунда — участник, выбранный для формирования блока.
7. TON — блокчейн‑экосистема, используемая как инфраструктурная платформа.

1.3. Сокращения

1. TVM — TON Virtual Machine.
2. Jetton — стандарт токенов в экосистеме TON.
3. Merkle Root — корень дерева Меркла.
4. sk — приватный ключ участника.
5. public_key — публичный ключ участника.

2. Архитектура сети

2.1. Компоненты системы

1. Ядро PoF: модуль генерации VRF;механизм выбора победителя; система верификации заявок.
2. Смарт‑контракты: контракт участия в раунде; контракт формирования блока; контракт‑арбитр для разрешения споров.
3. Хранилище данных:блокчейн TON (основное хранилище);TON Storage (для блоков > 4 КБ).
4. Интерфейс пользователя:кошельки TON (Tonkeeper, MyTonWallet);веб‑приложение GLC.

2.2. Интеграция с TON

1. TVM — исполнение смарт‑контрактов.
2. TON Storage — хранение чанков блоков.
3. Блокчейн TON — фиксация транзакций и dataroot.
4. Стандарт Jetton — эмиссия и оборот GLC.

3. Алгоритм консенсуса Proof‑of‑Fortune

3.1. Принципы работы

1. Децентрализация: отсутствие выделенных валидаторов.
2. Энергоэффективность: нет вычислительных гонок (как в PoW).
3. Инклюзивность: порог участия — 10 GLC без стейкинга.
4. Доказуемая честность: выбор победителя на основе VRF.
5. Мгновенная финализация: блок считается действительным после проверки смарт‑контрактом.

3.2. Этапы раунда

1. Инициализация:смарт‑контракт публикует:round_id;vrf_seed (на основе хэша последнего блока TON);минимальный порог участия: 10 GLC.
2. round_id;
3. vrf_seed (на основе хэша последнего блока TON);
4. минимальный порог участия: 10 GLC.
5. Участие пользователя:участник с балансом ≥ 10 GLC:локально вычисляет vrf_output = VRF(sk, vrf_seed);генерирует proof (доказательство корректности VRF);подписывает транзакцию своим sk;отправляет в сеть:vrf_output, proof, signature;public_key, glc_id (идентификатор в GLC).
6. Верификация смарт‑контрактом:проверка баланса (≥ 10 GLC);верификация signature по public_key;подтверждение proof относительно vrf_seed и public_key.
7. Выбор победителя:контракт выбирает участника с минимальным vrf_output (или его хэшем).победитель идентифицируется по public_key и glc_id.
8. Формирование блока:смарт‑контракт:собирает данные раунда (участники, победители, награды);формирует блок (см. раздел 5);подписывает блок от имени победителя;фиксирует блок в цепочке через prev_block_hash.
9. Разрешение споров:любой участник может подать доказательство в контракт‑арбитр; при выявлении несоответствия блок помечается как спорный (dispute_flag = true).

4. Форматы данных

4.1. Транзакция участника

4.2. Структура блока

Header:

1. room_id: string;
2. round: uint64;
3. timestamp: uint64 (Unix time);
4. prev_block_hash: bytes32;
5. vrf_seed: bytes32;
6. vrf_output: bytes32;
7. winner_public_key: bytes32;
8. winner_glc_id: string;
9. signature: bytes64 (подпись смарт‑контракта);
10. merkle_root: bytes32;
11. dispute_flag: bool.

Body:

1. participants: array (список glc_id);
2. winners: array (индексы победителей);
3. selection_type: string (например, «pairs», «groups»);
4. glc_reward: uint64 (награда в GLC).

5. Механизмы безопасности

5.1. Криптографическая защита

1. VRF: гарантирует невозможность подделки vrf_output без sk.
2. Подпись транзакции: подтверждает авторство заявки.
3. Merkle Root: обеспечивает целостность списка участников.

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

1. Награды: выплачиваются победителю в GLC.
2. Штрафы: применяются к участникам со спорными блоками (часть наград перераспределяется).
3. NFT‑талисманы: дают бонус к вероятности выбора (коэффициент ≤ 1.5).

5.3. Защита от атак

1. DoS‑атаки: ограничение числа заявок на раунд.
2. Подмена ключей: верификация public_key через signature.
3. Двойная отправка: проверка уникальности round_id и glc_id.

6. Экономическая модель

6.1. Токен GLC

1. Стандарт: Jetton (TON).
2. Эмиссия: фиксированная, регулируется смарт‑контрактом.
3. Назначение: оплата комиссий, награды, участие в раундах.

6.2. Награды и комиссии

1. Награда победителю: 50 GLC за блок.
2. Комиссия за транзакцию: 0.1 GLC.
3. Штраф за спорный блок: 10 GLC (перераспределяется между участниками).

6.3. Порог участия

1. Минимальный баланс: 10 GLC (не блокируется).
2. Доступ: любой владелец ≥ 10 GLC может участвовать в раунде.

7. Интеграция с экосистемой TON

7.1. Используемые компоненты

1. TVM: исполнение смарт‑контрактов GLC.
2. TON Storage: хранение чанков больших блоков.
3. Кошельки TON: аутентификация участников.
4. Блокчейн TON: фиксация транзакций и состояния сети GLC.

7.2. Взаимодействие

1. Хэш блока TON → источник vrf_seed.
2. Jetton‑токены → оборот GLC.
3. TVM‑смарт‑контракты → логика PoF.