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

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

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

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

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

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 (запити, розпочаті новим ключем).

Обирайте часове блокування уважно

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

Заплановано

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