Thanks for highlighting this @bkchr - I fundamentally believe that sooner or later the vast majority of users will interact primarily through pure accounts. The idea that you won’t ever be able to change a private key of an account will go out of fashion I’m convinced and we should design Polkadot to support that from the beginning.
There’s one more crazy idea I’ve been about that I wanted to throw out there: allowing an account from another parachain to transact via XCM directly. This still means the third party parachain is trusted by the owner of this account but at least there is no threat of the third party parachain to mess with anything that isn’t technically controlled by this specific third party parachain.
It could be as simple as a way to allow a parachain to take control of an account it specifies that is prefixed with the multi-location of the parachain:
TransactAsAccount(MultiAccount account, ExtrinsicPayload payload)
We could derive a local account id from the hash of mutliaccount:
// Acala sends this XCM message
TransactAsAccount("/0xFADED82....", "Balances.Transfer(1000 ACA)")
internally the chain would do:
- Prefix the source parachain to the account:
"/polkadot/acala/+account" - Hash this account
- Execute the extrinsic with the derived address as the origin
I think this offers a lot of benefits for allowing users to do stuff across parachains without the hard to avoid messiness of trying to sync account abstraction across parachains.