[FEATURE] VM-less templating

[andrewnguyen22]

Motivation

The VM-less implementation of Canopy's smart contract ideal enables external binaries to attach to the base Canopy software and 'plugin' to the FSM as an extension.

Describe the feature you'd like

• Chain.json which configures the nested chain with basic configurations. This configuration should modify the behavior of the Canopy software and (for the most part) shouldn't be changed.

{
  "chainId": 1,
  "name": "canopy",
  "symbol": "cnpy",
  "website": "https://canopynetwork.org",
  "logoURI": "https://",
  "explorerLogoURI": "https://",
  "walletLogoURI": "https://",
  "color1Hex": "#2c9b5a",
  "color2Hex": "#16502e",
  "description": "Canopy is a recursive, progressive-sovereignty framework for blockchains",
  "consensusPreset": 1
}

• Execute Genesis, BeginBlock, DeliverTx, EndBlock from the FSM to the binary using unix socket files
• Expose access to fsm store operations via unix socket file
• Expose fsm error function for the binary to fsm error via unix socket file

- Genesis
- BeginBlock
- DeliverTx
- EndBlock

Example

MainFSM: "Genesis" -> PluginExtension
PluginExtension: "Set(Key, Value)" -> MainFSM
PluginExtension: "Get(Key, Value)" -> MainFSM
PluginExtension: "Delete(Key, Value)" -> MainFSM
PluginExtension: "GenesisDone" -> MainFSM

syntax = "proto3";

package plugin;

message PluginRequest {
  oneof payload {
    GenesisRequest genesis = 1;
    BeginBlockRequest begin_block = 2;
    DeliverTxRequest deliver_tx = 3;
    EndBlockRequest end_block = 4;
    SetRequest set = 5;
    GetRequest get = 6;
    IterRequest iter = 7;
    DeleteRequest delete = 8;
  }
}

message PluginResponse {
  oneof payload {
    GenesisResponse genesis = 1;
    BeginBlockResponse begin_block = 2;
    DeliverTxResponse deliver_tx = 3;
    EndBlockResponse end_block = 4;
    SetResponse set = 5;
    GetResponse get = 6;
    IterResponse iter = 7;
    DeleteResponse delete = 8;
    ErrorResponse error = 99;
  }
}

• Genericize block explorer to allow custom transaction types without any panic or error
• Create explorer manifest extension that defines calls that may be made to the underlying plugin through the json rpc at an endpoint called plugin_call - that relays the RPC call to the plugin and back to the explorer and web wallet. This should define some generic state adapter

{
  "method": "fsm_getUserInfo",
  "params": { "address": "0xabc..." }
}

• Similar to the explorer, create wallet manifest extension that defines transactions that may be executed to the underlying blockchain.

Possible implementation

• Is not designed to modify consensus operations

• Is not designed to modify P2P operations

• Is not designed to modify persistence operations

• Does not handle signature validation

• Does not handle fee structure for existing transactions (but can handle fee structure for new tx types if desired)

• Can extend the FSM with additional features and items in the state store

• Can interact with accounts

• Can interact with validators

• Can interact with governance features

• Can interact with the order book for token swaps

Testing

• Implement a basic NFT template in golang in order to E2E test feature completeness.

Notes

• Don't make it too generic, optimize for UX over flexibility

Consensus Preset:
1 (20 second blocks that is good for 100-1000 validators with up to 2.5K TPS)
2 (10 second blocks that is good for 100-1000 validators with up to 2.5K TPS)
3 (5 second blocks that is good for 2-50 validators with up to 2.5K TPS)
4 (20 second blocks that is good for 2-50 validators with up to 10K TPS)
5 (10 second blocks that is good for 2-50 validators with up to 10K TPS)
6 (20 second blocks that is good for 1000+ validators with up to 1K TPS)
7 (10 second blocks that is good for 1000+ validators with up to 1K TPS)

Required Tags

• Priority: High
• Module: Multi-Module, FSM (Finite State Machine)