---
title: VSC master doc
---

# VSC Master Doc

### Overview

VSC is a next generation smart contract platform built on top of high. Leveraging IPFS as a L2 for smart contract state and transactions. The overall goal of the project is to provide the HIVE community with an incredibly flexible smart contract engine not unlike hive-engine, while being hyper scalable and nearly free. The long term goal goes well beyond just NFTs, community tokens, etc, but to allow many new use cases that were previously not possible. VSC nodes will be lightweight, and easy to operate while providing a rich interface into the smart contract land. Aside from having a list of prebuilt standardized contracts, anyone can easily write their own smart contract and deploy it to the network (paying the fees associated of course)

It will employ a combination of highly scalable data structures such as DAGs, merkle trees, and CRDTs to create a highly scalable fabric that smart contracts can utilize.

VSC has two main consensus elements:
- Main validator set - runs the main anchor chain hooked directly into the HIVE blockchain
- Executor set - responsible for the proper execution and maintainership of smart contracts. In other words this means there is an individual node runner pool per smart contract or group of smart contracts. Meaning as the number of nodes grow in the network so does the total TPS and number of smart contracts that can be supported.

### Layer two

The majority of operations on VSC will occur using offchain accounts to take advantage of very low fees and skip account creation. However, executing a smart contract will still be possible directly on the HIVE blockchain, but the ultimate state of that operation will be stored offchain.

### Economics

The economics of the entire system aims to stay as simple as reasonably possible while satifying the following goals of the project:

- Fund a treasury account to continue develop into the future
- Provide nearly free transactions under $0.02/tx for most cases
- Scale network infrastructure horizontally
- Distribute rewards for validators
- Distribute rewards for executors
- Create a small cushion of locked up witheld from validators/executors until proven trustworthy by other nodes

Thus the following is being proposed

- Network maintainance (50%)
- Dev fund (50%)

Out of the network maintainance:

- Executors (80%)
- Validators (10%) - will adjust according to network volume. TODO: determine max cap to validators
- Reserve (10%) - witheld fees, longer term saved fees.

Over time the dev fund % will be lowered as network volume increases. All of the economics are defined by the validator set of nodes. The validator pool is responsible for managing all funds and handling investment of funds such as HBD staking.

Research will need to be done on the security/viability of using a multisig on HIVE as the primary treasury account and holding system for the network. It should be adequate for the short term, but longer term when money is involved could be a different story.

### Consensus

The two primary consensus mechanisms are the validators and executors.

Starting with validators. They are responsible for the operation of the main anchor chain, hive multisig, treasury account, and distributing rewards for node operation. These nodes play a critical role in the operation of the network. Only one group of validators exist per network. To accomplish this we will leverage proof of burn or delegated proof of burn or similar. There will be a minimum primary set of approximately 10-20 validators, with an additional 30-50 to act as a fail over. At a very minimum 5 validators will be responsible for the hive multisig. Ideally, more validators would be part of the multisig assuming it's practical.

As for executors. These nodes are responsible for the actual execution and datastorage of smart contracts. There are multiple sets of executors. A general rule is 1 group per smart contract. What defines a group is simply a group of nodes "joining" a smart contract and all requiring participation from other nodes to move the smart contract state forward. Joining a smart contract involves staking a small amount of token and passing a small wait period. Once a node has joined a smart contract it can participately in the minutely execution rounds created by the validator nodes. 3/5 consensus among the executor pool is required to execute a smart contract.

### Smart Contract interface

The smart contract is comprised of 5 parts

Mutability - using an IPFS merkle tree to provide smart contracts with a flexible highly scalable data storage mechanism

Indexing - using an indexed database we can provide smart contracts with high performance web2 like operations involving querying/editing large samples of data.

VM - a customized javascript VM executes user defined code in a deterministic/decentralized manner. Certain functionalities in JS are purposefully disabled to ensure contract code can execute deterministically and without negatively affecting the network.

Graphql - a flexible graphql interface for smart contracts to define a structure, allowing any node on the network to query smart contract state through a standardized API.

Contract external interface - smart contracts can define an interface of datatypes and capabilities. For example operations involving money will require a special flag set by the contract to allow for such operations to take place.

A few more examples:
- Inheritently a common standard such as asset ownership
- Require active key signature
- Indexed operation
- Require randomness function