Dash August 2016 Development Update
I wanted to take some time to update the community about the state of the project and our current work. As you likely know, I recently returned from the d10e conference, where I met a number of volunteers and enthusiasts from the community. We also established many new industry connections. Conferences are incredibly useful, and they remind us that the world has not been exposed to enough information about Dash for it to reach more than a small subset of people even within a community like d10e. Nine of ten people I personally spoke to were completely unaware of what we’re doing, but as they learned about it most became incredibly excited to hear something like this was being created. Dash-only features like self-governance, self-funding, decentralized api access, interest bearing accounts and masternodes were the features these investors were most excited about.
After returning from the conference, we’re quickly picking up where we left off on 12.1. This is a critical phase of development, far more than at any point we’ve been in the past. This is the phase where we need to anticipate as many use cases as possible for the evolution software, since providing new functionality at a later stage will be more complex. Therefore, this phase is arguably more important than it would be in a centralized company, as we have seen from other projects in the space, due to the complexity of altering decentralized systems after they are in the wild.
There are currently two separate teams developing the next version of Dash. These are the Evolution team, and dash-core. The Evolution team is tasked with creating a simple user interface to provide a secure, fun, and easy user experience. While this sounds simple, it’s nothing of the sort. The team is building three separate wallets for different audiences. These are going to be the personal-client, merchant-client, and operator-client. The personal-client provides the most simple experience, allowing end-users to engage in social commerce with friends and in transactions with merchants who list their apps and services within a decentralized marketplace in Evolution. The merchant-client will enable the merchants to manage their product and service listings, customer payments, and subscriptions in Evolution. The operator-client enables Masternode operators, moderators, and other incentivized roles to access their functions from a simple client.
The team is also building the decentralized REST API to be hosted on the Masternode network and a set of SDKs for major platforms. Together, these capabilities will enable merchants to quickly and easily integrate decentralized Dash transactions into any website or app, and without the need to host a Dash node of their own. Integrating Dash into a website or app will be as simple as integrating a few lines of code, similar to what payment gateway providers like Braintree and Stripe provide for online merchants. This will significantly reduce the barriers to digital currency adoption for online merchants, allowing them to integrate Dash within hours and without the need for third-party services, fees, or infrastructure.
On the dash-core side, the team has been working on general usability/stability of 12.1. We are also integrating a basic version of dashdrive into the system. Dashdrive is the storage mechanism that sentinel+dashd use to store information on the network. At this point it is in a basic state that allows for objects to be created and stored as they will in the future. However the current storage capacity is quite small presently. For now, we will only be storing governance system data, mirroring the system setup for budgets from 12.0.
After the release of 12.1, utilizing this new technology to build our budgets, we will begin adding additional required pieces of functionality to integrate the two sides of the project. This involves beginning to use dashdrive as it was intended, as a storage mechanism for user data. New functionalities such as creation of users, groups, accounts and the ability to pay-to-url will be next on the development roadmap.
12.1 is also going to be something of a “pre-alpha” for Evolution. This means it will be able to store some of the basic data structures required for a user to register their Evolution account and be able to use it in basic ways. Many of the more advanced functionalities will first be exposed via CLI, allowing more experienced users access into the system before we implement the features into the evo-client.
As for current testing process, after d10e we have been busy onboarding some new highly-skilled developers into the core-team, which will be helping us to thoroughly test and refine 12.1 and will continue into 12.2 development. This additional capacity and expertise will accelerate the pace and quality of testing, bug-fixing, and ongoing core development, and allow progress to continue unabated even when my time may be required for events or business-related needs.
Testing is currently progressing for 12.1, and we are presently working on getting superblocks to be created and accepted on the network. This introduces a lot of new code and needs some work before community-wide public testing would be beneficial. The current one is a process of debugging thousands of new lines of code, and making sure most of the work flows are tested and function on a basic level without critical errors. We should expect to shift to public testing of version 12.1 within the next two weeks.