Implement support for account abstraction

[EdgeDLT]

This issue is intended to replace and continue discussions that started in https://github.com/neo-project/neo/issues/2907.

Summary or problem description

Neo lacks flexibility in regards to how users may interact with the network. We make too many assumptions about usability and it leaves massive barriers to adoption that are not feasible to overcome at the application layer. Examples include the fact that we require regular users to manage private keys or to initially load an account with GAS before they can do anything with the network.

We can build better applications and experiences by abstracting these things away from the end user. Depending on the approach taken, possible benefits include:

• GAS-free transactions (pay blockchain fees with any token)
• Support alternative verification approaches (e.g. quantum resistant signing schemes and keyless validation)
• Secure arbitrary transaction sponsorship #2577
• Solve the node incentivization problem through proposer-builder separation https://github.com/neo-project/neo/issues/2862#issuecomment-1567458367
• Multi-sig aggregation https://github.com/neo-project/neo/issues/1573
• Transaction conflict resolution https://github.com/neo-project/neo/issues/2907

Do you have any solution you want to propose?

Taking inspiration from ERC-4337, Neo should implement support for user operations. A user operation documents a user's intent for a transaction and grants increased flexibility for verification.

User operations are shared with the network through a separate channel than conventional transactions. Special operators, "bundlers", presumably an enhancement to P2P Notary, bundle these operations into transactions targeting a new native contract (Notary extension?), which unbundles and executes them. By sending the bundle transactions, bundlers pay any associated system/network fees, and are expected to be reimbursed in the process by the user operation. This reimbursement can be in any token desired by the bundler. Presumably a non-altruistic bundler will refuse any operations that do not meet its fee or validity checks.

User operations should allow the use of a new interop, along the lines of CheckData https://github.com/neo-project/neo/issues/2866. This interop should allow arbitrary verification logic to be validated, beyond what is possible with ECDSA alone. This, as an example use case, allows us to support end users that don't need to store private key material.

This facilitates a new type of Smart Account capable of onboarding any user regardless of their background. It also opens the door to several other benefits, such as Social Recovery services and transfer quotas, offering protection in the event that a user loses access or otherwise compromises it.

Optionally, we can explore the ERC-4337 concept of Paymasters as a method for doing practical arbitrary transaction sponsorship. A dApp should be able to maintain a GAS balance that any user operation can spend providing the operation abides by the requirements defined by the dApp.

Neo Version

• Neo 3

Where in the software does this update applies to?

Probably small changes to most of it, some more significant ones in parts.

• Compiler
• Plugins
• Ledger
• Network Policy
• P2P (TCP)
• RPC (HTTP)
• SDK
• VM