> 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/bezopasnost-i-razrabotchiki/model-bezopasnosti.md).

# Модель безопасности

### Архитектура вытягивающих платежей

NovaCont не отправляет средства получателям принудительно. Вместо этого все распределения средств записываются как кредиты в маппинге `pendingWithdrawals`, и получатели инициируют собственные выводы явно.

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

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

<figure><img src="/files/Eb0KqnBaXRDzd8QWaNwA" alt=""><figcaption></figcaption></figure>

### Защита от повторного входаProtection

Все функции, взаимодействующие с балансами ETH или ERC-20, помечены модификатором `nonReentrant` из ReentrancyGuard OpenZeppelin. Этот модификатор использует переменную блокировки для обеспечения того, что ни одна функция в контракте не может быть вызвана рекурсивно — при попытке повторного входа транзакция немедленно откатывается.

Переводы ERC-20 используют обёртку `SafeERC20` OpenZeppelin, которая корректно обрабатывает нестандартные реализации токенов и откатывается при неудачных переводах, а не молча завершается успешно с ложным возвращаемым значением.

### Контроль доступа

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

**Резолвер** — Назначенный адрес, уполномоченный урегулировать споры в управляемом режиме. По умолчанию равен владельцу при развёртывании. Может быть изменён владельцем в любое время. При активации системы присяжных резолвер автоматически устанавливается на адрес контракта NovaJury.

**onlyJuryContract** — Модификатор, ограничивающий определённые функции урегулирования исключительно зарегистрированным адресом NovaJury. Не может быть вызван владельцем, резолвером или любым внешним участником.

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

### Экстренная пауза

Владелец контракта может вызвать `pause()` в любое время для остановки всех операций, изменяющих состояние. Это предназначено как экстренная мера в случае обнаруженной уязвимости или продолжающейся атаки.

При паузе:

* Новые контракты не могут быть созданы
* Переходы состояний не могут быть инициированы
* Выводы из `pendingWithdrawals` остаются полностью функциональными — пользователи всегда могут вернуть зачисленные средства

Контракт может быть возобновлён владельцем в любое время через `unpause()`.

### Известные ограничения и допущения

**Псевдослучайный выбор присяжных:** Назначение присяжных использует псевдослучайный механизм в сети, основанный на `blockhash`, `prevrandao`, `gasleft` и инкрементируемом нонсе. Это не криптографически безопасная случайность. Валидатор с достаточным контролем над производством блоков теоретически мог бы влиять на результаты выбора присяжных. При текущем масштабе протокола этот риск считается приемлемым, но признаётся как ограничение. Интеграция с верифицируемым решением случайности, таким как Chainlink VRF, является потенциальным будущим обновлением.

**Зависимость от оракула:** NovaCont опирается на ценовые фиды Chainlink для расчёта депозитов. Длительный простой оракула или скомпрометированный фид могут повлиять на точность конвертации USD в токены. 24-часовая проверка устаревания снижает этот риск, но не устраняет его полностью.

**Отсутствие механизма апелляции:** Вердикты по спорам — будь то вынесенные администратором или присяжными — являются окончательными и необратимыми после исполнения в сети. Процесса апелляции не существует. Пользователям следует подходить к спорам с полными и хорошо организованными доказательствами с самого начала.

**Доказательства вне сети:** URI доказательств указывают на ресурсы вне сети. NovaCont не может гарантировать постоянство или целостность этих ресурсов. Исполнитель или клиент, предоставивший ссылку, которая впоследствии становится недоступной, несёт последствия этой недоступности при любой оценке спора.

### Анализ поверхности атаки

Понимание наиболее уязвимых мест смарт-контракта так же важно, как понимание того, что он делает. Ниже приведена честная оценка основных поверхностей атаки NovaCont и мер по их снижению.

#### cancelContract — Путь доступа владельца

Функция `cancelContract` содержит путь контроля доступа, заслуживающий явной документации. Оператор require выглядит следующим образом:

```
require(canCancel || msg.sender == owner(), "Cannot cancel");
```

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

#### settleDispute — Валидация разделения

Функция урегулирования администратором применяет строгий инвариант:

```
require(_clientRefund + _grossProviderPayment == c.totalLocked)
```

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

#### claimTimeout — Зависимость от времени

Механизм таймаута полагается на `block.timestamp` для проверки 7-дневного окна. Майнеры и валидаторы имеют небольшую степень влияния на временные метки блоков — как правило, в диапазоне от нескольких секунд до нескольких минут. Это не является значимым вектором атаки для 7-дневного окна, но стоит упомянуть как общее свойство логики, зависящей от временных меток. NovaCont не использует временные метки для чего-либо, где точность на уровне секунд является критически важной для безопасности.

### Соображения по фронтраннингу

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

**Фронтраннинг цены оракула:** Когда клиент вызывает `createContract`, цена ETH/USD извлекается из Chainlink в этом точном блоке. Искушённый участник теоретически мог бы наблюдать ожидающую транзакцию `createContract`, предсказать цену оракула в момент включения и разработать атаку вокруг этого. Однако здесь нет значимого доступного эксплойта — клиент сам блокирует свои средства, и цена оракула влияет только на то, сколько ETH он должен отправить, а не на то, могут ли быть похищены средства.

**Фронтраннинг спора:** Исполнитель, видящий транзакцию `disputeWork` клиента в мемпуле, не может использовать фронтраннинг выгодным для себя образом — состояние контракта допускает только один открытый спор, и спор может быть открыт только в состоянии «Доставлен». Нет состояния гонки, которое позволило бы исполнителю предупредить законный спор.

### Граничные случаи ERC-20

**Состояние гонки при подтверждении:** Стандартная функция ERC-20 `approve` технически уязвима к состоянию гонки, где получатель может наблюдать изменяемое подтверждение и использовать фронтраннинг для расходования как старого, так и нового лимита. NovaCont снижает этот риск, используя `safeTransferFrom` через `SafeERC20`, и пользователям рекомендуется устанавливать лимиты на ноль перед их увеличением при прямом взаимодействии с контрактами, а не через интерфейс приложения.

**Нестандартные возвращаемые значения:** Некоторые токены ERC-20 не возвращают булево значение из `transfer` и `transferFrom`, вопреки спецификации EIP-20. Обёртка `SafeERC20` OpenZeppelin корректно обрабатывает это, проверяя длину возвращаемых данных и считая отсутствующие возвращаемые значения успехом только тогда, когда сам вызов не откатился. Это обеспечивает совместимость с более широким спектром реализаций токенов.

### Риски централизации

NovaCont не является полностью доверенным в своей текущей форме. Следующие возможности владельца представляют допущения централизации, которые пользователи должны оценить перед использованием протокола:

| Capability                                 | Function                                          | Impact                                                                                                   |
| ------------------------------------------ | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| Приостановить все операции                 | `pause()`                                         | Останавливает создание контрактов и переходы состояний. Выводы не затрагиваются.                         |
| Отменить любой контракт                    | `cancelContract()`                                | Владелец может принудительно отменить любое соглашение. Клиент всегда получает полный возврат.           |
| Изменить комиссию платформы                | `setPlatformFee()`                                | Комиссия может быть изменена до максимума 10%. Влияет только на будущие расчёты.                         |
| Изменить резолвер                          | `setResolver()`                                   | Может перенаправить полномочия урегулирования споров на любой адрес.                                     |
| Активировать или деактивировать присяжных  | `activateJurySystem()` / `deactivateJurySystem()` | Может переключаться между управляемым и децентрализованным режимами споров в любое время.                |
| Добавить или удалить поддерживаемые токены | `addSupportedToken()` / `removeSupportedToken()`  | Может расширять или ограничивать варианты платежей. ETH или USDT удалить нельзя.                         |
| Обновить ценовые фиды                      | `setPriceFeed()`                                  | Может изменить источник оракула для любого токена. Вредоносный фид мог бы повлиять на расчёты депозитов. |

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

### Статус аудита

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

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

Проведение аудита запланировано как часть пути протокола к развёртыванию в основной сети. Отчёты об аудите будут опубликованы в полном объёме и привязаны к этой документации после их появления.