-
Notifications
You must be signed in to change notification settings - Fork 284
Open
Labels
EnhancementNew feature or requestNew feature or request
Milestone
Description
The risk of key loss can be mitigated by using a social-recovery pattern commonly called a guardian scheme. In Iroha, a guardian scheme can be implemented as library triggers. However, it requires finer-grained access control over metadata.
Implementation Overview
This involves two accounts and two triggers:
- Alice: the user who lost their private key
- Guardian: a trusted friend (ideally a multisig account) pre-authorized to schedule Alice's account migration
- Reception desk: a data trigger that accepts account-migration requests
- Migrator: a time trigger that executes the account migration
- Alice grants the Guardian write permission on the Reception desk's metadata entry
(Alice, *)
. - Alice loses her private key.
- Off-chain, Alice informs the Guardian of her new public key
NewAlice
. - The Guardian writes
(Alice, NewAlice)
into the Reception desk metadata. - The Reception desk detects this and writes
(Alice, NewAlice, migrate_at)
for the Migrator—wheremigrate_at
is a future timestamp. - A notification about the scheduled account migration is sent to Alice.
- If Alice did not intend this (e.g. malicious Guardian action), she can cancel the reservation by deleting the corresponding metadata entry.
- When the Migrator's periodic check runs, if the metadata entry is still present and valid, Alice's identity in the world state is replaced with
NewAlice
. - Alice can then access her previous assets under the new key
NewAlice
.
Addendum
Considering that triggers inherit authorities (#5475), the intermediary Reception Desk is redundant. The key point is that the delay before executing the migration should be a sufficiently long period approved by Alice, and must not be configurable by the guardians.
Metadata
Metadata
Assignees
Labels
EnhancementNew feature or requestNew feature or request