Core Platform Development Updates, August 2019
The Dragonchain Development team was super happy to finally open source release our core blockchain platform last week, allowing the community a peek into some of what we have been working on.
We were hoping to shed a little more context on what exactly we’re working on in regard to the Dragonchain core platform, as we are still actively developing and improving it daily.
As a note, with this open source release, it is now possible to spin up a Dragonchain on your own hardware in order to participate in Dragon Net! Right now the process to run a Dragonchain on your own hardware is a bit involved, but we are working to make it much easier in the future. Here are a few of the things we are working on in Dragonchain core right now:
Complete Overhaul of the Dragonchain Console UI & UX
We are working on a complete overhaul of the console which will make Dragonchain’s functionality more clear and easy to use, thanks to an improved and more intuitive UX. In addition,the new UI will support interacting with your self-hosted Dragonchains, so even Dragonchains running on your own hardware will be easier to interact with. There are many other improvements with this new UI & UX. It is a complete rewrite from the ground up. We hope this allows much more user friendly interactions for those preferring not to use a command-line or SDK.
For enterprise customers and developers alike, the new console will greatly improve the process of handling chains. Dragons are now also expected to be utilized throughout the system for various purposes, such as spinning up Business nodes (L1) and creating transactions.
Overhaul of the Interchain Management on Dragonchain
Dragonchain currently has native interchain abilities with a few public blockchains. This is accomplished now by generating keys for these public blockchain networks upon creation, and using these to interact with the other networks. While this method works, it means that users aren’t able to easily add their own keys/addresses if they wish, and it’s not super easy to add your own specifications for an interchain network (for example specifying which bitcoin rpc node you want Dragonchain to interact with).
We are working on a refactor of much of the interchain code with Dragonchain to address all of these problems. Once this refactor completes, users will be able to add their own keys for public blockchain networks (if they wish), as well as allow multiple ‘accounts’ per public network. Each ‘account’ can have its own keys, so a Dragonchain will be able to interact with public blockchains over any number of addresses, not just a single one set up on creation of the Dragonchain. It will also allow users to specify custom public nodes if they host their own or do not wish to use the ones provided by Dragonchain. Lastly, this refactor will make it significantly easier for interchains with other public networks added in the future. This will allow us to much more efficiently add functionality for many public blockchains, and easier for anyone in the community to add their own integrations.
Changing up Dragonchain’s Indexing System
Currently, all Dragonchains use Elasticsearch as an indexing solution for various data points within the chain. This is also what allows us to provide query endpoints, and custom indexing for transactions. The problem with this is that Elasticsearch requires A LOT of resources to run, and is not really meant to be run as a single-node service. We currently allocate over 1.5GB of RAM for each Dragonchain’s Elasticsearch, and even still it is not a performant solution.
With this in mind, we have evaluated other options, and have settled on using RediSearch as a replacement. Not only is RediSearch over 10x faster than elasticsearch in our testing, but it also has 1/10th the resource footprint for our uses. Replacing Elasticsearch with RediSearch is a huge step in making a Dragonchain capable of running on lower-end hardware.
In addition to this, RediSearch also allows us to expose a more powerful custom indexing solution for transactions. With this change, Dragonchain query endpoints as well as transaction custom indexing will have a breaking change, but will be much more powerful as a result.
Further, we will be refactoring all of the indexing code in Dragonchain, marking a huge step toward making the indexing system optional in the future. We hope that in the future, an indexing solution isn’t a required component of Dragonchain, thus lowering the resource footprint even more and providing useful added features if desired. For now, RediSearch will remain required, and its functionality will be enabled on all Dragonchains.
Optimizing the Dragonchain Creation Process
At this time it is super easy to go to Dragonchain’s managed service in order to spin up a Dragonchain and start developing with it. With our open source release, we allow developers to run their own instances of a Dragonchain locally for even quicker development. This is possible today, however the process to get a Dragonchain up and running on a user’s own hardware is not trivial. The Dragonchain platform was built as a Kubernetes-first application, meaning it requires a Kubernetes cluster with some configuration in order to deploy a Dragonchain.
We know that this is far from ideal for small deployments of Dragonchains on single machines, and we’re working towards a solution to allow a Dragonchain much easier creation and deployment. In the further future, we expect to fully support Dragonchain deployed to other container management platforms such as Docker Swarm. With this said, in order to address ease of deployment in the near future, we will create and maintain scripts to ensure ease while setting up/configuring a Kubernetes cluster and Dragonchain deployment. Our goal is to provide as close to a 1-click deployment as possible. Anyone with interest should easily be able to get up and running with their own Dragonchain.
Lowering Dragonchain Resource Requirements
At the moment, a Dragonchain requires a fair amount of resources (specifically RAM) to run. We are addressing this right now in multiple ways. Removing Elasticsearch as mentioned earlier will be a huge step toward this, but we will also be optimizing the deployments to offer a range of settings for a Dragonchain.
Currently we use Helm with templates to manage Dragonchain deployments on Kubernetes clusters. We are working towards offering a few presets for these templates in order to adjust how many resources to allocate towards a Dragonchain. This will allow users to give a chain more resources if they want it to be more performant, as well as allowing a Dragonchain to run on much less capable hardware with no issues. It’s worth noting that it’s possible to tweak the helm charts for a Dragonchain deployment today in order to optimize performance on your own, we simply plan to offer more optimized presets in the future.
We are also looking into making Dragonchain support other CPU architectures (specifically ARM), which would allow a Dragonchain to run on a Raspberry Pi. Currently our platform only runs on x86_64 cpus, but we plan on expanding this in the future.
This is all part of a greater effort where we plan to create and Open Source a streamlined deployment process. The astute among you may have noticed that the Dragonchain core repo only includes a single pre-packaged helm chart for deployment). This will be expanded in the future, with a goal to maintain a separate open source repository for helm (and other types, i.e. Docker Swarm) deployment.
Open Source Releasing Library Smart Contracts
Right now, through the Dragonchain web console, a few library smart contracts can be easily deployed to a chain with only a few parameters. We are currently working towards cleaning these up in order to properly release them as open source. We already have a reference for some basic starters in order to create smart contracts in various languages, however in the future we will also provide our Library Smart Contracts open source as further references for smart contract creation, as well as to demonstrate some best practices.