VSC Proposal 1: Goals & Deliverables

Vote for VSC Proposal here!

TL;DR:

• Build out of MVP VSC testnet
  • MVP smart contracts
  • MVP Validator system
  • MVP HIVE multisig capabilities
  • Security in mind
• Build out of Bitcoin wrapping on HIVE
  • Collatoralization
  • Chain relay
  • Node package
  • Redeem-or-slash
  • Security in mind

Greetings all! As many of you know by now, last week we released our very first DHF proposal. After some feedback from various community members and overall discussion within the team, we've decided to write this post to help clarify what the goals of VSC are and deliverables for our first proposal.

Before reading the rest of this post, we strongly recommend reading our DHF Proposal

Firstly, let's clarify what we've already built so far:

• A very barebones proof of concept demonstrating VSC. It's already been available for the last 6 months at https://github.com/vsc-eco/vsc-node for anyone to run and play around with.
• We've released multiple tutorials for setting up a node, setting up a dev environment, writing a basic smart contract, etc.
• We consider the current network as the "devnet" - highly experiment, concept proving ground
• We built one of the first core elements for doing Bitcoin Wrapping - a smart contract for verifying Bitcoin transactions with L1 security. We will be doing a demo in early November

We've discovered a lot of new challenges in the initial experimental phase of VSC and now we are taking the leap towards building out a proper testnet and later production iteration. Our first proposal is aimed at this initial buildout. In the following sections of this post we will go into detail about what that will look like:

Basic VSC testnet

For a VSC testnet, we will deliver an initial version that will provide the main necessities of what a smart contract system should provide, and minimum required HIVE interaction (i.e contracts holding tokens, sending/receiving tokens). For smart contracts themselves, we will provide a basic API for accessing/modifying persistent data, hive interactions as mentioned above, logging functionality, and a development toolkit. We are also looking into doing intercontract calls (i.e a contract triggering another contract), but we are still figuring out the fine details of how those will be implemented. Additionally, these smart contracts will be webassembly based with interop support to regular JavaScript. This has a whole swath of important implications out the scope of this article.

At the core of VSC, Validators will produce "blocks" (aka anchor records), which are record offchain on IPFS and ultimately referenced on HIVE. There will be no concept of Executors during this initial phase. Validators will both produce blocks and validate smart contract transactions instead. For clarification, executors are the node type that handles the highly scalable part of VSC. Due to the fact that we will have little load during initial phases, having executors in place is not necessary. Even without, because VSC operates offchain it still brings a tremendous scaling opportunity to HIVE during the testnet alone. The next phase would bring executors nodes into play & even more potential to scale long term.

During the testnet we aim to provide a stable environment (but still subject to bugs/changes) where the community can start to build on VSC. At the point we aim to keep VSC mostly the same at it's core of operation, we've figured out the data formats, node structures, and other technical elements that DAPP developers rely on. The following 4-5 months of build out of the testnet following the approval of our first proposal will be the battle grounds for all this to occur.

Finally, the testnet will be built with security in mind. This includes a decentralized multisig for holding funds on HIVE, anchor block validation, validators, DPoS voting, etc.
The goal here is to ensure VSC is secure from the get go & deliver core features required for DAPPs to building. In the later phases we will have more emphasis on security practices & network redundancy especially when we roll out sharding & more advanced features such as smart contract controlled accounts on HIVE.

Bitcoin wrapping

Firstly, Bitcoin wrapping is a joint effort between the SPK team and VSC. VSC provides the lower level smart contract functionality, while SPK will be building the smart contract themselves. (For myself personally @vaultec I will be working across both sides). The wrapping technology we are going to be building is based upon the xclaim.io framework, a trusted wrapping system already operating for the last 5+ years on Polkadot/Eth. We encourage everyone reading this post to check out their website.

We will first release a basic demonstration showcasing how the chain relay works & wrapping to a single centralized wrapping provider & posting the associated proof to chain thus completing the wrap. We do not aim for this to be even in the slightest ready for production, however, it will give the users an idea for how it will look in production. Over the following 4 months we will build out Bitcoin wrapping with a price oracle, collateralization, chain relay, and wrapping provider node package. Price oracles provide other smart contracts with reliable data for Bitcoin price, in our case for managing collateral. The chain relay handles proving the transactions on Bitcoin mainnet are correct. The wrapping provider node is the final piece of software operators run to facilitate wrapping between Bitcoin and HIVE. We will also build & test redeem-or-slash logic for keeping node operators honest. All of this is only possible with VSC smart contracts!

Why is this better than swap.btc?

swap.btc has long existed before VSC has even existed. However, it's at the same time it's 100% centralized and subject to attack. In fact, it already has been hacked in the past. While swap.btc has been quite useful to many projects, the counterparty risk of a centralized system cannot simply be ignored.

By making Bitcoin wrapping decentralized and collateralized we can eliminate counterparty risk and prevent future hacks of wrapped assets on HIVE.

---

So far, we've already learned a lot about the current state of the ecosystem and technical challenges ahead of us. While there are significant challenges before us, we are deadset on bringing smart contracts to HIVE with your support. Your vote for our DHF proposal is critical towards enabling us to bring smart contracts to HIVE and bringing us up to date with the rest of the broader ecosystem.

If you have any further questions about the scope of the VSC project please comment down below. We will reward any good comments with upvotes and engagement. Most importantly! Vote for the VSC proposal if you haven't already. We are only 7% away from getting approved! Your support is hugely important in bringing smart contracts to HIVE

Socials

Website: https://vsc.eco

Twitter: @vsc_eco

Hive: https://peakd.com/@vsc.network

Github: https://github.com/vsc-eco

Repo: https://github.com/vsc-eco/vsc-node

Vote on Peakd
Vote on Ecency
Vote on Hivesigner