docs: RFC-04 Accounts

[testinginprod]

Description

Closes: #XXXX

Rendered: https://github.com/cosmos/cosmos-sdk/blob/tip/accounts-rfc/docs/rfc/rfc-004-accounts.md

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.

I have...

• [ ] included the correct type prefix in the PR title
• [ ] added ! to the type prefix if API or client breaking change
• [ ] targeted the correct branch (see PR Targeting)
• [ ] provided a link to the relevant issue or specification
• [ ] followed the guidelines for building modules
• [ ] included the necessary unit and integration tests
• [ ] added a changelog entry to CHANGELOG.md
• [ ] included comments for documenting Go code
• [ ] updated the relevant documentation or specification
• [ ] reviewed "Files changed" and left comments if necessary
• [ ] confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.

I have...

• [ ] confirmed the correct type prefix in the PR title
• [ ] confirmed ! in the type prefix if API or client breaking change
• [ ] confirmed all author checklist items have been addressed
• [ ] reviewed state machine logic
• [ ] reviewed API design and naming
• [ ] reviewed documentation is accurate
• [ ] reviewed tests and test coverage
• [ ] manually tested (if applicable)

[testinginprod]

I think this coupling of authentication with the accounts abstraction is not needed and these two should be dealt with separately.

They're coupled here to show how the process of creating authenticated accounts would look like. Also the current scope of work for authn which only aims to abstract public keys and not the authentication mechanism as a whole, I think a refactor should be sufficient.

I don't see a scenario where an EOA would receive messages

The RFC highlights an example of an account whose credentials can be recovered by another identity. The recoverer would be sending a message to the account that needs to be recovered and ask for a credential change. I think in general any state change on a account scoped module will require a message to be sent to it.

Now, as I proposed before, I think we should explore extending this to a first class concept within the SDK rather than a dedicated module.

Agreed on moving this to be a first class citizen, I would also say a module would be required to be able to deploy these form of accounts arbitrarily, otherwise every module would need a custom deploy path (message) for creating account scoped modules (EG: bank smart denoms as you have described)

[tac0turtle]

@testinginprod @aaronc were you two able to catch up?

[aaronc]

@testinginprod @aaronc were you two able to catch up?

Not in detail yet but we should

[tac0turtle]

@testinginprod do we need to add any hooks to the base interfaces or are app devs free to do it and dont need anything native