Introducing Blocknet Comet (Mandatory Update)

NOTE: This is a MANDATORY update for everyone, regardless if you’re a holder, staker, service provider, or Service Node operator.

We are delighted to announce the release of Blocknet Comet, the biggest Blocknet release to date with over 2,120 files changed with 391k additions! Before we jump into the new tech, let’s quickly go over what Blocknet is and aims to achieve for anybody new to the project.

Blocknet is a blockchain interoperability protocol that enables communication, interaction, and exchange between different public and private blockchains, as well as on-chain access to off-chain data, APIs, and services via oracles. We are an open sourced, self-funded, and self-governed project with dedicated contributors around the world.

Our service-based blockchain is comprised of 3 main components: XBridge, XRouter, and XCloud.

• XBridge is a true decentralized exchange protocol that allows users to conduct peer-to-peer trading of native assets directly from their own wallets.
• XRouter is a decentralized full node SPV network that enables use of on-chain data from any public or private blockchain without requiring users to download the full blockchain.
• XCloud is a decentralized oracle network that enables on-chain use of off-chain data, APIs, and services.

Blocknet’s goal is building an open and collaborative blockchain ecosystem. This is accomplished by providing developers with the aforementioned suite of decentralized and openly governed protocols. All these protocols are currently available in beta for use on mainnet.

Comet includes many changes that will help us continue to achieve these goals, including a move to on-chain governance, on-chain Service Nodes, a single tier block reward and the migration from an older PIVX codebase to the Bitcoin v18 codebase.

There’s a lot of information to unpack so let’s jump right into it!

Blocknet Core

At the heart of the protocol is the base chain code. It is vitally important as it’s the foundation for the entire network and needs to be solid. Prior to this release, Blocknet’s base chain was a fork of PIVX v2, which caused a lot of issues from network instability and inefficiencies. For this release, we migrated all base chain code to Bitcoin’s v18 codebase. This allows us to immediately benefit from all the security, scalability, and network efficiencies that Bitcoin has to offer and allow us to quickly and easily pull in future upstream updates.

The migration to the Bitcoin base chain code has provided some additional benefits as well. Our wallet now also supports a REST API interface and auto-complete console commands. These additions greatly improve the experience of interacting with the wallet.

There are some very important key changes that users need to be aware of:

• Blocknet’s default data directory has been renamed from BlocknetDX/ to Blocknet/ on Windows and MacOS and from .blocknetdx/ to .blocknet/ on Linux.
• Blocknet’s wallet configuration file has been renamed from blocknetdx.conf to blocknet.conf.
• When interacting with the wallet via CLI you will need to use blocknet-cli instead of blocknetdx-cli.
• Support for the getinfo command has been dropped and replaced with getblockchaininfo.
• Current Service Nodes will need to be set up again. You can view the instructions for this procedure here and the new guide for voting on proposals here.

Below is a detailed breakdown of all additional changes.

Qt Wallet

The Qt wallet has been updated to combine the redesigned and classic wallet interface into a single application instead of needing to download a separate release for each. This makes it much easier for the user to switch back and forth between each GUI as well as make it easier to publish releases as only a single set of builds is required. To switch between each GUI, a classic= setting has been added to the blocknet.conf wallet configuration file. Setting classic=1 will load the wallet with the classic GUI, which has been updated to use the Bitcoin v18 interface, and setting classic=0 will load the wallet with the redesigned GUI. By default the wallet will load the redesigned GUI.

Staking & Network Improvements

While the migration to Bitcoin’s v18 codebase brings with it security and network stability, the majority of the improvements will be coming from the decision to move to a single tier block reward system and moving the Service Node list to being on-chain (more on that in the Service Node section below).

As it currently stands with our double tier block reward system, the staker earns 30% of the block reward (0.3 BLOCK) and the Service Nodes earn 70% of the block reward (0.7 BLOCK). There are three primary issues with this setup.

The first issue is that for this system to function it relies on a Service Nodes list as part of the consensus protocol. This means the blockchain requires a non-blockchain based side chain to operate, opening the doors for significant instability because nobody can agree on the list due to it being off-chain. When nobody can agree on the list it results in forks because the list is part of the consensus model which results in nodes banning each other if they can’t agree.

The second issue is that in this old design Service Nodes weren’t able to stake. Because the collateral for a Service Node is 5k BLOCK and we have over 400 nodes, this greatly reduces the security of the network.

The third issue is unstable protocol service support. To understand this issue, let’s take a closer look at the dynamics of how the reward system operates. Staking on Blocknet’s blockchain is probabilistic, so when there’s less stakers you have a higher chance of winning a stake and when there’s more stakers you have a lesser chance of winning a stake. In other words, less stakers yield a higher ROI and more stakers yield a lower ROI. This same concept also applies to Service Node’s block reward payouts. Less Service Nodes yield a higher ROI and more Service Nodes yield a lower ROI. Because Service Nodes can’t stake, the difference in block reward ROI for stakers and Service Nodes incentivizes Service Node operators to switch between staking to chase a higher ROI. This causes fluctuations in Service Node support on the network as the services they’re supporting become unavailable as they move to staking.

As a solution to these issues, the Comet release replaces the current double tier reward system with a single tier block reward system in which everyone can stake, even existing Service Nodes. This results in a less fragile network by removing the mechanism that pays rewards to Service Nodes, it increases the security of the blockchain by enabling Service Nodes to stake which increases the amount of stakers on the network by about 180%, and it stabilizes the support for services by removing the mutual exclusivity of staking and operating a Service Node.

For the ROI of stakers and Service Nodes between the two systems, it should be barely affected over time since the constant rebalancing of BLOCK from Service Nodes to staking naturally brings the ROI of the Service Nodes and stakers to an equilibrium. The ROI at equilibrium in the double tier block reward system we have now is equal to the ROI of the single tier block reward system (read more).

In addition to the changes above, we’ve also updated the staking protocol to pay out the network’s transaction fees to the staker. In the old design the transaction fees were getting burnt. By making this change to pay the fees to the staker, we are further increasing the security of the network by incentivizing them to act benevolently.

Governance

While a small number of other projects have already implemented staking on Bitcoin, nobody has added on-chain governance. Blocknet is the first to achieve this and continues to lead the charge in Blockchain 3.0 projects.

When forking PIVX for our old codebase, it suited our short term needs for a governance system and masternode model. However, as time went on we noticed quite a few shortcomings and our needs quickly outgrew their design.

As stated previously, there were many issues with the Service Node list and it didn’t stop at instability. The old design introduced A LOT of bandwidth on the network to maintain the state of that sidechain, it restricted governance participation to those that operate an active Service Node, and it wasn’t on-chain so there wasn’t much transparency to it.

We decided to take advantage of this and rebuild the governance system from the ground up to be on-chain and completely transparent. The old system didn’t have much in terms of unit testing either, so we also took the time to write over 3000 lines of code testing for the new governance protocol to make sure it was well tested.

After moving the governance system on-chain, there has been a HUGE improvement in efficiency with network data transfers decreasing by 90% with the Comet release! The dramatically less bandwidth requirements allows more people to participate in the network by being able to run the wallet with fewer resources, which produces a more stable network.

The separation of the governance system and Service Nodes also opens voting to the wider community, allowing a larger decentralized democracy. You will still need 5000 BLOCK to vote, but you will no longer need the knowledge or hardware to setup a Service Node. You can vote directly from the wallet. You can read more about the requirements for voting here: Voting Guide

When voting, any funds spent will result in those votes being invalidated. It’s necessary to recast votes whenever funds are spent. However, you will still be able to stake without any issues. This is made possible by a clever feature that will automatically re-cast your votes within the staking block.

Speaking of sporks, we now have real miner-driven (staker-driven) consensus on sporks. We have adopted Bitcoin Core’s BIP9 spork system. This means that instead of initiating a spork through a developer key, it’ll now require the stakers on the network to signal approval for these changes.

Upcoming BIP9 sporks on the Blocknet network include: Network fees paid to stakers instead of being burned, SegWit support, and staking to p2pkh instead of p2pk. Stakers will have to signal support for all of these features on or after March 15th, 2020 in order for them to be adopted. Once 95% of stakers signal support for a BIP9 spork, it will be adopted into the protocol.

Prior to Comet, as Service Nodes go inactive, their trace in governance effectively disappears. When you went offline, all your votes on proposals would be removed, even proposals that have passed and are closed. By moving everything on-chain there’s now 100% transparency into how users are interacting with the system as all votes are saved to the blockchain. Going offline will no longer impact votes.

There were various other changes made to improve the governance system. With Comet, there is now a proposal submission cutoff 2880 block prior to the Superblock (approximately 2 days). This is to prevent proposal sniping and other malicious activity where a proposal is submitted last minute and voted on with enough votes to meet the passing criteria without giving others a chance to review and vote on it. The cutoff for voting on proposals has also changed from 2880 blocks prior to the Superblock to 60 blocks prior. If someone submitted a proposal last minute, the community will have nearly 2 full days to review it and cast their votes.

The proposal passing criteria has also been updated to avoid passing by a simple majority:

• 25% of all voting Service Nodes in this Superblock must have voted on the proposal
• 60% of votes must be “yes” (in favor)
• At this point all valid proposals are prioritized according to these requirements:

1. Descending order by the sum of yes votes minus no votes

2. Descending order by amount of yes votes

3. Sequential order by block height the proposal is submitted (earlier blocks are first)

• The Superblock is then filled by as many valid proposals as possible according to the priority defined by (1), (2), and (3).
• If there are not enough funds remaining in the Superblock for a proposal to fit, it is skipped (not paid out), and the next proposal in the priority list is checked for qualification

Additionally, the new system has introduced the ability to add short descriptions to the proposal and longer URLs for better security. Having the ability to submit a longer URL means you don’t need to use a shortener, which could easily be used to direct you to a malicious website.

The rewrite of this governance system is a huge accomplishment and provides us with better tools that better suit the needs of a growing project. We have a lot of flexibility with this system so in the future we can even create new types of proposals, such as non-funding polling that doesn’t have a payout.

Service Nodes

Just like with the governance and staking reward makeovers, the Service Node list was the driving factor in revamping the Service Node system. Service Node collateral now only requires 2 confirmations, there is no longer a significant waiting period for activation. We have completely removed the Service Node list from the consensus protocol. The Service Node list is no longer required in block validation on the network.

As previously mentioned, with the new staking protocol Service Nodes will be able to participate in staking, which greatly increases the security of the network. Service Node collateral inputs are tracked, similarly to the governance system and votes. When Service Node collateral stakes or is spent, the system automatically attempts to re-register your Service Node with the network.

Another tool that we implemented to make Service Node operation a little easier is an automated input splitting mechanism that takes your funds and easily splits them into the proper size and quantities to setup your Service Node. You can find the instructions on how setup your Service Node here: Service Node Setup Guide

XRouter & XCloud & XBridge

Because Comet uses the BTC codebase, this also benefits XRouter, XCloud, and XBridge with the aforementioned improvements in scalability and networking efficiencies.

However, relying just on the technology in the wallet isn’t enough to support enterprise clients as it can’t handle a high frequency of calls. That is why we have integrated DNS for Service Nodes and are currently developing the Enterprise XRouter Proxy, currently in closed beta.

XRouter now supports DNS for Service Nodes, which allows you to setup a more traditional service-oriented architecture (SOA). This means that you can expose your backend services and data oracles to XRouter through an nginx reverse proxy (such as the Enterprise XRouter Proxy) that sits behind a specific domain. This also allows for a load balanced environment and support for much higher transactions per second.

The Enterprise XRouter Proxy, to be released soon, is currently in a closed beta. The Blocknet team will be officially supporting this tool. It has been designed specifically for the XRouter protocol and greatly reduces the latency of handling XRouter requests. This tool exposes XRouter services outside the blockchain network, meaning that developers can interact with XRouter without having any blockchains installed locally in their environments. Please reach out to the team if you would like to get involved with testing this new product.

Catering to developer feedback, we’ve also made some additional changes. It was mentioned that XCloud blockchain calls would be easier to integrate and test if they matched the native calls. To accommodate this feedback we added support for underscores in XRouter service names since a lot of Ethereum calls contain underscores, and we’ve also updated the XCloud Setup Guide to reflect this convention.

Other improvements we’ve made include removing the xrouter= requirement from blocknet.conf and enabling XRouter by default. Service Nodes send their XRouter and XCloud config data automatically with their service pings. If you would like to disable XRouter you can still set xrouter=0 in the blocknet.conf.

There are two new configuration parameters as well that have been implemented for XBridge and XRouter to support JSON 2.0 and ContentType request headers. These two parameters are important to allow support for blockchains that utilize different JSON RPC versions and ContentType’s. This fix allows for additional XBridge SPV and XCloud RPC plugin support that was not available prior to the addition of these parameters.

A new API call dxGetTradingData has been created and will eventually replace the legacy gettradingdata call. This change was made to match the API naming convention of the other Blocknet protocol API calls. In addition to this change, the returned key names have been updated to reflect a more intuitive naming convention.

The API help responses have also been updated for all XBridge and XRouter calls. Each help response will return detailed information on the call. Additionally there are usage examples on how to use the call properly, either via blocknet-cli or curl. These can be viewed in the Blocknet console by typing help followed by the call name.

How to make the transition to Comet

This update is MANDATORY for everyone, regardless if you’re a holder, staker, service provider, or Service Node operator. Everyone must update by February 20th 6pm UTC +0.

Download Blocknet Comet v4.0

Install the new wallet as you would with any other application. If your balance is 0 after fully syncing the new chain, then follow these instructions. There is also a v4 bootstrap available to speed up syncing.

The instructions for setting up a Service Node can be viewed here and the new guide for voting on proposals can be viewed here. If you have any questions regarding the update, please join the #support channel in our Discord or Telegram. All Service Nodes will need to be setup again on the new wallet.

Looking Forward

With the Comet release under our belt, we have a solid foundation to develop on. Blocknet has many exciting milestones approaching as we move through the year including XRouter C++ and Golang lite libraries to interact with XRouter without requiring the installation of the Blocknet wallet, the Enterprise XRouter Proxy which will allow Service Nodes to handle millions of requests per second, XBridge Segwit address and staking input compatibility, partial orders for Block DX, an XRouter-powered lite multiwallet developed by CloudChains Inc that’s compatible with Block DX, and much much more.

To learn more about Blocknet, check out our website, API, documentation, Discord, and whitepaper. You can also check out the full 2020 roadmap here.

— — — — — —

Website / Block DX Website / Documentation Portal / API Docs / Discord / Twitter / Medium / Telegram / Reddit / Newsletter / Blocknet Facebook / Block DX Facebook / YouTube / DTube / Instagram / Minds / BitcoinTalk / Proposal Forum / Block Node Info / Blockdx.co