[SNatives] SNative domination

We have discussed SNative world domination, that is:

Exposing all burrow transaction functionality via a singular, unified SNative interfaces (names, permissions, proposal), and for future things like #1083
Making such SNatives callable directly (i.e. not just from deployed contracts)
Possibly: making SNatives callable from little anonymous functions (EVM/WASM code running in a lexical scope that calls multiple snatives and can bind and operate onreturn values

We have the following plans initially:

1. Tidy up SNative descriptions

We should be able to use strongly typed function signatures for our snatives rather than the current func(stateWriter Interface, caller crypto.Address, gas *uint64, logger *logging.Logger, v interface{}) (interface{}, error

If we let the description take a function as an interface{} then we can reflect over that, wire up any state-accessing functions and map incoming arguments to the rest.

We should provide access to any of the types used by the existing execution.Context types. Perhaps we should assume the form for SNatives:

func(context Context, arg Payload) (Result, error)

Where Context contains access to state caches etc, Payload are the function arguments (similar to current Tx payloads) and Results are a new counterpart to Payloads containing the return values.

We can extract more information from structs over reflection and having them defined should also allow us to generate a nice calling interface if we want to call them from outside the VM.

Suggest we change SNativeFunctionDescription to something like:

type SNativeFunctionDescription struct {
    // Comment describing function's purpose, parameters, and return value
    Comment string
    // Function name (used to form signature)
    Name string
    // Permissions required to call function
    PermFlag permission.PermFlag
    // Native function to which calls will be dispatched when a containing
    F interface{}

    // The values below are memoised at definition time (at startup)
    // Function arguments
    arguments reflect.Type
    // Function return values
    returns reflect.Type
    // The memoised abi
    abi abi.FunctionSpec
}

2. Implement NameContext as SNative

If we move the implementation of NameContext to an SNative in the new structure we will then get access to NameReg from within contracts. We can preserve the existing transaction for the time being, but just call the SNative function implementation.

In doing this we will probably learn something about how to proceed more generally as below and it will be useful to have NameReg accessible from contracts (e.g. doug can register himself...)

3. Move all contexts to SNatives

Rinse and repeat the above and decide what to do about existing transactions. I think we may be best to standardise on a single transaction wrapper a bit like TxEnvelopeParam of rpctransact's BroadcastTxSync and just pass that through to the executor payload.Any can be used for anything other than a CallTx (poss rename CallPayload) we should do a direct 'no vm' call of an snative.

hyperledger-archives / burrow