TL;DR:
- Basic VSC testnet over the next 4 months w/MVP scope
- Researh

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 VSC does and what we intend to do as part of our first 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 VSC.
- 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 "dev**net**" or "demo**net**"
- We built one of the 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 learned a lot so far in building this barebones model of VSC, and we are now taking the next steps to build out VSC to a basic testnet and later production iteration. Our first proposal is aimed to accomplish the following.

#### 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 how those will be implemented. Additionally, these smart contracts will be webassembly based with interop support with 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 records that are 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. For clarification, executors are the node type that handles the scaling part of VSC. Due to the fact that we will have little load during initial phases, having this system in place is not necessary. Even then, because VSC operates offchain it still brings tremendous scaling opportunity to HIVE during the testnet alone. The next phase would bring executors nodes into play & even more scaling opportunities.

During the testnet we aim to provide a stable environment (but still subject to bugs) 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 figure out the 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).

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. Coupling this technology together with VSC smart contracts allows all of this technology to work seamlessly together.

#### 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](https://peakd.com/hive-engine/@aggroed/good-news-bad-news-good-news-a-hack-p2p-and-a-white-gray-hat). 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.

<hr>

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 good comments with upvotes. Most importantly! **Vote for the VSC proposal if you haven't already. We are only 9% away from getting approved!**

[Vote on Peakd](https://peakd.com/proposals/279)
[Vote on Ecency](https://ecency.com/proposals/279)
[Vote on Hivesigner](https://hivesigner.com/sign/update_proposal_votes?proposal_ids=%5B%22279%22%5D&approve=true)