> For the complete documentation index, see [llms.txt](https://novacont.gitbook.io/nova-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://novacont.gitbook.io/nova-docs/novacont-docs/russian-novacont-docs/obzor-bezopasnosti-novacont-lite.md).

# Обзор безопасности NovaCont Lite

**Область проверки**

* NovaCont\_Lite.tact

**Методология**

* Ручная проверка кода, проведённая в два раунда: первый раунд исследовал архитектуру и логику переходов состояний, находки были устранены разработчиком; второй раунд верифицировал исправления на уровне исходного кода.
* Статический анализ: Misti

| Серьёзность     | Количество | Категория                                                                                                                                                                                                            |
| --------------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Critical / High | 0          | Нет                                                                                                                                                                                                                  |
| Medium          | 9          | SuboptimalSend: предлагает использовать более газоэффективный message() вместо send(), без функционального риска                                                                                                     |
| Low             | 29         | PreferredStdlibApi (require -> throwUnless), PreferSenderFunction (context().sender -> sender()), EtaLikeSimplifications, UnusedMethodArgument. Всё на уровне оптимизации газа или стиля, без поведенческих различий |

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

**Ручная проверка**

Находки, выявленные в первом раунде проверки, устранённые разработчиком и верифицированные на уровне исходного кода:

**Ошибка порядка мутации состояния в CancelEscrow \[Исправлено]**

В начальной версии локальная переменная «escrow\.state» обновлялась до «STATE\_CANCELLED» *до* того, как вычислялась проверка «escrow\.state == STATE\_CREATED»; поэтому эта проверка всегда давала «false», поскольку переменная уже была изменена. Только условие «acceptTime == 0» фактически действовало, и это условие оказалось безопасным эквивалентом состояния «STATE\_CREATED», поэтому ошибка не имела практического воздействия, но мёртвое условие представляло скрытый риск, который мог молча превратиться в реальную ошибку при будущем рефакторинге. Исходное состояние теперь предварительно сохраняется в переменной «wasNotYetAccepted: Bool», и это предварительно сохранённое значение используется после мутации состояния.

**Риск молчаливой потери средств через SendIgnoreErrors \[Исправлено]**

Все вызовы «send()» были переключены с «SendIgnoreErrors» (который молча проглатывает неудачный перевод) на «SendBounceIfActionFail». Неудачный перевод теперь возвращает транзакцию, обеспечивая согласованность обновления состояния с успешностью перевода. Верифицировано по каждому вызову «send()» в кодовой базе.

**Централизация логики распределения средств \[Исправлено]**

В начальной версии ветка штрафной отмены в «CancelEscrow» содержала собственную логику разделения средств, независимую от «distributeFunds». Это дублирование несло риск того, что исправление, применённое к одному пути, не будет отражено в другом (и действительно, ранняя ошибка оставалась ограниченной именно этой веткой). «CancelEscrow» теперь направляется через единую центральную функцию «distributeFunds(escrowId, escrow, 5000 or 10000)». Это устраняет дублирование кода и гарантирует согласованность расчёта STORAGE\_RESERVE во всех сценариях распределения средств.

**Единая точка отказа в разрешении споров \[Исправлено]**

В начальной версии споры разрешались через зависимость от единого личного аккаунта. Теперь существует пул поддержки, управляемый через «AddSupport»/«RemoveSupport», с циклическим распределением через «nextSupportAssign». При подаче спора («RaiseDispute») он назначается участнику поддержки последовательно. Паттерн обмена с последним элементом в «RemoveSupport» корректно сохраняет синхронизацию index/count/nextAssign.

> Примечание: это не исправление ошибки, а архитектурное улучшение устойчивости. Оно снижает риск централизации, но не устраняет его.

**Риск коллизии EscrowId \[Исправлено]**

В начальной версии клиент мог выбирать свой собственный ID эскроу, создавая риск коллизии, если два разных клиента выбрали одинаковый ID. «escrowId» теперь назначается автоматически и последовательно через «self.escrowCount».

| Находка                                                              | Статус                                                                                                                         |
| -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| Потеря округления при целочисленном делении                          | На уровне «пыли», без измеримого влияния                                                                                       |
| Отсутствие проверки максимальной длины полей description/evidenceUrl | Низкий приоритет, актуально для предсказуемости газа                                                                           |
| Согласованность именования событий (EscrowCreated и др.)             | Косметическое, без функционального риска                                                                                       |
| Не определена минимальная нижняя граница для agreedTon               | Условные проверки > STORAGE\_RESERVE в distributeFunds уже неявно предотвращают риск отрицательного/недействительного перевода |

**Заключение**

Все шесть находок из первоначальной проверки (включая одну находку уровня High и одну Medium) были верифицированы как исправленные в v1.1.0. Статический анализ Misti не обнаружил функциональных уязвимостей безопасности в кодовой базе. После этого раунда верификации NovaCont Lite достиг уровня зрелости, сопоставимого с основными контрактами NovaCont. Независимый аудит третьей стороны по-прежнему рекомендуется, но тщательность и скорость внутреннего процесса проверки являются положительным сигналом.