{"id":70718,"date":"2019-10-17T22:22:51","date_gmt":"2019-10-17T22:22:51","guid":{"rendered":"https:\/\/wp.dash.org\/uncategorized\/introducing-the-platform-chain-2\/"},"modified":"2021-09-23T15:00:15","modified_gmt":"2021-09-23T15:00:15","slug":"introducing-the-platform-chain-2","status":"publish","type":"post","link":"https:\/\/wp.dash.org\/blog\/introducing-the-platform-chain-2\/","title":{"rendered":"Introducing the Platform Chain"},"content":{"rendered":"
Based on the feedback received from the community following the Dash Platform presentation<\/a> at Dash Convention Europe, we would like to share the rationale for introducing a separate Platform Chain.<\/p>\n As previously discussed in the Introduction to Dash Platform post<\/a>, Dash Platform is a technology stack (a set of services) for developing decentralized applications.<\/p>\n Initially, we will provide:<\/p>\n 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.<\/p>\n 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.<\/p>\n For example, let\u2019s assume we have a Dash Platform application, memo.dash, a decentralized Twitter clone and the Dash analog of https:\/\/memo.cash<\/a>. 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\u00b9 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\u2026<\/p>\n 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.<\/p>\n If we use the existing blockchain for state transitions, we are faced with some downsides:<\/p>\n If we introduce an additional blockchain for Dash Platform we solve those problems:<\/p>\n 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.<\/p>\n 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.<\/p>\n \u00b9 State Transition \u2014 see https:\/\/blog.dash.org\/an-introduction-to-dash-platform-dapi-and-drive-9d080d6e89c9<\/a><\/p>\n \u00b2 Merkle Tree \u2014 https:\/\/en.wikipedia.org\/wiki\/Merkle_tree<\/a><\/p>\nPlatform Overview<\/h2>\n
\n
\n
Comparison of Solutions<\/h2>\n
\n
<\/strong>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.<\/li>\n
<\/strong>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\u2019s 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.<\/li>\n
The verification of platform data for light clients (similar to SPV) is complex and inefficient. Let\u2019s go back to our example with memo.dash. As a client, in order to prove that memos exist in Platform State and weren\u2019t modified by a bad actor, you need to download block headers, merkle proofs and state transitions for each memo.<\/li>\n
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).<\/li>\n
<\/strong>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 \u2014 payments.<\/li>\n<\/ol>\n\n
<\/strong>Running the Platform Chain exclusively on the masternode network reduces the overall network load and the size of the existing blockchain.<\/li>\n
<\/strong>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.<\/li>\n
<\/strong>In order to make data verifiable for light clients, we store Platform State as a merkle forest (multi-level merkle trees\u00b2) 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\u2019t need to be concerned about blockchain data sharding and can simply keep the most recent blocks.<\/li>\n
<\/strong>Since it\u2019s a separate blockchain, we\u2019re 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\u2019t 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\u2019t necessary to handle blockchain reorgs.<\/li>\n
<\/strong>Introducing a separate blockchain decouples Dash Platform from the current Dash functionality and builds it as a second layer. The first layer doesn\u2019t know about the second one, so if something happens with the platform it won\u2019t affect the existing blockchain and its payment functionality.<\/li>\n<\/ol>\nConclusion<\/h2>\n
\n