1. Introduction

The VSC network is a next generation smart contract system that will power the next generation of HIVE DAPPs. For a very long period of time, HIVE has completely lacked the ability to create, maintain and operate truly open smart contracts either on the base layer or an equivalent L1. VSC aims to completely change that, by providing a universal, composable, and modular layer for DAPPs to customize, create and reuse smart contracts. HIVE can then become a flourishing ecosystem for growth.

Unlike HIVE, Ethereum has always maintained an active ecosystem for smart contracts through standardization, open smart contracts, and a half-decent smart contract VM itself. Despite the cost prohibitive fees, it’s largely still considered king. The issue of whether HIVE or Ethereum is better, isn’t because of fees. It’s the lack of anything that meets Ethereum 1:1 in functionality. This has kept us from growing, despite, some limited attempts to create a sufficient solution to the problem.

VSC isn’t just theoretical. We have been developing VSC for months, including its concepts, and tested the anchor chain, multisig, P2P, smart contracts, cross-chain swaps, and more! There have already been two testnets created thus far to demonstrate what we built, helping us prove and further reinforce our plan. Now, we are ready to take the next steps toward a massive expansion.

2. The Goal

With the advent of VSC, HIVE can open itself up to the future of DAPPs.

Flagship features:

• Powerful smart contracts
• Ethereum account ownership of HIVE/HBD
• Powering wrapping of BTC to HIVE
• Smart addresses
• Smart contract controlled HIVE accounts
• Offchain accounts (DID standard)
• Scalability
• …And more

2.1. Offchain

We’ve known for a long time the limitations of being 100% on chain. The SPK network was created for this very same reason to incentivize the storage and processing of video content. Regardless of whether it’s mass video data or millions of crypto kitties, the same problem exists. On chain data is limited and precious. For those who need fully immutable data this is critical. HIVE accounts for example absolutely need to be on chain for the purpose of key rotation and important metadata.

However, what happens if you are a new user and simply want to a few dollars worth of HIVE? This presents a problem of getting a HIVE account, either by spending 3 HIVE or billions of RCs and in many cases the balance held is lower than the creation cost itself. What if those funds can be held offchain instead? With native DID support users can hold funds through a standard process for both HIVE/HBD and native VSC tokens deployed in a smart contract. This brings a unique opportunity allowing Ethereum and Web2 users to interact with HIVE

Additionally, by coupling VSC and SPK network offchain indexer, users can post offchain onto Ceramic/SPK & hold/interface with funds via VSC. The complimenting nature of both protocols will unleash the ability for non HIVE users to have a near native experience on HIVE while retaining many of the original principals HIVE was built on. The trajectory of HIVE could be altered dramatically.

2.2. Cross-chain

We have already mentioned VSC being fully offchain, and a side effect automatically supporting 3rd party wallets like metamask. However, there is a lot more to offchain than just that alone. VSC provides the necessary tools to properly handle cross chain links between HIVE and other ecosystems. It also means those links will be decentralized, significantly decreasing the counterparty risk of centralized bridges.

VSC aims to power the next generation of Bitcoin wrapping onto HIVE, with longer-term goals of supporting that same type of wrapping for ETH, LTC, DOGE, and more. Though it is not ideal under most circumstances, majority of this can be done with VSC through HTLC support

3. The Anchor Chain (HIVE)

Contrary to L2s, such as Polygon, which require their own chain to operate, VSC operates a lightweight anchor chain that is mostly dependent on HIVE for sync and distribution. Not just using HIVE as any old place to put data, but also for unique accounts, spam prevention, censorship resistance and more. HIVE natively provides VSC with a lot of crucial functionality and vastly decreasing the development time required to reach where we are at now.

The anchor chain itself is predominantly a chain of records on IPFS. This allows us to put much more data into a single record and allows us to scale offchain in the above point. This provides nodes with an easy way to sync the vast amounts of data that might be on VSC without a dependency on API nodes or RCs to post that initial data. The anchor chain itself is extremely light weight, but the attached transactions can be many hundreds of times the size of the anchor chain itself.

4. Executor Pools

To achieve scalability as we intend with VSC, the execution of smart contracts MUST be broken down into smaller, segregated units to distribute the long term computational and storage costs associated with smart contracts.

Each smart contract or set of smart contracts creates an individual pool. Every single pool has a list of executors that are assigned and become responsible for the smart contract state. Generally, these pools consist of 25-50 individual nodes that will be assigned based on the schedule selected randomly for each epoch. The combination of the number of nodes and randomization of nodes ensures each pool is secure from outside attack. Additionally, all executor nodes have a certain amount of collateral at stake in order for them to participate.

After transaction processing, a majority executor nodes must agree on the pool's state. If there is a disagreement, a set of executors can sign off to activate a fraud request. When a fraud request is created both the attacking and defending parties collateral becomes at stake. In the event one side loses all collateral and held up earnings is liquidated and distributed to the rest of the network.

The party that ultimately decides: the anchor chain validators. The validators will come to a consensus based on the input transactions and smart contracts logic and produce a final fraud proof to indicate the winning side. During this entire process the smart contract state is temporarily frozen across only. However, this does not mean other nodes can process the state in the mean time. Only the main executor pool is affected by the fraud request.

The aforementioned mechanisms of (collateralization, multi executor nodes, and fraud requests) significantly decrease the internal risk of smart contract attack. This ensures the network can scale through these individuals pools without major risk of single point of failure.

4.1. Rewarding

All nodes in the network receive a transaction fee for participating in Anchor record creation or processing transactions. Ensuring fair reward distribution is critical for ensuring the scaling executor system and smart contract across state distribution.

Typically, rewards will be withheld for a period of time to ensure the node will not commit fraud in the meantime; this timeframe lasts up to a month. In contrast, some transactions can be redistributed as rewards within a few hours.

See below for more information on fees.

4.2. The fee

VSC will utilize two separate systems for handling the payment of fees. Both will result in roughly the same outcome, but different UX to the end user. These are:

• Flat one time fee
• HBD staked RCs

Let’s cover the first one: Flat one time fees are fees paid either ahead of time or when a transactions that are direct HBD transfers to the VSC multisig account. This offers some advantages of being low involvement and can only use when necessary. However, it presents UX challenges of requiring a user to prompt repetitively to perform a single operation and can be more expensive to the user. For the short term there will be no fees on VSC, with flat fees being one of the first to be supported.

Now, stake based RCs. This allows user to stake HBD into the VSC’s multisig savings account, which generates approximately 20% interest on the earnings. A large portion of the interest generated will be directly used for paying VSC fees without needing to prompt users to move funds. This will also enable DAPPs to delegate RCs either on demand or long term to offchain users. This allows us to maintain a free feel while directly rewarding operators with liquid HBD for performing network operations.

Being scalable also ensures these fees remain near constant with network growth.

5. Smart contracts

The smart contract VM behind VSC is a specialized JavaScript VM designed to maintain security and deterministic of any smart contract code. By supporting JS, many already existing Web2 developers can easily come over and start programming smart contracts. VSC aims to make smart contracts easy and straight forward to write. Of course we cannot solve all technical problems involved in smart contract development, but we can make it easier and we will actively work on developing the tools necessary to support developers.

6. Beyond

6.1. No token

We firmly believe VSC should have no native token. By going no token, VSC decreases risks on the front of regulatory, price speculation, fair distribution and other nasties associated with launching a token. We also acknowledge that tokens might be necessary for cases of governance or liquidity on VSC native, it is out of the scope of an initial testnet and mainnet launch. In the later stages a token might be revisited. For the time being, no token is planned.

However, what we can provide the community with, is a versatile smart contract interface that will power a realm of new possibilities much more interesting than what powers them.

Our Ask

We need YOU! As the community to support this ambitious project. It’s not an easy feat, not only does it require obtaining funding with you vote, but also hiring talented devs, building and testing one of the most complicated technical feats there is. Your support is what we need to succeed.

Scope (Phase 1)

Network Core Components

• Develop and maintain a full fledged smart contract layer.
• Open and customizable smart contracts
• Full fledged graphql interface
  • Supporting smart contract state
  • Transaction info
  • Node Info
  • Indexed searches
  • Custom models
  • And more
• Anchor Chain

Witness system (aka validators)

• Voted in DPoS style
• Only a single main validator set
• Responsible for the multisig
• Acts as the final arbiter of the network
• Produces blocks, TX validation, helps keep track of global state (anchor chain)
• Very lightweight node operation

Executor pools

Executors pools are responsible for the sharding & maintainership of smart contracts on VSC. Each pool is a separate set of nodes from other executor pools & the main witness system. This does not mean a node will be excluded from operating in multiple pools, rather the goal is to enforce horizontal sharding as the number of nodes on the network increases with usage.

• Joining smart contracts
• Shuffling pools
• Fraud requests / Fraud Proofs

Smart contracts

• Provide DAPPs with a versatile and flexible smart contract
• State
  • Simple key/value store for storing basic contract state. Mimicking LevelDB
  • Immutable log - Primarily useful for creating ownership and token contracts
  • DB indexed storage
• TX input options
  • HIVE account
  • Included block
  • Signed by authority
• Capabilities
  • Scoped functionality for further security improvements
• Output options
  • Onchain interaction - Ability for contracts to directly create on chain transactions. For example creating custom_json, account creation, etc
  • Movement of funds to/from witness multisig
• Smart contract inheritance - Allows smart contracts to inherit properties from standardized smart contracts. Example usecase: token contract with a custom burn function

Standardized smart contracts

The VSC core will develop a list of core smart contracts that guarantee interop between applications. These smart contracts are as follows:

• Ledger Contract
• NFT Contract
• Token Contract
• Account Creation Contract - Autonomous creation of a HIVE account via a smart contract
• Account Ownership Contract - Autonomous ownership of a HIVE account via a smart contract

We will presumably build an assortment of official smart contracts that are not considered globally standard or are not represented above. We will publish & provide the community with more information on official smart contracts created by the core team.

Apps

Aside from building the core VSC software we intend to build several small side apps to help aid the user experience of using VSC.

• Desktop app VSC node with
  • Mini HIVE wallet
  • Mini Bitcoin/LTC/optional ETH wallet
  • VSC full node option
  • VSC light node option
  • Snapshot option instant sync
• Wrapping / swapping app
  • Ability to wrap BTC into HIVE from desktop app
  • Trade wBTC against HBD/HIVE/Other support cryptos
  • Simple but powerful trading interface. Including price/depth charts, trading widget mode, etc.
  • Local key encryption for added security
  • Send / receive wBTC from HIVE users.

Note BTC wrapping will largely fall under the SPK Network scope. However, it should be noted that there will be some lower level cross over between the two.

Phase II Research

• EVM smart contract support
• WASM (Webassembly) smart contract support
• Fraud proofs & security measures to accommodate for smart contract state sharding
• Fully transparent/trustless L1 < — > L2 bridging
• < TBD more future scope items will be finalized at a later date >

Phase II scope is the next step of the VSC project and will be worked on after phase I or during if budget is left available

Team

• @vaultec - Founder
  • The founder of VSC and proven web3 developer. Originally joining Hive in 2018, he has a long history of working with web3 technologies and platforms. Currently building SPK, 3Speak and VSC
• @platinium - Core Contributor
  • Fullstack developer with a strong interest in web3 and blockchain technology. He has been working in his free time on core VSC features such as the accounting system.
• @piyushjha - Frontend Developer
  • Frontend developer intern recently started with the VSC project. He is currently building the bitcoin swap UI.
• We are looking to further expand the team as necessary. We are looking for:
  • Frontend developer
  • Backend core developer
  • Social media manager
• Visit https://vsc.eco/jobs for our application form.

Socials

Website: https://vsc.eco
Twitter: @vsc_eco

NOTE: This is a draft proposal and is still considered in progress. This is subject to major changes over the next 1-2 weeks before final release. Any feedback/comments and concerns would be much appreciated! This is one of the most pivotal moments to starting full fledged development of VSC.