Обновление архитектуры ключей и кошельков

2026-10-01 17:11:38 +03:00
parent f452ce1f1e
commit 8d22602761
51 changed files with 565 additions and 898 deletions
@@ -0,0 +1,48 @@
+# Переработать authority Solana PDA через Recovery key
+
+## Статус
+
+**Не делать в текущем patch.** Solana smart contract и существующие правила `shine_users` пока остаются без изменений.
+
+Причина: текущий контракт рабочий, а окончательная модель прав ещё требует отдельного решения и тестов. Не смешивать эту переработку с UI/кошельками/хранением ключей.
+
+## Текущая модель
+
+- обычные `update_user_pda` авторизуются активным `blockchain key`;
+- полная ротация root + client + blockchain использует старый `root/recovery key` как дополнительное recovery-разрешение;
+- новый blockchain key подписывает новое состояние по текущему протоколу;
+- увеличение платного лимита также проходит через текущую схему обычного update.
+
+## Желаемое направление
+
+Recovery key логически должен быть главным ключом для критического управления аккаунтом, например:
+
+- смена recovery/root key;
+- смена blockchain key / создание нового fork;
+- смена client key;
+- смена access server;
+- изменение критических настроек серверов/доступа.
+
+При этом простое **увеличение оплаченного лимита** не должно заставлять пользователя вводить пароль и временно восстанавливать Recovery private key.
+
+## Предпочтительный вариант для исследования
+
+Не исключать отдельные поля PDA из цифровой подписи. Подпись должна покрывать всё авторизуемое состояние целиком.
+
+Вместо этого разделить Solana-инструкции по полномочиям:
+
+1. `top_up_limit(...)` — узкая экономическая инструкция, которая умеет только увеличить `paid_limit`/`additional_limit` и физически не может менять identity, ключи или серверы. Recovery не требуется.
+2. `rotate_keys(...)` / критический `update_account(...)` — изменение root/client/blockchain identity, требует Recovery-authority; отдельно решить, нужна ли совместная подпись текущего blockchain key.
+3. `update_servers(...)` — критические server/access-server изменения, вероятно требуют Recovery-authority; окончательное правило зафиксировать после threat-model.
+
+Возможная усиленная схема для критических изменений: текущий blockchain key + текущий Recovery key подписывают один и тот же hash полного нового состояния, а при ротации новый blockchain key дополнительно доказывает владение новым ключом.
+
+## Обязательные тесты перед изменением контракта
+
+- compromised blockchain key не может захватить identity без Recovery;
+- Recovery может безопасно восстановить аккаунт после компрометации blockchain key;
+- top-up лимита не может изменить ни один identity/server field;
+- replay старой подписи невозможен;
+- смена любого ключа атомарна;
+- fee payer не обязан совпадать с Recovery key;
+- crash/retry не оставляет PDA в промежуточном состоянии.