Based on the feedback received from the community following the Dash Platform presentation at Dash Convention Europe, we would like to share the rationale for introducing a separate Platform Chain.

Platform Overview

As previously discussed in the Introduction to Dash Platform post, Dash Platform is a technology stack (a set of services) for developing decentralized applications.

Initially, we will provide:

• Drive — document-oriented database for storing and querying metadata
• Identities — unique identities for users, applications and other entities
• Dash Platform Name Service — decentralized and enhanced DNS
• DAPI — decentralized HTTP API to communicate with the platform

In the future, we are going to introduce a communication protocol between users and applications, payment requests, access rules for Drive data, and more. The list of future services is not fully defined yet.

In order to host and operate these services, Dash Platform will run exclusively on the masternode network. Compared to using the entire Dash network, this is a much more scalable solution because masternodes will be economically incentivized to provide high-quality service. For processing and storing the Platform State (the global platform dataset), the platform needs a byzantine fault-tolerant consensus protocol. This consensus protocol ensures that a quorum (i.e. subset) of masternodes validates and processes the data in a trustless manner.

For example, let’s assume we have a Dash Platform application, memo.dash, a decentralized Twitter clone and the Dash analog of https://memo.cash. In order to create a new memo and update the application state (a subset of the Platform State), we need to create and send a state transition¹ with this memo to the platform via DAPI. The platform, in turn, should process the state transition and update the application state. Once this is complete, the platform will…

1. Propagate the state transition within a masternode quorum
2. Validate it with the quorum according to platform consensus rules
3. Record it on the blockchain
4. Update the Platform State when the state transition is finalized (confirmed on the blockchain)

The problem of how to best record and finalize state transitions presents us with two potential solutions: use the existing blockchain or introduce a new blockchain solely for the platform.

Comparison of Solutions

If we use the existing blockchain for state transitions, we are faced with some downsides:

1. Inefficient Resource Usage
   Since state transitions are only needed on masternodes, using the existing chain would unnecessarily consume extra disk space and increase network load for the entire network. This is because we would need miners to process and put state transitions into blocks. Then, the blocks would be propagated across the whole network and stored on all full nodes.
2. More Expensive, Non-Deterministic State Transition Fees
   With miners involved, it would be necessary to pay fees for state transitions to both masternodes (which process and store the data) and miners. Such fees are non-deterministic since the existing blockchain’s fees can vary based on factors such as transaction size and block capacity. Deterministic fees are desirable for businesses and developers that may want to adopt Dash Platform, as they make it possible to calculate costs in advance for budgeting and planning purposes.
3. Inefficient Data Verification for Light Clients
   The verification of platform data for light clients (similar to SPV) is complex and inefficient. Let’s go back to our example with memo.dash. As a client, in order to prove that memos exist in Platform State and weren’t modified by a bad actor, you need to download block headers, merkle proofs and state transitions for each memo.
4. Poor UX Due to Block Confirmation Times
   The block time of 2.5 minutes is not an acceptable user experience (UX) for platform applications. Imagine a user creating a memo and then waiting several minutes for the memo to appear in their application. This wait time is a consequence of the state transition needing to be confirmed on the blockchain. Although we could lock state transitions via a process similar to InstantSend, there is no guarantee that a miner would put them into the next block (or any particular block).
5. Increased Complexity and Risk to Existing Chain
   By introducing state transitions and other platform functionality into the existing chain, we would add more complexity, as well as possible bugs and attack vectors, to the most critical part of our system — payments.

If we introduce an additional blockchain for Dash Platform we solve those problems:

1. Efficient Resource Usage
   Running the Platform Chain exclusively on the masternode network reduces the overall network load and the size of the existing blockchain.
2. Cheaper, Deterministic State Transition Fees
   Without miners involved, state transition fees only go to masternodes. This reduces the cost of using Dash Platform and simplifies the fee calculations. So now fees depend only on data size and the complexity of the data processing operations. Since the costs are predefined, businesses and developers will be able to deterministically calculate the price of the state transition before sending it to DAPI.
3. Easy Data Verification for Light Clients
   In order to make data verifiable for light clients, we store Platform State as a merkle forest (multi-level merkle trees²) and save the merkle root in block headers. Going back to our previous example, to verify any memo in memo.dash a client only needs to get a merkle proof and the last header signed by the quorum. This state-centric approach makes verification for light clients much easier than classic SPV. Additionally, blocks become less significant, which means we don’t need to be concerned about blockchain data sharding and can simply keep the most recent blocks.
4. Faster State Transition Finalization for Better UX
   Since it’s a separate blockchain, we’re implementing a consensus protocol that fits the platform requirements. Instead of Proof-of-Work, we can rely on the incentivized masternodes and build a Proof-of-Service based consensus. If a masternode doesn’t provide a service or misbehaves, it will be punished. Thus, utilizing masternode quorums for block proposing and validation allows us to both reduce block time to seconds and ensure absolute finality. This significantly simplifies Platform State and Drive, because it isn’t necessary to handle blockchain reorgs.
5. Decreased Risk to Core Functionality
   Introducing a separate blockchain decouples Dash Platform from the current Dash functionality and builds it as a second layer. The first layer doesn’t know about the second one, so if something happens with the platform it won’t affect the existing blockchain and its payment functionality.

Conclusion

Ultimately, the decision to use a second chain was driven by our goal of providing the best possible user experience, one that is indistinguishable from non-crypto apps, while retaining the security benefits of a blockchain. The Platform Chain emerged as a way to achieve the speed/finality necessary for the UX and support the network/storage scalability of the system. It also simplified the architecture by decoupling the Platform and the existing chain. Combined, these advantages make the introduction of a second chain the obvious choice.

We hope this answers many of the questions you have regarding the Platform Chain. We encourage you to stay tuned for future details about the overall platform architecture.

¹ State Transition — see https://blog.dash.org/an-introduction-to-dash-platform-dapi-and-drive-9d080d6e89c9

² Merkle Tree — https://en.wikipedia.org/wiki/Merkle_tree