Description

Currently, MetaMask faces tight coupling between its UI and the keyring-controller. The UI heavily relies on the keyring-controller's state while also amalgamating information from various sources, such as preferences and balances.

However, this approach presents some challenges. The keyring-controller must be aware of the UI's limitations, like the need for instant account list provision to avoid lag. Moreover, it takes on the responsibility of adding metadata to accounts, such as the associated keyring type, required for displaying account details.

To address these issues, the introduction of the accounts-controller comes into play as a new abstraction layer between the UI and the keyring-controller. This separation of responsibilities allows the keyring-controller to focus on two main tasks:

• Routing requests to the appropriate keyring.
• Persisting the state of the keyrings.

This PR introduces @metamask/accounts-controller and InternalAccounts to the background script. It is one of several PRs that will be switching the usage of identities to internal accounts.

Changes:

1. PermissionsController

• getCaveatSpecifications and getPermissionSpecifications uses getInternalAccounts instead of getIdentities
• captureKeyringTypesWithMissingIdentities uses the InternalAccount model instead of an identity

2. IncomingTransactionHelper

• getAccount now returns an InternalAccount, and uses the AccountsController's getSelectedAccount

3. AlertController

• Removed the preferenceStore
• Added the accountsController and controllerMessenger
• adds the subscription of selectedAccountChange from the AccountsController

4. DetectTokenController

• removes subscription of selectedAddress from the PreferencesController
• adds the subscription of selectedAccountChange from the AccountsController

5. AccountTracker

• removes subscription of selectedAddress from the PreferencesController
• adds the subscription of selectedAccountChange from the AccountsController

6. Backup

• adds backup of AccountsController

7. MetamaskController

• modifies TokensController's onPreferencesStateChange to subscribe to selectedAccountChange from the AccountsController
• modifies the KeyringController constructor arguments
• modifies metamaskMiddleware's getSelectedAddress to getSelectedAccount
• modifies setupControllerEventSubscriptions to subscribe to selectedAccountChange from the accounts controller and removes subscribing to selectedAddress from the PreferencesController
• modifies setAccountLabel to use setAccountName from the AccountsController
• createNewVaultAndKeychain - awaits for updateAccounts and uses setSelectedAccount from the AccountsController

Additions:

1. 105 migration file, this migration creates an InternalAccount for every identity and selectedAddress to selectedAccount on the AccountsController
2. Adds AccountsController to the store and memStore
3. Adds setSelectedInternalAccount and setAccountName to the api
4. Changes selectFirstIdentity to selectFirstAccount
5. Unlock hardware wallet to return internal accounts
6. resetAccount to use getSelectedAccount
7. Adds a new subscription, selectedAccountChange to change accounts in setupControllerEventSubscription

Related issues

Resolves https://github.com/MetaMask/accounts-planning/issues/133

Manual testing steps

1. Use a hardware wallet to test all the flows

Screenshots/Recordings

No UI changes

Pre-merge author checklist

• I’ve followed MetaMask Coding Standards.
• I've clearly explained:
  • What problem this PR is solving.
  • How this problem was solved.
  • How reviewers can test my changes.
• I’ve indicated what issue this PR is linked to: Fixes #???
• I’ve included tests if applicable.
• I’ve documented any added code.
• I’ve applied the right labels on the PR (see labeling guidelines).
• I’ve properly set the pull request status:
  • In case it's not yet "ready for review", I've set it to "draft".
  • In case it's "ready for review", I've changed it from "draft" to "non-draft".

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.