# Ідентичність

> Ідентичність у NeuroChain — стабільна адреса, ключі керування якою можна змінювати, і соціальне відновлення з опікунами, порогом і часовим блокуванням, яке власник може заветувати, — усе застосовується в консенсусі.

Source: https://docs.nro.world/uk/ai/identity

Адреса `.human` спочатку є чистою функцією одного публічного ключа. **Ідентичність** дає адресі пережити ключ: набір ключів, що нею керують, зберігається в стані мережі, тож ключі можна **замінювати**, а в разі втрати — **відновлювати**, не змінюючи адреси, її балансу, імен чи історії.

## До і після першої заміни ключів

| Стан | Хто керує адресою |
|------|-------------------|
| Ключі не замінювали, відновлення не налаштовано | Ключ, з якого виведено адресу (`address = f(публічний ключ)`) |
| Запис ідентичності існує | **Лише** ключі з запису. Початковий ключ перестає працювати, щойно його вилучено |

Запис створюється, коли ви вперше замінюєте ключі чи налаштовуєте відновлення. Платні імена (`.node`, `.app`, `.vault`, `.agent`) слідують за ідентичністю гаманця `.human`, якому належать.

```bash
curl -s "$GATEWAY/api/v1/identity/neuro:<15 hex>.human"
# { "address": "…", "keys": ["<pk1>", "<pk2>"], "version": 2, "rotated_at": 4210, "recovery": { … } }
```

## Заміна ключів

`POST /api/v1/identity/rotate` з `owner`, `add` (публічний ключ, який треба додати, або порожньо), `remove` (публічний ключ, який треба вилучити, або порожньо), підписаний **чинним** ключем над:

```
nc-rotate|<owner>|<add>|<remove>|<nonce>
```

- Останній ключ вилучити неможливо.
- Підпис покриває точну зміну, тож ніхто не може змінити її дорогою.
- Застосовується в консенсусі на кожному валідаторі.

Типовий перехід на новий пристрій: додайте новий ключ зі старого пристрою, а потім вилучіть старий ключ новим.

## Соціальне відновлення

Якщо всі ключі втрачено, доступ можуть відновити **опікуни**.

### Налаштування

`POST /api/v1/identity/recovery/setup` — підписаний чинним ключем:

| Поле | Правило |
|------|---------|
| `guardians` | Одна чи кілька адрес `.human`, не ваша власна |
| `threshold` | Скільки опікунів мають схвалити: від 1 до кількості опікунів |
| `timelock` | Скільки блоків чекати після досягнення порогу, щоб ви встигли заветувати |

Відновлення доступне лише для адрес `.human`.

### Відновлення

1. **Запит** — з нового пристрою `POST /api/v1/identity/recovery/request` з `target` (ваша адреса) і `new_key`, підписаний новим ключем. Статус `pending`.
2. **Схвалення** — кожен опікун викликає `POST /api/v1/identity/recovery/approve` (`target`, `guardian`). Коли схвалень досягає порогу, запит стає `armed` з `executes_at = now + timelock`.
3. **Виконання** — на `executes_at` кожен валідатор автоматично замінює ключі ідентичності на `new_key`.

У будь-який момент до виконання:

| Хто | Може | Ендпоінт |
|-----|------|----------|
| Ви, будь-яким чинним ключем | Заветувати | `POST /api/v1/identity/recovery/cancel` |
| Опікун | Відхилити | `POST /api/v1/identity/recovery/reject` |
| Ініціатор запиту | Відкликати | `POST /api/v1/identity/recovery/withdraw` |

Читання: `GET /api/v1/identity/recovery/:addr` (налаштування й відкритий запит), `GET /api/v1/identity/guardian-of/:addr` (кого ви охороняєте), `GET /api/v1/identity/recovery/initiated/:pk` (запити, розпочаті новим ключем).

::: tip Обирайте часове блокування уважно
Часове блокування — ваше вікно, щоб помітити відновлення, якого ви не починали. Надто коротке — і змовлені опікуни заберуть адресу, перш ніж ви зреагуєте; надто довге — і справжнє відновлення триватиме стільки ж.
:::

## Заплановано

Запис ідентичності має нести більше, ніж ключі: репутацію, побудовану з поведінки в мережі, доказ з нульовим розголошенням для неї та пакет IBC v2, що дозволить іншій мережі її прочитати. Нічого з цього ще немає.
