I believe this conversation extremely interesting. The actor-asset is for sure the base of any next generation blockchain.
Regarding the asset storage, i am not sure this is the most urgent issue to fix.
ERC20 are working pretty well on the way to save states of an ERC20. However, the missing part of the ERC20 is how it has been designed. The basic Transfer function of a ERC20 check directly the address signature where ideally we would need to delegate to the actor authorization. This way, the ERC20 Token will not need to check if the signature is correct but the actor will check if the signature is correct. This way, the transfer of asset goes from one actor to another actor. Crypto address are not first class citizen, Actors are.
In the current ERC20 Token, i cannot easily change my public signature without moving my assets to a new address which is huge pain for mass-adoption. Traditional end-user not familiar to crypto already have the opportunity to increase the security of their Gmail account without the need to “re-create an account”. Ideally being able to to deploy a smart contract to the my current public address would be very useful (kind of a new opcode CREATE3) because it gives a seamless experience for end-user to upgrade their actor account security. At the beginning my public address is my actor ID then later on, it is not necessarily anymore the case because i always keep my Actor ID however I can still switch to another type of Curve or multi-sig to transfer assets.
I consider there is 2 main types of condition to transfer an asset:
- internal condition delegated and checked by the actor, does my signature (1 or several) matches the condition to move my asset
- external condition from the issuer. does this asset can be moved from Actor A to Actor B (ex: checked how TPL works https://tplprotocol.org/)
In my opinion, before improving the asset storage, the actor model needs to be well defined.
To get mass adoption from the end-user, we need to make sure end-user can create an actor account easily, defining easily how many and which public key/private key will be used to allow transfer and potentially optiinally how to recover their private key from a social recovery schema (https://www.youtube.com/watch?v=FAC9uqHJ4H0)
I hope my comment helps. I suggest we co-write an article regarding this topic?
I believe this topic is a major to get mass adoption solved.
Kind regards,
Antoine