Порог отвечает на два вопроса: кто может платить и кто может восстановить
| Схема | Что выдерживает | Главный риск | Когда уместна |
|---|---|---|---|
| 1-of-2 | Недоступность одного ключа | Любой участник действует единолично | Резерв личного кошелька, но не совместный контроль |
| 2-of-2 | Ни один участник не действует один | Потеря или конфликт одного ключа блокирует работу | Две стороны с очень сильным recovery-процессом |
| 2-of-3 | Потерю одного ключа и отсутствие одного участника | Сговор или компрометация любых двух | Типичный малый бизнес с независимым резервным подписантом |
| 3-of-5 | Отсутствие двух участников | Сложнее координация и больше поверхностей хранения | Команда с формальной казначейской процедурой |
- Схема
- 1-of-2
- Что выдерживает
- Недоступность одного ключа
- Главный риск
- Любой участник действует единолично
- Когда уместна
- Резерв личного кошелька, но не совместный контроль
- Схема
- 2-of-2
- Что выдерживает
- Ни один участник не действует один
- Главный риск
- Потеря или конфликт одного ключа блокирует работу
- Когда уместна
- Две стороны с очень сильным recovery-процессом
- Схема
- 2-of-3
- Что выдерживает
- Потерю одного ключа и отсутствие одного участника
- Главный риск
- Сговор или компрометация любых двух
- Когда уместна
- Типичный малый бизнес с независимым резервным подписантом
- Схема
- 3-of-5
- Что выдерживает
- Отсутствие двух участников
- Главный риск
- Сложнее координация и больше поверхностей хранения
- Когда уместна
- Команда с формальной казначейской процедурой
Удобная схема 2-of-3 часто распределяет роли так: операционный ключ у ответственного за платежи, контрольный ключ у руководителя, recovery-ключ у человека или функции, не участвующей в ежедневных переводах. Это не универсальная рекомендация. Важнее, чтобы любые две разрешённые стороны могли встретиться в аварии, а один инцидент не затронул сразу два ключа.
В TRON Owner и Active решают разные задачи
TRON встраивает permission model в account. Каждая permission содержит список адресов с weight и threshold; transaction проходит проверку, когда сумма весов валидных подписей достигает порога. Owner — высший уровень контроля, включая изменение permission configuration. Active permissions предназначены для операций и могут ограничиваться bitmap разрешённых system contract types.
| Permission | Практическая роль | Что проверить | Опасная ошибка |
|---|---|---|---|
| Owner | Изменение структуры контроля и высшие операции | Keys, weights, threshold и независимый recovery | Использовать Owner для каждого ежедневного платежа |
| Active: payments | Разрешённые рабочие transfer/contract calls | Permission_id и operations bitmap | Оставить все system contracts из удобства |
| Active: treasury | Отдельный порог для редких операций | Состав signers и допустимые operation types | Считать имя permission техническим ограничением |
| Witness | Подпись блоков у Super Representative | Только релевантно SR | Использовать как обычную бизнес-роль |
- Permission
- Owner
- Практическая роль
- Изменение структуры контроля и высшие операции
- Что проверить
- Keys, weights, threshold и независимый recovery
- Опасная ошибка
- Использовать Owner для каждого ежедневного платежа
- Permission
- Active: payments
- Практическая роль
- Разрешённые рабочие transfer/contract calls
- Что проверить
- Permission_id и operations bitmap
- Опасная ошибка
- Оставить все system contracts из удобства
- Permission
- Active: treasury
- Практическая роль
- Отдельный порог для редких операций
- Что проверить
- Состав signers и допустимые operation types
- Опасная ошибка
- Считать имя permission техническим ограничением
- Permission
- Witness
- Практическая роль
- Подпись блоков у Super Representative
- Что проверить
- Только релевантно SR
- Опасная ошибка
- Использовать как обычную бизнес-роль
При создании account TRON выдаёт стандартные Owner и Active с одним ключом и threshold 1. Чтобы получить совместный контроль, команда отправляет AccountPermissionUpdate. Это high-risk transaction: payload заменяет полную permission configuration, поэтому пропущенный ключ или неверный threshold может лишить доступа после подтверждения.
Сначала политика на одной странице, потом on-chain настройка
Решения, которые принимают до генерации ключей
- 1Определить активы и операции
Какие сети, токены и contracts используются; кто создаёт заявку; кто проверяет реквизиты; какие операции запрещены рабочему permission.
- 2Назначить независимые роли
Запишите не только имена, но и роль, заместителя, устройство, место backup и способ связи при инциденте. Один человек не должен незаметно контролировать два signers.
- 3Выбрать threshold для работы и recovery
Смоделируйте отпуск, увольнение, потерю устройства и конфликт. Порог должен останавливать одного нарушителя и не блокировать компанию при одном ожидаемом отказе.
- 4Установить правило независимой проверки
Каждый signer получает сумму, сеть, token contract, recipient, назначение и deadline из журнала заявки, а адрес подтверждает не пересланным скриншотом, а исходным каналом.
- 5Согласовать emergency window
Кто объявляет compromise, как быстро оставшиеся signers собираются, какой новый ключ допускается и где сохраняется evidence до rotation.
Backup каждого signer остаётся личным секретом этого ключа: его не складывают в общий архив «на всякий случай». Практики хранения и восстановления seed применяются к каждому участнику отдельно, иначе threshold превращается в декорацию.
Настройку проводят как отдельную церемонию
До первой AccountPermissionUpdate
- Каждый signer создаёт ключ в доверенной среде и передаёт только публичный адрес.
- Адреса сверяются полностью на независимом устройстве; QR-код не заменяет сравнение итоговой строки.
- Один участник собирает draft, другой вслух проверяет network, account, owners, threshold, weights и operations.
- Команда сохраняет human-readable policy и точный machine payload до подписания.
- Из актуального официального источника заново проверяются network fees и особенности permission update.
- Транзакция подписывается действующей конфигурацией, а не теми ключами, которые начнут действовать после update.
| Тест | Ожидаемый результат | Если не получилось |
|---|---|---|
| Одна подпись при threshold 2 | Transaction не готова к broadcast | Проверить, что threshold действительно записан on-chain |
| Две разрешённые подписи | Current weight достигает threshold | Сверить Permission_id, key addresses и подписи |
| Запрещённый operation type | Permission отклоняет операцию | Не переводить рабочий баланс до исправления bitmap |
| Недоступен один signer | Две другие стороны завершают разрешённую операцию | Пересмотреть реальную отказоустойчивость |
| Rotation тестового ключа | Новый on-chain state совпадает с policy | Остановить запуск и восстановить управление |
- Тест
- Одна подпись при threshold 2
- Ожидаемый результат
- Transaction не готова к broadcast
- Если не получилось
- Проверить, что threshold действительно записан on-chain
- Тест
- Две разрешённые подписи
- Ожидаемый результат
- Current weight достигает threshold
- Если не получилось
- Сверить Permission_id, key addresses и подписи
- Тест
- Запрещённый operation type
- Ожидаемый результат
- Permission отклоняет операцию
- Если не получилось
- Не переводить рабочий баланс до исправления bitmap
- Тест
- Недоступен один signer
- Ожидаемый результат
- Две другие стороны завершают разрешённую операцию
- Если не получилось
- Пересмотреть реальную отказоустойчивость
- Тест
- Rotation тестового ключа
- Ожидаемый результат
- Новый on-chain state совпадает с policy
- Если не получилось
- Остановить запуск и восстановить управление
Каждый подписант проверяет транзакцию, а не чужое согласие
В TRON transaction создают с нужным Permission_id. Первый участник подписывает тот же payload и передаёт его следующему; последний собирает достаточный weight и broadcast. Метод getSignWeight показывает required threshold, approved addresses и current weight. Но техническая готовность не заменяет проверку смысла операции каждым человеком.
| Поле | Источник для сравнения | Стоп-сигнал |
|---|---|---|
| Network и account | Корпоративный реестр кошельков | Неизвестная сеть или похожий account |
| Permission_id | Утверждённая permission policy | Owner вместо рабочего Active |
| Token contract | Официальный issuer registry | Только тикер и логотип |
| Recipient | Счёт/договор и независимый канал контрагента | Адрес скопирован из истории или чата посредника |
| Amount и deadline | Одобренная заявка | Другая сумма, срочность или истёкший контекст |
| Current weight | Node API для неизменённого payload | Подписи относятся к другой версии transaction |
- Поле
- Network и account
- Источник для сравнения
- Корпоративный реестр кошельков
- Стоп-сигнал
- Неизвестная сеть или похожий account
- Поле
- Permission_id
- Источник для сравнения
- Утверждённая permission policy
- Стоп-сигнал
- Owner вместо рабочего Active
- Поле
- Token contract
- Источник для сравнения
- Официальный issuer registry
- Стоп-сигнал
- Только тикер и логотип
- Поле
- Recipient
- Источник для сравнения
- Счёт/договор и независимый канал контрагента
- Стоп-сигнал
- Адрес скопирован из истории или чата посредника
- Поле
- Amount и deadline
- Источник для сравнения
- Одобренная заявка
- Стоп-сигнал
- Другая сумма, срочность или истёкший контекст
- Поле
- Current weight
- Источник для сравнения
- Node API для неизменённого payload
- Стоп-сигнал
- Подписи относятся к другой версии transaction
Connect, message signature, approve и transaction имеют разные последствия. Перед внедрением совместного кошелька все signers должны одинаково понимать экран подтверждения; иначе второй участник лишь механически повторяет ошибку первого.
Утрата и увольнение — штатные сценарии, если их репетировали
- 1Остановить новые draft transactions
При подозрении на compromise не собирайте подписи поверх старых заявок и не используйте неизвестный signer для срочной замены.
- 2Определить оставшийся действующий weight
Прочитайте confirmed on-chain permission state. Таблица в Notion или старый скриншот не доказывают, какие keys действуют сейчас.
- 3Создать новый независимый ключ
Новый signer генерирует key pair в доверенной среде. Старый secret не импортируют на новое устройство для «проверки».
- 4Подписать rotation оставшимся threshold
Уберите compromised/departed address, добавьте новый, заново проверьте полный Owner/Active state и дождитесь solidification.
- 5Закрыть старые operational каналы
Отзовите доступ к кабинетам, журналам и устройствам отдельно. On-chain rotation не завершает off-chain увольнение автоматически.
Смена сотрудников и смерть владельца требуют не только технического threshold, но и документов, полномочий и понятного доступа преемников к инструкции. Гайд о наследовании помогает отделить передачу секрета от передачи права и процедуры.
Проверяемый результат запуска
- Confirmed on-chain state содержит только утверждённые owners/keys, weights, threshold и рабочие permissions.
- Один signer не может выполнить тестовый платёж при threshold 2, а любые две разрешённые стороны могут.
- Рабочий Active не может вызвать запрещённый тип операции и не подменяется Owner из удобства.
- Каждый участник независимо восстанавливает свой signer и не знает secrets других участников.
- Команда выполнила test rotation, дождалась final state и сохранила txID и новую конфигурацию.
- Журнал связывает заявку, неизменённый payload, signatures и on-chain receipt без хранения seed/private key.
Когда схему нельзя запускать
- Подрядчик просит seed каждого signer, чтобы «собрать мультисиг» на своём компьютере.
- Два или три ключа создаются из одной seed-фразы либо импортируются на одно устройство.
- Permission update подписывают без выгрузки current state и сравнения полного нового payload.
- Рабочая роль получает Owner только потому, что так проще поддержать интерфейс.
- Названия permissions используют как лимиты суммы, хотя on-chain operations этого не обеспечивают.
- Средства переводят до теста отказа одного signer и rotation recovery-key.
- Сервис обещает восстановить доступ при любом числе потерянных ключей через поддержку.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- TRON Developers — account permission management Проверено 10 августа 2026 г.
- TRON Developers — AccountPermissionUpdate Проверено 10 августа 2026 г.
- TRON Developers — multisignature transaction flow Проверено 10 августа 2026 г.
- TRON Developers — GetTransactionSignWeight Проверено 10 августа 2026 г.