State of Development 2018

2017 was an amazing year for the Halo Platform. We saw a successful ICO, new team members added, a growing community, and the skyrocketing success of cryptocurrency.

We are well funded for many years of development for Halo Platform. We have several divisions of teams already working hard on your beloved blockchain. A few of the teams are:

1. Coin Team — Lead by Halo-Amer. This team is dedicated to the development of our coin node and masternode software. They are experts in C++ and Solidity and have been rocking it out on the coin software.
2. DAPP Team — Lead by Halo-Shannon. This team is focused on your front end applications such as the wallet, masternode control, and governances applications.
3. Tool Team — Lead by Halo-Shannon. This team is working on bringing you quality tools to interact with our blockchain. Items this team works on are Feather client and metamask.
4. Mining Pool & Blockchain Explorer — Lead by Halo-Mike. Tools to allow you to mine and explore the blockchain.
5. Exchange Team — Lead by Halo-Mike. The high quality and high speed exchange you have all been dreaming about. This team is focused on the design and development of the low level code, infrastructure, and front end design of your exchange.
6. Wiki Team — Lead by Halo-Jarett. Getting your documentation created is Jarett’s highest priority. He is working on compiling information from all different sources to give you some breakdown on how to use our system and cryptocurrency in general.
7. Security Team — Lead by Halo-Mike. Your security is our #1 priority. We constantly review code, submit code for audit, and check our dependencies and tools we use for security holes or flaws.

These are the current teams working to build your blockchain paradise. Now, how about we talk a little about where each part of the project is at?

General Development

We are currently ending a sprint and preparing to go into a new sprint next week. This sprint will be spent putting the final polish on the system and getting ready to launch. The last few sprints have seen us go from code and hopes to working test networks and live transactions. Over 50% of our open tickets have been closed, and with a majority of the open ones being created within the last week or so.

Open and Closed Issues

A lot of the tasks that are still open are tasks to be completed after go-live and distribution of ICO coins. We are also doing some revamping of the UX/UI for masternode control. You’ll see some of the old UI later on when we go over masternodes.

We also had a major security vulnerability that we have addressed regarding Electron and the MIST wallet. We were using a fork of the MIST wallet as our main wallet for deployment. However Electron which MIST is built on is slow to get patches and updates to an underlying component of it the Chromium browser. A remote code execution vulnerability was patched in Chromium, but not patched in Electron. After about 2 weeks of internal testing and development to mitigate this risk, Electron team still did not know about the vulnerability. This was unacceptable to us. So we looked to the brave browser team and started working with the tools they have developed. Muon, their fork of Electron, is a lot more secure and up to date than Electron. The result of this was a new client called the feather/lite client. The “/” is not a typo. It has two flavors “Feather” and “Featherlite”. More will be discussed on this and Feather further down.

The Coin Codebase

Amer and his team have worked their little hineys off getting the coin codebase ready for public use. They are currently testing network stability and the new transaction types (Instant send & private send). We have successfully started a handful of private networks and we have two nodes up on a test network right now running in the cloud.

After transaction type testing is completed we will start moving into load and stress testing. We want to see the limits of the network with a lot of nodes connected and transacting.

We are putting intensive care into testing and ensuring our blockchain meets world-class security standards. We will not release a coin if we perceive any threat to it, and work to mitigate that threat to release it.

External Review also needs to be finished before we release code and publish the network.

Masternode Control

Masternodes are going to be fully controlled by smart contracts and will require a physical server (bare metal or VPS) in order to operate. We plan to have masternode hosting available through the platform, and using it will take a single click.

While you are not required to use our hosting to run your own fully owned masternode, if you operate a shared masternode through our masternode marketplace, you will be required to host the masternode in our cloud.

If you want more information about masternode tiers and payouts please see the Halo Platform white paper at: https://www.haloplatform.tech/assets/Halo-Whitepaper.pdf .

As you can see in the function listings shown, we have two contracts here that require interaction. One is for the administration of Masternodes and will be operated by the Halo Platform. The other is for the end user to apply for, and operate their masternode.

These images are rather old and don’t cover all the aspects tested, added to and removed from the platform. Please do not constitute anything here as an end product or what it will look like when delivered.

Our masternodes are split into three layers.

Masternode Admin
Masternode Ownership

MNAdmin is a contract that oversees the creation, suspension, and cancellation of masternodes. It is essentially the arch node that is dictating everything.

MNOwnership is for owners of masternodes that allows them to apply for, interact with, and cancel masternodes.

Here are some fancy flow charts for you to see the flow of how shared masternodes and single masternodes will work:

Co-Owned Masternodes

Single Owner Masternode

Aero Browser

Our Aero Browser was built on top of MIST browser by ethereum. Unfortunately it doesn’t fit our tech stack for front-end as it uses Meteor and not Vue. It also was large and overly complex for what it did and what we needed it to do. The final arrow that put it in the grave was a recent vulnerability that simply could not be fixed in MIST until the Electron team updated electron. Who knows when that will be, (As of writing this article, it’s several weeks later and no update to Electron). So this is our official announcement that Aero Browser was taken to the streets and flogged. It has been sacked from the project list as well, but as you will see in the next section, we have built a browser that will be even better!

Feather Client

What rose up out of the ashes of Aero Browser is the Feather client. Feather is a light client built using Muon (brave browser fork of electron), vuejs (used as the front end), and halo DAPPS. DAPPs are decentralized applications and utilize web3 to interact with the node. To get you enticed here is a nice screenshot of the settings page as it stands right now.

If you have a keen eye you would notice that “Hey! That says Featherlite and not Feather Client!”. You’d be right. See there are two flavors of Feather wrapped up in one. What you see here is Featherlite. What’s the difference? Simple. Featherlite runs off a hosted RPC connection, and Feather runs off a local light synced node. So with Featherlite you are not required to have any blockchain blocks downloaded to your machine. You don’t have to run a node, and you can get up and running immediately. With Feather you will have the option to download the node software, install it, and run it. There will be no difference in the use and interaction of the Feather Client from between Feather / Featherlite. The difference is in the internals and some people like to run a local node vs talking to a remote hosted node.

Even if you use Featherlite and use the hosted RPC node you would not be sending your keys anywhere. All your secrets and passwords are stored locally. Below is a flowchart of the startup and operation of Feather as it stands now and is planned to be built as.

A few things about this diagram that you should notice. The first is that, before we even launch the main part of the program, we are going to see if there is an urgent announcement. Something would be classified as urgent if it affects the security of the Feather Client in any way shape or form to the extent that it should not be used. After getting the remote data and checking it, if there is an urgent message then Feather is prevented from fully starting up and will display a link to the announcement message. Most likely that announcement would be posted to medium. Second, you’ll notice the node software is not downloaded unless you decided to use a local node. This prevents Featherlite from even using the space on your local device to store a useless software which you won’t use. Third, there is the option to “change network”. Since everything runs via metamask, as long as there is a metamask version for the blockchain we want to add, we can just drop it in. If there isn’t, then we probably are already working on a new version of metamask to talk to these other blockchains using the same system and protocol. Ex. LTC and BTC. Insert winky face here.

We have a simple plan to host the RPC network for metamask to consume and that is outline below:

Simply put we are going to load balance custom built C++ nodes that are built for retrieving data and returning it via RPC. Transaction signing and other parts that require heavy load or private data will not be done on the C++ nodes but rather on the local machine. See metamask’s provider engine for more details on that: https://github.com/MetaMask/provider-engine

There is still a lot of development and testing needed on the Feather Client for it to release, and we hope to get it wrapped up in this sprint or next. So that’s about 2–4 weeks.

Web3 For Developers

There is just a little bit of information about web3 that we wanted to talk about in this post. Since we are forked from ethereum, and we want to maintain the ecosystem we love and support that has been built for developers by ethereum, we are keeping the ethereum denominations and naming conventions for coin and web3 internals. This means that in Smart Contracts and Web3 calls you will be sending and receiving “ether” and “wei”.

However we are going to mask that backend processing wherever the end user would see the denomination. So for example in a wallet UI, the user will see that they have 12 halo. But internally it will be dealing with 12 ether.

This is to limit the confusion of the differentiating chains for the end user. However, as developers we deal with confusion like this all the time and it’s more practical for us to maintain the same ecosystem as ethereum does.

In addition to this, we will be adding some special functions to web3 itself. These functions will allow for developers to utilize our new transaction types (instant, private, and safe send). The availability of these functions in web3 may not be ready on go live, but will be shortly after that if not.

Conclusion

2017 was fast, crazy, and amazing. Let us turn our eyes to 2018 and what it has in store for the Halo Platform community. If you have questions or comments please reach out to us on discord, you can find us there at all times of the day.

Discord: https://discord.gg/PmveA6A

We have an initial wiki started and are constantly adding new content to it. Please see the wiki for some more information. https://wiki.haloplatform.tech/FAQ#halo-platform

^Shannon Duncan