Gilt0
b78c72cf9c
# Description
This PR removes redundant type definition from test definition config
implementations like
```
#[derive_impl(frame_system::config_preludes::TestDefaultConfig as frame_system::DefaultConfig)]
impl frame_system::Config for Test {
type A = A;
...
}
```
This changes avoid redundancies in the code as the macro `derive_impl`
defines the relevant types. To implement the changes, it was a simple
fact of running tests and making sure that the tests would still run
while the definition would be removed.
Closes #3237
As a note, here is a brief account of things done from the Issue's
description statement
```
alliance migrate alliance, fast-unstake and bags list to use derive-impl #1636
asset-conversion DONE
asset-rate DONE
assets DONE
atomic-swap DONE
aura DONE
authority-discovery DONE
authorship migrate babe and authorship to use derive-impl #1790
babe migrate babe and authorship to use derive-impl #1790
bags-list migrate alliance, fast-unstake and bags list to use derive-impl #1636
balances DONE
beefy NOTHING TO DO --- also noted this error without failing tests Feb 13 13:49:08.941 ERROR runtime::timestamp: `pallet_timestamp::UnixTime::now` is called at genesis, invalid value returned: 0
beefy-mmr NOTHING TO DO
bounties DONE
child-bounties DONE
collective DONE
contracts DONE
conviction-voting DONE
core-fellowship NOTHING TO DO
democracy DONE
election-provider-multi-phase NOTHING TO DO
elections-phragmen DONE
executive NOTHING TO DO
fast-unstake migrate alliance, fast-unstake and bags list to use derive-impl #1636
glutton DONE
grandpa DONE
identity DONE
im-online NOTHING TO DO
indices Refactor indices pallet #1789
insecure-randomness-collective-flip DONE
lottery DONE
membership DONE
merkle-mountain-range NOTHING TO DO
message-queue DONE
multisig add frame_system::DefaultConfig to individual pallet DefaultConfigs substrate#14453
nft-fractionalization DONE
nfts DONE
nicks Refactor pallet-state-trie-migration to fungible::* traits #1801 NOT IN REPO
nis DONE
node-authorization DONE
nomination-pools NOTHING TO DO -- ONLY impl for Runtime
offences DELETED EVERYTHING -- IS THAT CORRECT??
preimage DONE
proxy add frame_system::DefaultConfig to individual pallet DefaultConfigs substrate#14453
ranked-collective NOTHING TO DO
recovery DONE
referenda DONE
remark DONE
root-offences DONE
root-testing NOTHING TO DO
salary NOTHING TO DO
scheduler DONE
scored-pool DONE
session DONE -- substrate/frame/session/benchmarking/src/mock.rs untouched
society NOTHING TO DO
staking DONE
staking-bags-benchmarks NOT IN REPO
state-trie-migration NOTHING TO DO
statement DONE
sudo DONE
system DONE
timestamp DONE
tips DONE
transaction-payment NOTHING TO DO
transaction-storage NOTHING TO DO
treasury DONE
try-runtime NOTHING TO DO -- no specific mention of 'for Test'
uniques DONE
utility DONE
vesting DONE
whitelist DONE
```
---------
Co-authored-by: command-bot <>
Co-authored-by: gupnik <nikhilgupta.iitk@gmail.com>
Recovery Pallet
Overview
The Recovery pallet is an M-of-N social recovery tool for users to gain access to their accounts if the private key or other authentication mechanism is lost. Through this pallet, a user is able to make calls on-behalf-of another account which they have recovered. The recovery process is protected by trusted "friends" whom the original account owner chooses. A threshold (M) out of N friends are needed to give another account access to the recoverable account.
Recovery Configuration
The recovery process for each recoverable account can be configured by the account owner. They are able to choose:
friends- The list of friends that the account owner trusts to protect the recovery process for their account.threshold- The number of friends that need to approve a recovery process for the account to be successfully recovered.delay_period- The minimum number of blocks after the beginning of the recovery process that need to pass before the account can be successfully recovered.
There is a configurable deposit that all users need to pay to create a recovery configuration. This deposit is composed of a base deposit plus a multiplier for the number of friends chosen. This deposit is returned in full when the account owner removes their recovery configuration.
Recovery Life Cycle
The intended life cycle of a successful recovery takes the following steps:
- The account owner calls
create_recoveryto set up a recovery configuration for their account. - At some later time, the account owner loses access to their account and wants to recover it. Likely, they will need to create a new account and fund it with enough balance to support the transaction fees and the deposit for the recovery process.
- Using this new account, they call
initiate_recovery. - Then the account owner would contact their configured friends to vouch for
the recovery attempt. The account owner would provide their old account id
and the new account id, and friends would call
vouch_recoverywith those parameters. - Once a threshold number of friends have vouched for the recovery attempt, the account owner needs to wait until the delay period has passed, starting when they initiated the recovery process.
- Now the account owner is able to call
claim_recovery, which subsequently allows them to callas_recoveredand directly make calls on-behalf-of the lost account. - Using the now recovered account, the account owner can call
close_recoveryon the recovery process they opened, reclaiming the recovery deposit they placed. - Then the account owner should then call
remove_recoveryto remove the recovery configuration on the recovered account and reclaim the recovery configuration deposit they placed. - Using
as_recovered, the account owner is able to call any other pallets to clean up their state and reclaim any reserved or locked funds. They can then transfer all funds from the recovered account to the new account. - When the recovered account becomes reaped (i.e. its free and reserved balance drops to zero), the final recovery link is removed.
Malicious Recovery Attempts
Initializing a the recovery process for a recoverable account is open and permissionless. However, the recovery deposit is an economic deterrent that should disincentivize would-be attackers from trying to maliciously recover accounts.
The recovery deposit can always be claimed by the account which is trying to to be recovered. In the case of a malicious recovery attempt, the account owner who still has access to their account can claim the deposit and essentially punish the malicious user.
Furthermore, the malicious recovery attempt can only be successful if the attacker is also able to get enough friends to vouch for the recovery attempt. In the case where the account owner prevents a malicious recovery process, this pallet makes it near-zero cost to re-configure the recovery settings and remove/replace friends who are acting inappropriately.
Safety Considerations
It is important to note that this is a powerful pallet that can compromise the security of an account if used incorrectly. Some recommended practices for users of this pallet are:
- Configure a significant
delay_periodfor your recovery process: As long as you have access to your recoverable account, you need only check the blockchain once everydelay_periodblocks to ensure that no recovery attempt is successful against your account. Using off-chain notification systems can help with this, but ultimately, setting a largedelay_periodmeans that even the most skilled attacker will need to wait this long before they can access your account. - Use a high threshold of approvals: Setting a value of 1 for the threshold means that any of your friends would be able to recover your account. They would simply need to start a recovery process and approve their own process. Similarly, a threshold of 2 would mean that any 2 friends could work together to gain access to your account. The only way to prevent against these kinds of attacks is to choose a high threshold of approvals and select from a diverse friend group that would not be able to reasonably coordinate with one another.
- Reset your configuration over time: Since the entire deposit of creating a recovery configuration is returned to the user, the only cost of updating your recovery configuration is the transaction fees for the calls. Thus, it is strongly encouraged to regularly update your recovery configuration as your life changes and your relationship with new and existing friends change as well.
Interface
Dispatchable Functions
For General Users
create_recovery- Create a recovery configuration for your account and make it recoverable.initiate_recovery- Start the recovery process for a recoverable account.
For Friends of a Recoverable Account
vouch_recovery- As afriendof a recoverable account, vouch for a recovery attempt on the account.
For a User Who Successfully Recovered an Account
claim_recovery- Claim access to the account that you have successfully completed the recovery process for.as_recovered- Send a transaction as an account that you have recovered. See other functions below.
For the Recoverable Account
close_recovery- Close an active recovery process for your account and reclaim the recovery deposit.remove_recovery- Remove the recovery configuration from the account, making it un-recoverable.
For Super Users
set_recovered- The ROOT origin is able to skip the recovery process and directly allow one account to access another.
License: Apache-2.0