Hong Kong | Research and Planning

Over the past year Andy Freer and his team have been preparing a comprehensive plan for the launch of Dash Evolution. Because of the vast amount of foundational work and the high stakes involved, we have been careful about releasing too much information at the beginning of the project. We don’t want to give our competition an edge, nor do we want to make “promises” without knowing whether they are feasible.

We began the Evolution design process with a series of prototypes that were quick and dirty. These prototypes showed the main concepts of the wallet and how it would operate. More recently, we’ve moved to using DIPS, Dash Improvement Proposals, for a highly detailed internal process of imagining, planning and creating Dash Evolution.

All conceptual components were finished a few weeks ago and I’ve been serving as an advisor to Andy and his team. Toward the end of this process, I was excited to jump on a plane and come out to Hong Kong, visiting Andy and other community members located here. Once I arrived, I began the process of walking through their plan and helping to create the most comprehensive, all-inclusive plan to date. This plan literally covers every last detail of Evolution’s architecture, its economics, how it all works, and how it will be implemented.

I’m happy to announce that after several days of planning, meeting, and documenting, we have finished the final version of Dash Evolution’s roadmap and implementation plan. This is a game-changing plan which turns our network from a small, minor player in the space into the first ever network capable of competing with major payment networks directly. We will be able to compete with credit cards on their own level, matching their transactional volume but charging lower fees and easier to use solutions, and we will do this while maintaining complete decentralization.

There are a few new concepts I’d like to outline:

Masterblocks : Moving from soft consensus to hard consensus of masternode list
Masternode shares : Allowing depositors to earn returns and vote from partial masternodes
Scaling to ultra large blocks : All-inclusive plan for building hardware and software to move from 2MB blocks through 400MB blocks
State transitions : Tracking changes to DashDrive
Network maintenance functions : Using quorum technology to build administrative functions, akin to a decentralized crontab which updates DashDrive.
Governance objects : All objects required for initial launch are determined and working theoretically to store user information securely and efficiently
Credit system : A credit/debit system for incremental value charges related to the storage of data and user processing power.
New fee structure : Lower fees become economically viable

The model works economically, will be fully incentivized at every level, and will be implemented using a continuous improvements to the network. Our plan is heavily reliant on masternode concepts, such as collateralization, quorum-based actions and our two-tier optimized network. We are building Evolution in such a way that Dash will maintain market advantage as it grows. Over time, we will perfect and implement each individual component, scaling efficiently and creating an insurmountable competitive advantage.

We are far ahead of every other project in the space, having been aided greatly by our decentralized governance and budgeting system. Using the budget system, we have been (and will continue to be) able to pay for top talent to design and implement each component without falling into centralized profit-seeking methodologies that result in bottlenecks and potential points of failure.

We are using a strategy of incremental development which will allow us to roll out Evolution in multiple stages. Each new phase of development will target 10x user growth, while incorporating new features such as trustless masternode shares, blind mixing and ultra-large blocks with quick propagation times.

We are building a system capable of handling massive amounts of user traffic and supporting vast number of transactions-per-second. We anticipate that such scale will require masternodes to run on specialized, custom-built hardware created specifically for the Dash network. We are designing that hardware now, and are doing so in a transparent, decentralized fashion. By designing and creating this hardware ourselves, we will be able to ensure it meets the needs of the network while maintaining the highest level of security.

What follows is the plan that will bring Dash Evolution to life, allowing it to support millions of users in the space of just a few years. Evolution will allow Dash to become the first digital currency to reach mass-market adoption. We will achieve this while maintaining complete decentralization. We will also add important security features that until now have remained undisclosed.

Collateralization, Quorums and DashDrive

Each part of the Dash Evolution architecture will be hardened, allowing only specific approved actions to happen on the network. For example, we will utilize the first decentralized database with full schema, readable and writable data structure, stored across the network in a sharded database. We secure this via a concept called collateralization and quorums. Each write to the database requires a pseudo-random set of masternodes, called a quorum, to agree and sign a message. If the majority of this quorum agrees, the write object will be wrapped in these masternode signatures and relayed internally to DashDrive. By using masternode quorums, we ensure that our network is sybil-proof. Any attempt to attack the network would require the attacker to control an enormous number of masternodes, which would be prohibitively expensive.

Quorums themselves are hardened by proof-of-work hashes which form the seed for the randomizing quorum function. In order to attack this system, one would either need a huge amount of Dash (to attack the quorums directly) or a vast amount of mining power (to alter the randomization seed). We anticipate that either attack would be obscenely expensive and uneconomical. Because of the importance of these random seeds, both our thriving ASIC market and a forthcoming collateralized mining requirement become important foundational elements in the success and security of our product.

I have always been opposed to any switch to a proof-of-stake consensus method due to potential security issues. While doing research for Evolution, it has become clear that the only way to securely implement quorum-style technology is to utilize our hybrid proof-of-work (mining) and proof-of-service (masternodes) model. Competitors who have switched to proof-of-stake should consider switching back to proof-of-work to harden their hashes if they wish to use quorum technology. Without proof-of-work providing an additional layer of security, such systems are vulnerable to several different forms of attack.

Democratic Voting Process

All actions on the network are done using a democratic voting process, where the collateralized masternodes are the only members allowed to vote on network topics. Additionally, end-users will also gain the ability to vote on network issues by moving money into trustless masternode shares. This will give the depositors a say in the direction of the network, maintaining equal distribution of power/influence over the network itself. By allowing masternode shares via savings accounts we lower the threshold required to participate in governance and decrease the power of large masternode owners. This will cause our network to become even more decentralized.

Not-for-Profit / Team Structure

We are committed to maintaining a not-for-profit mindset, where individuals are paid for the work they do, but a corporate organization doesn’t take a “cut” of the profit. We will organize ourselves into multiple small groups, each with it’s own management structure, administration protocols, strategies, assignments, goals and projects. These teams will be paid directly from our blockchain. This removes the need for profit-seeking behavior, since funding is guaranteed by the network as long as the appropriate milestones are met.This structure is anti-fragile and anyone, from any team, at any time, can be fired by the network itself. This will surgically remove infections from the project and prevent fragmentation of the community long term while still allowing exponential growth of our global workforce.

Dash Network — Software Applications

CORE DAEMON : This is the main daemon that that does much of the work of the network. It relays blocks, validates blocks and transactions and ultimately is responsible for maintaining the blockchain ledger.
DAPI : This is the third-tier interface, allowing our edge users to maintain a connection to the network and access services from a distance without having to download and validate large amounts of data themselves
DASHDRIVE : This is where we store user object information in a decentralized and secure way on the network. Only those with proper permissions can update various pieces of data.
ADAPI : We utilize onion-type routing to securely and anonymously access services of DAPI, allowing users to maintain privacy if needed. This is automatically used for our new implementation of ”Privacy,” a cutting edge, improved version of PrivateSend.

Teams & Offices

I myself will be heading up the new office in Hong Kong, called “Dash Labs.” We will immediately begin building proof-of-concepts of custom masternode hardware. Our existing offices in Arizona will be used for academic research. This research will be aimed at proving our ideas work and proactively searching for any problems before they crop up.

Dash Ethos and Philosophy

We are building a world-wide financial network capable of putting every individual’s money under his/her direct control without intermediaries. We are building Dash Evolution because we believe it’s needed and offers value to society. We are not building it to get rich. Since we do not have short-term profit motives, we shouldn’t rush an unfinished product to market. We are building a quality assurance team that will thoroughly evaluate the software and ensure that it meets a standard of 99.999% uptime. Ultimately we are targeting customers used to legacy banking and payment solutions. They will not necessarily care about decentralization; instead, they will want software that “just works,” and that works all the time. It is ultimately this group of customers we must keep in mind while designing and implementing Dash Evolution.