Neutron SCCS
The SCCS is a stack data structure which serves as the sole non-permanent method for communication between the smart contract VMs and the backing blockchain. It is also used for communication between different types or instances of smart contract VMs. This includes for instance calling a WASM smart contract from an x86 smart contract and sending/recieiving data between the two smart contracts. The following can be considered templates of how the SCCS looks in different scenarios when the VM begins execution
Note in all of these the bottom of the template is the first item to be popped off.
Call smart contract from TX
- argument 3
- argument 2
- argument 1
- ...
- function selector
Create smart contract from TX
- smart contract creation argument 2 (such as to set the coin supply of an ERC20 contract)
- smart contract creation argument 1
- ...
- data section 2 (preinitialized read/write data)
- data section 1
- ...
- code section 2 (read-only data)
- code section 1
- ...
- section information (specifies how many code sections and how many data sections are specified)
- VM options (sets various VM execution/storage options)
Execute "bare" smart contract from TX (ie, a smart contract which is not persisted to an address/deltadb)
same as creation, but with a flag that prevents any data from being stored permanently within the contract. Can be used especially for invoking a complex set of contract calls (which can save persistent data).. For instance, if an "atomic" operation needs to be performed where 2 separate smart contracts are called and their state modified in some way, but you want for nothing to be persisted if either smart contract call fails
Call smart contract from another smart contract:
Same as from a TX
etc.
When a smart contract returns and VM terminates
- return data 1
- return data 2
- ...
- error/status information
When a smart contract invokation TX is completed (ie, a smart contract UTXO verification is completed)
- empty
The reasoning and rationale for this type of SCCS usage is to allow for the best amount of flexibility. It allows for the following:
- smart contract bytecode/data can be stored and interpreted in whatever method works best within the VM, while the blockchain format for doing this remains consistent across all VMs
- A flexible ABI interface where certain arguments that aren't needed can be completely ignored by the receiving smart contract. This prevents needing to allocate extra memory or copy data that won't be needed, saving in gas costs.
- Remaining flexible with where ABI data should go in the smart contract. For some contract designs the ABI (or a subset of it) data would go into the temporary stack (ie, local variables) which do not require additional memory allocation, nor worries about garbage collection. For other designs the ABI data could go into a permanent memory area (ie, a global variable) which does require memory allocation and the potential of clean up being required.
- Recognizing that ABI data might be too big to either fit into the contract's design, or to be capable of being processed with the current gas limit. This allows for an early error that wastes less processing power and thus less gas.
- Allows for simpler pass-through style contract calls. ie, if a function selector is a "passthrough" to another contract, the selector would simply be pushed back onto the stack and the external contract called. This leaves the function selector and argument data on the stack and ready for the external contract to handle. This prevents needing to copy data out of the SCCS and waste more processing power and gas.