To ensure the consistency and integrity of data stored on Layer 2, all data is governed by the Dash Platform Protocol (DPP). Dash Platform Protocol describes serialization and validation rules for the platform's 3 core data structures: data contracts, documents, and state transitions. Each of these structures are briefly described below.
Dash Platform Protocol 0.22
A number of breaking changes were introduced in DPP 0.22. Details can be found in the GitHub release.
Dash Platform Protocol 0.21
A number of breaking changes were introduced in DPP 0.21. Details can be found in the GitHub release.
Dash Platform Protocol 0.20
This release updated to a newer version of JSON Schema (2020-12 spec) and also switched to a new regex module (Re2) for improved security. More details can be found in the GitHub release.
A data contract is a database schema that a developer needs to register with the platform in order to start using any decentralized storage functionality. Data contracts are described using the JSON Schema language and must follow some basic rules as described in the platform protocol repository. Contracts are serialized to binary form using CBOR.
Dash's data contracts support backwards-compatible modifications after their initial deployment unlike many smart contract based systems. This provides developers with additional flexibility when designing applications.
For additional detail, see the Data Contract explanation.
A document is an atomic entity used by the platform to store user-submitted data. It resembles the documents stored in a document-oriented DB (e.g. MongoDB). All documents must follow some specific rules that are defined by a generic document schema. Additionally, documents are always related to a particular application, so they must comply with the rules defined by the application’s data contract. Documents are submitted to the platform API (DAPI) by clients during their use of the application.
For additional detail, see the Document explanation.
A state transition represents a change made by a user to the application and platform states. It consists of:
- An array of documents, or
- One data contract
- The contract ID of the application to which the change is made
- The user's signature.
The user signature is made for the binary representation of the state transition using a private key associated with an identity. A state transition is constructed by a client-side library when the user creates documents and submits them to the platform API.
For additional detail, see the State Transition explanation.
Updated 5 months ago