vm: account abstraction and new tx format

[dshulyak]

At genesis we will launch vm with 3 precompiled templates:

• simple (single-sig) wallet
• multisig wallet
• vesting contract

Precompiles will be implemented as a simple golang modules, while trying to preserve boundaries discussed during design.

Templates

Templates are identified by an address, and will have their own address space.

For genesis we will define 3 constant addresses:

• 0x01 - singlesig wallet
• 0x02 - multisig wallet
• 0x03 - vesting

TODO maybe start fron 0x00, any use case for empty address?

For spawned accounts we will store one of this addresses in the account table.

Template API

Load

Loads stored state or initializes state using arguments from a self spawn transaction.

Parse (ParsePayload)

decodes generic arguments from the concrete payload

• method arguments
• min/max layer
• nonce counter/bitfield
• max gas
• gas price
• max spend ?

some of the fields might not be specified by the transaction, by design it depends on the template. for example max gas is known in advance, since we are using fixed gas estimator. nonce for spawn transaction is 0.

result of the Parse returned to the mempool.

MaxSpend

inputs: selector, method arguments, state

TODO merge it with Parse for now

Verify

transaction validity

input: raw transaction and state

TODO this is really weird that we need to read transaction from the end when we parsed everything before the signature.

TODO can we unmarshal signature into concrete type?

Exec

Apply changes to the account state, by executing one the methods.

Accounts

every account with funds but without attached template is a stub account and needs to be spawned before it can be used.

In the database stub account will have null template field.

VM API

On gossip

Before accepting transaction into the local database it needs to pass validation.

Next sequence of template APIs is executed:

1. Load (use conservative state)
   Probably will be implemented by conservative passing AccountState from conservative cache. Or maybe method will accept callback that will load state from conservative state.
2. Parse
   Optionally after Parse tx can be validated by the conservative state, but with current API it is simpler after Verify.
3. Verify
   After verify tx is saved to the pool, and conservative state may do other things.

If verify fails - transaction is discarded, and peer is blocked (tm).
Otherwise mempool may do anything with transaction.

On apply

1. Load (non-conservative state)
2. Parse
   Most of the transaction will be stored as a blob for sync efficiency, so we will Parse it again.
3. No Verify
   No need to execute signature verification, but need to consume gas.

Verify has access only to immutable state so it is guaranteed to pass.
4. Exec

If tx fails before Exec - it is returned to mempool and may be either discarded or saved for later, this is irrelevant for vm.

If tx fails in Exec - transaction will be applied to the state as failed, account will pay for gas used in validation (Load/Parse/Verify).

Node API

execution result

each transaction that was applied to the state will have execution result. this API will significantly change after SVM introduction.

type ExecutionResult struct {
    Result   uint8 // FAILED or SUCCESS
    Reason   string // message of the failure
    GasSpent uint64 //
    // for spawn
    SpawnedAddress [20]byte 
}

TODO think more what is missing and might be helpful for debugging

api to read precompile state state

each precompile state has some fields that might be useful for smapp, such as:

type Wallet struct {
    Owner PublicKey
}

type MultiSigWallet struct {
    Owners OrderedSet[PublicKey]
    Required uint32
}

API will return byte buffer with whole state serialized using SCALE, in fact it will simply return what is stored in the latest account state.

Subtasks

• core vm changes
• simple wallet
• multisig wallet
• vesting wallet
• execution results and API for them
• API changes to read account state (including SCALE encoded state)