Аварійне відновлення

Модель відновлення

BroSettlement MPC використовує поріг 2-of-3:

Звичайне підписання використовує A+B. Під час аварійного відновлення тимчасово об'єднуються B+C, які можуть створити дійсний threshold signature без Share A та без будь-якого API BroSettlement.

Ніколи не зберігайте B і C на одному хості, у файловій системі, на диску, у vault, cloud account, backup set, recovery medium або одному адміністративному домені поза короткою процедурою відновлення. Ніколи не надавайте стороннім особам доступ до жодної share.

Підтримуваний сценарій відновлення

Відкритий skill brosettlement-disaster-recovery зараз підтримує:

• рівно одну native TRX- або стандартну TRC-20-транзакцію за один запуск;
• TRON Nile testnet або TRON mainnet;
• точний пошук source address у обмеженому діапазоні m/44'/195'/0'/0/index;
• автентифіковані artifacts Share B + Share C, створені в одній MPC/DKG-сесії;
• створення через публічний TRON RPC, локальне threshold signing, збереження signed JSON із правами 600, перевірку підпису та негайне відправлення в мережу.

Необов'язкова адреса token contract перемикає CLI у режим TRC-20; якщо її не передано, використовується native TRX. Skill не підтримує довільні smart-contract calls, інші мережі, звичайні withdrawals або режим лише підписання чи офлайн-результату. Він не викликає BroSettlement API або Console і не потребує API credentials.

Передумови

Підготуйте уповноваженого оператора, затверджену процедуру відновлення, чистий контрольований клієнтом host із Go 1.24 або новішим і зашифрований тимчасовий workspace поза папками cloud sync.

Також потрібні незмінний artifact Share B .primary.json, відповідний artifact Share C .recovery.json, оригінальний 32-byte share-encryption key, source і destination TRON addresses, точна amount, вибрана network та новий абсолютний output path. Для TRC-20 додатково передайте адресу smart contract токена та явний максимальний fee limit у TRX.

Share B, Share C і файл encryption key мають бути різними regular files із правами 600. Не вставляйте їхній вміст в AI-чат, command argument, log, ticket, email або shared drive. Передавайте агенту лише абсолютні локальні шляхи.

Процедура відновлення

1. Встановіть усі три Agent Skills та активуйте $brosettlement-disaster-recovery.
2. Підтвердьте, що це свідома recovery operation, оскільки звичайне підписання A+B недоступне або непридатне.
3. До фінального execution window зберігайте B і C у різних custodians або trust domains. Вимкніть screen sharing, session recording, shell tracing, cloud sync і доступ сторонніх осіб.
4. Передайте лише несекретні параметри транзакції та абсолютні локальні шляхи. Skill перевірить pinned Go module, збере приватний тимчасовий binary, перевірить metadata файлів і підтвердить, що output path ще не існує.
5. Перевірте фінальне резюме з network, source, destination, точною amount і output path. Явно підтвердьте саме цю транзакцію. Для mainnet це переміщує реальні кошти, а broadcast не можна скасувати.
6. CLI запускається рівно один раз. Він автентифікує обидва artifacts, доводить, що B+C належать одному quorum, виводить і перевіряє source address, створює та перевіряє транзакцію, виконує threshold signing, незалежно перевіряє signature, зберігає signed JSON і відправляє транзакцію.
7. Вважайте операцію успішною лише після BROADCAST_ACCEPTED, усіх успішних validation flags і повернення публічного txId. Збережіть signed JSON як audit evidence, потім завершіть процедуру та знову розділіть B і C.

Будь-яка зміна network, source, destination, amount або output path потребує нового явного підтвердження.

Source-only CLI

Skill містить recovery-tron-sign.go, go.mod і go.sum:

go run ./recovery-tron-sign.go \
  --network <nile|mainnet> \
  --source <SOURCE_ADDRESS> \
  --to <DESTINATION_ADDRESS> \
  --amount <TRX_AMOUNT> \
  --output </ABSOLUTE/PATH/TO/NEW-SIGNED-TRANSACTION.json> \
  --share-b </ABSOLUTE/PATH/TO/SHARE-B.primary.json> \
  --share-c </ABSOLUTE/PATH/TO/SHARE-C.recovery.json> \
  --encryption-key </ABSOLUTE/PATH/TO/share-encryption.key>

Для TRC-20 додайте:

  --token-contract <TRC20_CONTRACT_ADDRESS> \
  --fee-limit-trx <MAXIMUM_TRX_FEE>

--token-contract — необов'язковий параметр. Без нього CLI переказує native TRX. З ним CLI читає публічні decimals() і token balance, симулює точний виклик transfer(address,uint256) та створює його через вибраний публічний TRON RPC.

CLI відхиляє відносні шляхи до protected inputs, symlinks, inputs без прав 600, невідповідні artifacts, розбіжність source address, наявний output file, некоректну amount, недостатній native TRX або token balance, недійсну RPC transaction або помилковий signature.

Обробка успіху та помилок

Успішний результат містить status: BROADCAST_ACCEPTED, derivedAddressMatch: true, artifactsMatch: true, signatureVerified: true, broadcastPerformed: true, broadcastAccepted: true, очікувані поля транзакції та непорожній txId.

Signed JSON записується до спроби broadcast. Якщо виконання завершилося помилкою після появи цього файла, не запускайте процес повторно без перевірки. Збережіть файл, перевірте лише його публічні поля транзакції та знайдіть txID у відповідному TRON explorer. Кожна повторна спроба потребує нового output path і нового підтвердження конкретної транзакції.

Завершення процедури

1. Зупиніть усі recovery processes і видаліть тимчасовий binary.
2. Видаліть або unmount кожну локальну share з recovery host, не видаляючи основні backups.
3. Поверніть B і C до різних trust та administrative domains.
4. Знищте ключ зашифрованого тимчасового workspace або ephemeral environment за затвердженою процедурою клієнта. Не покладайтеся на твердження про secure deletion для SSD.
5. Підтвердьте, що B і C більше не зберігаються разом і жодна стороння особа не має до них доступу.

Не послаблюйте cryptographic, artifact-binding, address-binding або signature checks заради завершення відновлення.