https://blog.dash.org/introducing-the-platform-chain-982fe6aea67f
by @Ivan Shumkov
Based on the feedback received from the community following the "); background-size: 1px 1px; background-position: 0px calc(1em + 1px);">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 "); background-size: 1px 1px; background-position: 0px calc(1em + 1px);">Introduction to Dash Platform post, Dash Platform is a technology stack (a set of services) for developing decentralized applications.
Initially, we will provide:
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 "); background-size: 1px 1px; background-position: 0px calc(1em + 1px);">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…
Comparison of Solutions
If we use the existing blockchain for state transitions, we are faced with some downsides:
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 "); background-size: 1px 1px; background-position: 0px calc(1em + 1px);">https://blog.dash.org/an-introduction-to-dash-platform-dapi-and-drive-9d080d6e89c9
² Merkle Tree — "); background-size: 1px 1px; background-position: 0px calc(1em + 1px);">https://en.wikipedia.org/wiki/Merkle_tree
by @Ivan Shumkov
Based on the feedback received from the community following the "); background-size: 1px 1px; background-position: 0px calc(1em + 1px);">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 "); background-size: 1px 1px; background-position: 0px calc(1em + 1px);">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 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 "); background-size: 1px 1px; background-position: 0px calc(1em + 1px);">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…
- Propagate the state transition within a masternode quorum
- Validate it with the quorum according to platform consensus rules
- Record it on the blockchain
- Update the Platform State when the state transition is finalized (confirmed on the blockchain)
Comparison of Solutions
If we use the existing blockchain for state transitions, we are faced with some downsides:
- 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. - 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. - 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. - 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). - 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.
- Efficient Resource Usage
Running the Platform Chain exclusively on the masternode network reduces the overall network load and the size of the existing blockchain. - 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. - 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. - 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. - 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.
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 "); background-size: 1px 1px; background-position: 0px calc(1em + 1px);">https://blog.dash.org/an-introduction-to-dash-platform-dapi-and-drive-9d080d6e89c9
² Merkle Tree — "); background-size: 1px 1px; background-position: 0px calc(1em + 1px);">https://en.wikipedia.org/wiki/Merkle_tree