40.1. Назначение Event Ledger

YAHCHAIN EVENT LEDGER представляет собой техническую систему последовательной регистрации событий игровой партии.

Её назначение — обеспечивать воспроизводимость ходов, проверку начисления очков, учёт игрового времени, регистрацию судейских решений и независимый аудит.

Event Ledger не является игровой Сотой.

Event Ledger не является игровым Blockchain.

Event Ledger не является обязательной криптовалютной или финансовой системой.

Он представляет собой отдельный технический слой учёта событий.

40.2. Разграничение трёх понятий

В YAHchain необходимо строго различать:

1. Сота — игровая позиция, в которой размещаются карты.
2. Игровой Blockchain — допустимая последовательность карт, сформированная по утверждённым правилам.
3. Event Ledger — техническая история зарегистрированных событий.

Эти понятия имеют разные функции и не являются взаимозаменяемыми.

Дополнительно различаются игровые очки, рейтинговые единицы и денежные расчёты.

Регистрация игрового события сама по себе не создаёт денежного обязательства.

40.3. Основной принцип последовательного журнала

Event Ledger строится по принципу последовательного добавления записей.

Каждое подтверждённое событие получает порядковый номер и уникальный идентификатор.

После подтверждения запись не должна незаметно изменяться или удаляться.

При необходимости исправления создаётся новое событие, связанное с исправляемой записью.

Таким образом сохраняется не только итоговый результат, но и история его получения.

40.4. Идентификация партии

Каждая партия получает уникальный GAME_ID.

С партией связываются:

• Идентификатор мероприятия.
• Идентификатор площадки.
• Версия игровых правил.
• Версия Event Ledger.
• Режим хронометрии.
• Состав участников.
• Назначение Сот.
• Порядок активации.
• Начальные игровые параметры.
• Статус подтверждения результата.

При онлайн-игре дополнительно фиксируется идентификатор серверной сессии.

При телевизионной партии может фиксироваться идентификатор выпуска и записи.

40.5. Командная модель данных

Event Ledger должен поддерживать как индивидуальную, так и командную игровую Соту.

Для команды регистрируются:

1. TEAM_ID.
2. Название команды.
3. Список участников.
4. Идентификатор капитана.
5. Закреплённая Сота.
6. Время назначения.
7. Допустимые замены участников.
8. Статус команды.

Один командный ход регистрируется как одно официальное игровое действие.

Внутреннее обсуждение команды не требует регистрации каждой произнесённой реплики.

Event Ledger фиксирует подтверждённое решение и совершённое действие.

40.6. Основные категории событий

События разделяются на функциональные категории.

40.6.1. События партии

• GAME_REGISTERED;
• GAME_CONFIGURED;
• GAME_STARTED;
• GAME_PAUSED;
• GAME_RESUMED;
• GAME_RESULT_CONFIRMED;
• GAME_CLOSED.

40.6.2. События участников

• PLAYER_REGISTERED;
• TEAM_REGISTERED;
• TEAM_ASSIGNED_TO_SOTA;
• TEAM_CAPTAIN_APPOINTED;
• TEAM_MEMBER_REPLACED.

40.6.3. Игровые действия

• SOTA_ACTIVATED;
• TURN_STARTED;
• MOVE_SUBMITTED;
• MOVE_REJECTED;
• MOVE_ACCEPTED;
• TURN_COMPLETED.

40.6.4. Blockchain и игровые очки

• BLOCKCHAIN_CANDIDATE_DETECTED;
• BLOCKCHAIN_CONFIRMED;
• BLOCKCHAIN_REJECTED;
• SCORE_CALCULATED;
• SCORE_CONFIRMED;
• SCORE_CORRECTED.

40.6.5. Хронометрия

• TIME_CONTROL_LOCKED;
• CLOCK_ACTIVATED;
• TURN_TIMER_STARTED;
• EARLY_MOVE_DECLARED;
• TURN_TIMER_STOPPED;
• TURN_TIMER_PAUSED;
• TURN_TIMER_RESUMED;
• TIME_BUDGET_UPDATED;
• TIME_LIMIT_EXPIRED;
• CLOCK_ADJUSTMENT_APPROVED.

40.6.6. Звуковое производство

• METRONOME_STARTED;
• METRONOME_PAUSED;
• METRONOME_RESUMED;
• METRONOME_STOPPED.

40.6.7. Телезрители

• VIEWER_POLL_OPENED;
• VIEWER_VOTE_ACCEPTED;
• VIEWER_POLL_CLOSED;
• VIEWER_RESULT_CONFIRMED;
• VIEWER_MOVE_SELECTED.

40.6.8. Судейские корректировки

• REFEREE_REVIEW_OPENED;
• REFEREE_DECISION_RECORDED;
• EVENT_CORRECTION_RECORDED;
• GAME_STATE_RESTORED.

Каталог событий является расширяемым, но изменения должны сопровождаться новой версией технической спецификации.

40.7. Структура одной записи события

Минимальная нормализованная запись может содержать:

• event_id;
• game_id;
• sequence_number;
• event_type;
• timestamp_utc;
• actor_id;
• sota_id;
• team_id;
• turn_id;
• rules_version;
• payload;
• previous_hash;
• event_hash.

Для событий с отсутствующими значениями соответствующие поля могут содержать null.

Типизированная схема определяет обязательные поля для каждого вида события.

40.8. Пример JSON-записи игрового хода

{
  "event_id": "evt-000057",
  "game_id": "yah-live-demo-001",
  "sequence_number": 57,
  "event_type": "MOVE_ACCEPTED",
  "timestamp_utc": "2026-11-05T10:00:57Z",
  "actor_id": "captain-team-7",
  "team_id": "team-7",
  "sota_id": 7,
  "turn_id": "turn-7-1",
  "rules_version": "41-draft",
  "payload": {
    "card_id": "card-example-17",
    "action": "PLACE_CARD",
    "target_sota": 7,
    "validation": "ACCEPTED"
  },
  "previous_hash": "EXAMPLE_PREVIOUS_HASH",
  "event_hash": "EXAMPLE_EVENT_HASH"
}

Пример иллюстрирует структуру данных.

Строки EXAMPLE_PREVIOUS_HASH и EXAMPLE_EVENT_HASH не являются реальными криптографическими хешами.

Фактические значения вычисляются системой по утверждённому алгоритму.

40.9. Криптографическая связность журнала

Для контроля целостности может использоваться криптографическая хеш-цепочка.

Каждая запись содержит хеш предыдущей записи.

Хеш текущей записи вычисляется на основании канонического представления её содержимого и связанного предыдущего хеша.

Условная формула:

H(n) = SHA-256( CanonicalEvent(n) )

В CanonicalEvent(n) включается previous_hash, но не включается само вычисляемое поле event_hash.

Для независимой совместимости необходимо утвердить правила канонической сериализации, кодировку UTF-8, порядок полей, обработку чисел и пустых значений.

Хеш-цепочка позволяет обнаруживать изменения в имеющейся последовательности записей.

Однако она сама по себе не доказывает, что первоначально внесённые данные соответствовали фактическим событиям.

Для более сильной проверки могут использоваться цифровые подписи, независимые контрольные точки и внешнее временное удостоверение.

40.10. Авторитетное игровое время

В официальной цифровой партии время измеряется авторитетным игровым контроллером.

В онлайн-версии таким контроллером обычно является сервер.

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

В телевизионной версии CHRONOS-12 обеспечивает управление временем двенадцати Сот.

Метроном и эфирная графика получают временное состояние от контроллера.

Они не являются самостоятельными источниками официального времени.

40.11. Режимы игровой хронометрии

Event Ledger поддерживает три базовых режима:

1. FIXED-60.
2. TIME-BANK.
3. HYBRID-60.

В FIXED-60 каждый ход ограничен 60 секундами без переноса остатка.

В TIME-BANK игрок, команда или Сота получает общий бюджет на серию ходов.

В HYBRID-60 общий бюджет сочетается с максимальной продолжительностью 60 секунд на отдельный ход.

Пример: 20 минут на 20 ходов с лимитом 60 секунд на один ход.

Режим фиксируется событием TIME_CONTROL_LOCKED до начала соревновательной партии.

40.12. Модель временного бюджета Соты

Для каждой Соты может храниться отдельный временной бюджет.

Базовые поля:

• sota_id;
• time_control_mode;
• initial_budget_ms;
• remaining_budget_ms;
• turn_limit_ms;
• completed_turns;
• active_turn_id;
• timer_status.

Для накопительного режима используется формула:

T_remaining = T_initial − ΣT_spent + ΣT_adjustment

Вычисления рекомендуется выполнять в целочисленных миллисекундах.

Остаток времени не должен становиться отрицательным.

При достижении нулевого значения фиксируется соответствующее событие истечения.

40.13. Начало хода

После завершения предыдущего допустимого действия система определяет следующую активную Соту.

Проверяется соответствие очередности утверждённым правилам.

Затем фиксируются:

1. SOTA_ACTIVATED.
2. TURN_STARTED.
3. TURN_TIMER_STARTED.

Для телевизионного формата может дополнительно регистрироваться METRONOME_STARTED.

В стандартном последовательном режиме одновременно активен только один официальный таймер хода.

40.14. Досрочное совершение хода

Игрок или капитан может объявить готовность до окончания предоставленного времени.

Такое объявление регистрируется как EARLY_MOVE_DECLARED.

Затем выполняется игровое действие.

Система проверяет его допустимость.

После принятия действия фиксируются:

1. MOVE_ACCEPTED.
2. TURN_TIMER_STOPPED.
3. TIME_BUDGET_UPDATED.
4. TURN_COMPLETED.

При наличии метронома дополнительно регистрируется METRONOME_STOPPED.

Само объявление готовности не завершает официальный ход.

40.15. Пример хронометрического события

{
  "event_id": "evt-000058",
  "game_id": "yah-live-demo-001",
  "sequence_number": 58,
  "event_type": "TURN_TIMER_STOPPED",
  "timestamp_utc": "2026-11-05T10:00:57Z",
  "team_id": "team-7",
  "sota_id": 7,
  "turn_id": "turn-7-1",
  "payload": {
    "time_control_mode": "HYBRID-60",
    "turn_limit_ms": 60000,
    "initial_budget_ms": 1200000,
    "elapsed_ms": 57000,
    "remaining_budget_ms": 1143000,
    "stop_reason": "MOVE_ACCEPTED"
  }
}

В приведённом иллюстративном примере команда использовала 57 секунд.

Из бюджета 20 минут осталось 19 минут 3 секунды.

Следующий ход по-прежнему ограничен 60 секундами, поскольку выбран режим HYBRID-60.

40.16. Монотонные часы и серверное время

Для измерения длительности хода следует использовать монотонный источник времени.

Такой источник предназначен для измерения прошедших интервалов и не должен зависеть от обычных корректировок системных часов.

Отдельно сохраняется временная отметка UTC для регистрации момента события.

Таким образом различаются:

1. Абсолютное время регистрации события.
2. Продолжительность игрового действия.

При восстановлении после технического сбоя используются сохранённые контрольные точки и утверждённая процедура восстановления.

40.17. Остановка и возобновление часов

Официальная остановка времени допускается по предусмотренным регламентом основаниям.

Такими основаниями могут быть:

• Техническая неисправность.
• Судейская проверка.
• Нарушение безопасности.
• Ошибка игрового контроллера.
• Разрешённая процедура доступности.
• Иное утверждённое основание.

Остановка фиксируется событием TURN_TIMER_PAUSED.

Возобновление фиксируется событием TURN_TIMER_RESUMED.

Каждая остановка должна иметь обоснование и идентификатор уполномоченного лица или системы.

При остановке игрового времени метроном также переходит в состояние паузы.

40.18. Истечение временного лимита

Если время истекло до принятия допустимого действия, система фиксирует TIME_LIMIT_EXPIRED.

После истечения лимита новые действия просроченного хода не принимаются автоматически.

Последствие определяется заранее утверждённым игровым регламентом.

Оно может включать пропуск хода, штраф или другое предусмотренное действие.

Event Ledger должен сохранять основание применения соответствующего последствия.

40.19. Ошибочный игровой ход

Если игрок отправляет недопустимое действие, система фиксирует MOVE_REJECTED.

Причина отказа должна быть определена в соответствии с утверждёнными правилами.

По умолчанию отправка недопустимого действия не останавливает игровой таймер.

Время продолжает расходоваться до принятия допустимого хода или истечения лимита.

Исключения должны иметь отдельное судейское основание.

40.20. Метроном и производственные события

Метроном является звуковым производственным слоем.

Он получает состояние от официального игрового контроллера.

Могут регистрироваться:

• METRONOME_STARTED;
• METRONOME_PAUSED;
• METRONOME_RESUMED;
• METRONOME_STOPPED.

Эти записи предназначены для проверки синхронизации и восстановления производственной последовательности.

Метроном не определяет фактическую продолжительность хода.

При расхождении звука и официального таймера приоритет имеет подтверждённое игровое время.

40.21. Участие телезрителей

Event Ledger поддерживает три режима зрительского участия:

1. VIEWER POLL.
2. VIEWER ADVISORY.
3. VIEWER TEAM.

Для голосования фиксируются:

• Идентификатор голосования.
• Связанная партия.
• Активная Сота.
• Перечень вариантов.
• Время открытия.
• Время закрытия.
• Правила подсчёта.
• Итоговые показатели.
• Статус подтверждения.

Персональные данные участников голосования не должны без необходимости включаться в публичную версию журнала.

При необходимости проверки уникальности используются отдельные защищённые идентификаторы и контрольные механизмы.

40.22. Пример результата зрительского голосования

{
  "event_type": "VIEWER_RESULT_CONFIRMED",
  "game_id": "yah-live-demo-001",
  "poll_id": "poll-7-1",
  "sota_id": 7,
  "payload": {
    "mode": "VIEWER_ADVISORY",
    "total_valid_votes": 1000,
    "results": {
      "A": 560,
      "B": 320,
      "C": 120
    },
    "recommended_option": "A",
    "binding": false
  }
}

Значения являются иллюстративными.

Поле binding показывает, является ли результат голосования обязательным для определения хода.

В режиме VIEWER ADVISORY оно имеет значение false.

При режиме VIEWER TEAM должна применяться отдельная утверждённая процедура преобразования результата голосования в допустимый ход.

40.23. Проверка Blockchain

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

Если обнаружен кандидат на Blockchain, регистрируется BLOCKCHAIN_CANDIDATE_DETECTED.

После проверки создаётся BLOCKCHAIN_CONFIRMED либо BLOCKCHAIN_REJECTED.

Для подтверждённой комбинации сохраняются:

1. Сота или набор игровых позиций.
2. Последовательность карт.
3. Версия правил.
4. Метод оценки.
5. Результат проверки.
6. Начисленные игровые очки.

Event Ledger не должен самостоятельно изобретать новые комбинации или значения очков.

Он применяет утверждённую игровую спецификацию.

40.24. Три метода расчёта результата

В соответствии с системой разграничения игровых очков могут использоваться различные утверждённые методы оценки.

1. Сумма весов карт без дополнительного бонуса.
2. Сумма весов карт с утверждённым бонусом комбинации.
3. Отдельная стоимость комбинации по справочной таблице редкости.

Каждая партия должна содержать ссылку на применяемый метод оценки.

Система не должна смешивать результаты различных методов без специально утверждённого правила пересчёта.

Время хода не изменяет стоимость Blockchain по умолчанию.

40.25. Повторное воспроизведение партии

На основании подтверждённой последовательности событий система должна иметь возможность восстановить состояние партии.

Воспроизведение включает:

1. Начальную конфигурацию.
2. Назначение Сот.
3. Последовательность ходов.
4. Размещение карт.
5. Подтверждение Blockchain.
6. Начисление очков.
7. Изменение временных бюджетов.
8. Судейские корректировки.
9. Окончательный результат.

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

Однако видеозапись не должна подменять официальную последовательность зарегистрированных событий.

40.26. Корректировки и компенсирующие события

Если ранее подтверждённая запись содержит ошибку, она не должна незаметно удаляться.

Создаётся корректирующее событие со ссылкой на исходную запись.

Корректировка должна содержать:

• Идентификатор исходного события.
• Причину исправления.
• Идентификатор уполномоченного лица.
• Время решения.
• Исправленное значение.
• Последствия для игрового состояния.

Если корректировка затрагивает игровые очки или время, соответствующее состояние пересчитывается по утверждённой процедуре.

Все изменения должны оставаться проверяемыми.

40.27. Восстановление после технического сбоя

Система должна предусматривать контрольные точки состояния партии.

Контрольная точка может содержать:

1. Последний подтверждённый номер события.
2. Состояние всех двенадцати Сот.
3. Положение карт.
4. Игровые очки.
5. Активную Соту.
6. Остатки временных бюджетов.
7. Состояние таймера.
8. Версию правил.

После восстановления система проверяет целостность сохранённой последовательности.

Затем воспроизводит подтверждённые события до последнего достоверного состояния.

Если требуется судейская корректировка, она регистрируется отдельно.

40.28. Независимый аудит

Независимая проверка должна позволять установить:

1. Подлинность доступной версии журнала.
2. Последовательность событий.
3. Соответствие действий правилам.
4. Корректность формирования Blockchain.
5. Правильность начисления очков.
6. Соблюдение временных лимитов.
7. Основания судейских корректировок.
8. Корректность подтверждения результатов.

Аудитор должен получать необходимые данные в пределах своих полномочий.

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

При этом должна сохраняться возможность проверки официального результата.

40.29. Паб-модель и расчётные события

В программе YAHCHAIN PUBLIC HOUSE PROGRAM Event Ledger может подтверждать факт проведения и завершения партии.

Эти сведения могут использоваться в качестве одного из оснований для договорных расчётов с заведением.

Однако игровой журнал не должен смешиваться с бухгалтерской системой выплат.

Финансовая система может ссылаться на GAME_ID и подтверждённый статус партии.

Размер выплаты и основание денежного обязательства определяются отдельным договором.

Игровые очки не являются автоматически денежными средствами.

40.30. Телевизионное производство

Для YAHCHAIN LIVE Event Ledger обеспечивает единый источник подтверждённых игровых событий.

Телевизионная графика получает данные о:

• Номере активной Соты.
• Команде.
• Текущем ходе.
• Остатке времени.
• Игровых очках.
• Подтверждённых Blockchain.
• Зрительских результатах.
• Судейских решениях.

Производственная система может использовать эти данные для титров, повторов и аналитических экранов.

При этом телевизионный монтаж не должен изменять исходные игровые события.

40.31. Версионирование и совместимость

Каждая партия должна ссылаться на конкретную версию игровых правил и технической схемы.

При изменении Event Ledger необходимо сохранять возможность прочитать ранее зарегистрированные партии.

Новые типы событий не должны произвольно изменять смысл исторических записей.

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

Исторический результат проверяется по правилам, действовавшим для соответствующей партии, если официальный регламент не предусматривает законную процедуру пересмотра.

40.32. Лицензионный технический стандарт

Программная реализация Event Ledger может входить в состав лицензируемых технических материалов YAHchain.

Объём разрешённого использования определяется соответствующим договором.

Лицензия на телевизионное производство не обязательно включает право копировать, изменять или распространять исходный код игрового сервера.

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

YAHCHAIN INTERNATIONAL FORMAT BIBLE может устанавливать обязательные технические интерфейсы и процедуры проверки совместимости.

Однако договорные требования не создают исключительных прав на абстрактные технические идеи за пределами применимого законодательства.

40.33. Разграничение технического и философского уровней

Event Ledger фиксирует последовательность наблюдаемых игровых событий.

Он не является источником Логоса или Дхармы.

В авторской архитектуре YAHchain философское содержание раскрывается через корректное разворачивание игрового процесса.

Техническая система позволяет проверить, какие действия были совершены, в какой последовательности и с какими игровыми последствиями.

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

Оба уровня сохраняют свои самостоятельные функции.

40.34. Заключительный принцип

YAHCHAIN EVENT LEDGER обеспечивает техническую проверяемость официальных партий.

Он связывает игровые действия, командные решения, шахматные часы, временные бюджеты, метроном, зрительское участие, судейские решения и итоговые результаты.

Каждое событие имеет определённый тип и место в последовательности.

Ошибки исправляются проверяемыми корректирующими событиями.

Игровой Blockchain остаётся карточной последовательностью.

Сота остаётся игровой позицией.

Event Ledger остаётся технической историей событий.

Лицензионный стандарт определяет согласованные требования к официальной реализации.

Логос не продаётся. Дхарма не отчуждается. Лицензируется воспроизводимый формат YAHchain.

Смысл не подменяется технической записью. Техническая запись обеспечивает проверяемость совершённого действия.