I am excited to finally share and release the first public version of the Herdius blockchain. This first version is named Foundation and as the name suggests, servers as our base infrastructure upon which our vision is to be built. Many months of development and work from our team has gone into the project, and after having ran our internal testnet for the last month, we feel confident in releasing our architecture for everyone to use.
You can access the Herdius repository here: https://github.com/herdius/herdius-core
At a glance
The first public version of the Herdius blockchain includes a fully fledged blockchain that is fully functional and ready to be deployed. It is tailored to fit our own specific needs and roadmap to facilitate a medium to transfer assets of all kind. These assets primarily are different crypto currencies, stocks, fiat currency, etc. We were aiming to create a stable base upon which we easily can build and complete the overall Herdius architecture by updating and adding currently still missing components and functionality
Our current setup is semi-decentralized due to the fact that our Supervisor node (explained below) right now is currently a single node instead of it being decentralized and distributed. If anyone wants to utilize the current release in production environment, we advise they do so in a private network/setup. Everything is ready for deployment with instructions to be found inside our repository on how to deploy Herdius Core on your own, as part of a dedicated server, or a network of EC2 instances on AWS.
Our architecture follows all of the major initial ides that were described in our technical paper and through different articles on our Medium. Specifically the interesting bit of our design is something we call Blocks-on-Blocks, BoB in short. We wanted to create an architecture which scales with transaction volume and the number of validators but without putting a bottleneck on performance, that is where the idea of BoB came up. By having transactions batched into smaller set of blocks, then having each of these individual blocks validated by different validator groups, nodes can validate blocks in parallel. At the center of our architecture is something we call the supervisor node which, for now, controls general transaction flow and acts as a safeguard in the system. In the current environment it acts as a buffer between nodes and the users.
To illustrate how our network work below is an example transaction journey:
Step 1: Supervisor node makes a copy of the last approved blockchain State (S) and creates S’
Step 2: Inside every block there is a list of candidates of nodes who commit to perform validation
Step 3: Supervisor node assigns validators into groups (currently randomly), creates a Merkle tree of their address for each group
Step 4: User creates transaction packet and transmits it to supervisor node
Step 5: Supervisor node validates transaction against State S’
Step 6: Supervisor node places transaction into batches of 500 Tx each
Step 7: Supervisor node builds up the BoB structure, hashing all the blocks roots and connecting them; assigns each block to a different validator group
Step 8: Validators perform block validation, vote on result within their group to reach consensus which is then sent back to Supervisor node
Step 9: Supervisor node receives consensus result, finalizes all blocks and adds block to the blockchain
There are several advantages of using BoB, the most obvious and important are:
- it reduces the size of validators from the whole network, to a smaller subset of nodes. This means that not all nodes of the network have to agree on a transaction being valid, but only those within their own validator group.
- it eliminates the problem of cross-block communication (cross-shard translated to our wording) as the validator groups do not have to communicate with each other. This saves a considerable amount of bandwith
- Tx validation can run in parallel without compromising us to double-spend attacks. Whatever happens in sub block #1 does not influence block #9. e.g. if Alice/Bob creates 100 Txs and transmits them to the supervisor with some time delay in-between them, more than likely these transactions will be in different batches, assigned to different validators. Due to the fact that the Supervisor node already has a State S’ it continuously amends, double spend risk is avoided.
Along the way many people have been saying that BoB is similar to sharding, it is. We first imagined BoB during the end summer, 2017 which coincidentally also is the time when the first sharding specification came out.
Benchmarks and performance
We have had the fully deployed Herdius blockchain running on our testnet. In order to simulate a distributed network, we utilised AWS EC2 small (2 CPU cores, 2GB RAM, 8GB storage) instances spread around different continents and datacenters to simulate validator nodes. Our central supervisor node was hosted in Frankfurt, Germany. We also created 3,000 sample transactions that we continuously fed to the network. From the moment a user sent 3000 continuous transactions, it took the whole network 5.31s to finalise and agree on all the blocks within.
One of the most obvious aspects of the system might be that the supervisor component is not decentralized. This was done on purpose for this version as it still aligns with our roadmap in the current quarter. Having the supervisor node of our system to be fully distributed (and here I mean no masternodes, 21 nodes, 100, or other similar schenenigans) would take away most of our dev power to be fully focused on it for a month or so. Something that does not align with our current plans of finishing and releasing our wallet in March.It is also quite difficult to do. There is no right way, or paths that have been tested, and when you make a system that will be public eventually. You better know what you are doing and that it is safe.
Staking is also a component that is missing and we do fully plan to realise our modified version of PoS. Once again we would rather have a perfectly usable product out now that different companies can already use than have something we work on for years without it functioning during that time. The HER token will play a role in the system and every validator needs to have. From this side we aim for an architecture that is easy to use and see through and this means no messy smart contracts. Two possible solutions here: 1) when you run a validator node you simply have an associated address with you HER. You decide how much to risk/commit and fees are distributed automatically straight to your client. 2) you have HER inside our wallet and that is it, fees come to your wallet depending on the amount you hold.
On Governance side my opinion still has not changed. We plan to do what we outlined in our initial paper to include our token holders in decisions as much as possible. Nothing more on this for now as my view that governance is a mess from one year ago still has not changed.
We welcome other blockchain companies, corporates, or anyone interested to contribute, participate, and help. We are happy to provide our ideas and plans on how to solve staking, decentralization of the supervisor node, voting, etc. Feel free to get in touch.
I am happy we got here and excited for our releases and what we have in store. To be more precise this includes our above mentioned multi-currency crypto currency wallet for Mac & Windows and IOS (bit later than the previous two). Sure that does not sound exciting in itself, but herdius-core was not the only project we worked on. Our distributed key generation protocol is to be finished very, very soon. When you combine it with the wallet, things are more exciting :)