Release Highlights include: GroveDB, Verifiable Document Secondary Indices, Data Contract update, Masternode Identities, Inter-Validator Set Communication
The new release involves several breaking changes which make previous Platform data invalid. Therefore, previous Platform testnet state data has been wiped. The Layer 1 Core chain testnet remains untouched, keeping the history of test payment transactions.
To update your testnet node please update the distribution package and reset platform data.
- GroveDB – Hierarchical Authenticated Storage In the new version, the Platform team developed an innovative in-house solution to store the Platform state. Our previous prototype storage solution used four databases, two instances of both Merk and MongoDB in order to provide the functionality we needed. Having a four times replication of data was a deal-breaker and hence we had to build out GroveDB. GroveDB works by layering AVL Merkle-ized trees instead of having one big single tree as in Merk and also possesses functionality for building secondary indices. This hierarchical approach significantly reduces the size of the storage and cryptographic proofs, which are used to effectively prove data on light clients. The new database provides new operations that enable more complex, cryptographically verifiable queries, as can be done with other popular non-authenticated databases in the industry such as MySQL or MongoDB.
- Cryptographically Verifiable Document Secondary Indices Previously, Platform used MongoDB to allow DApps to query documents using document properties and document IDs. Since MongoDB doesn’t support cryptographic proofs for secondary indices, by using only MongoDB there would effectively have been no security. Prior to v0.22, we solved this by adding security through an authenticated database called Merk previously mentioned above. Merk however did not have the requirements to efficiently perform complex queries. This would mean that a malicious Masternode would have been able to return only some of the documents requested by a client, rather than the full set of valid documents that should have been returned, and the client would not have been able to know it. Platform v0.22 solves this issue with a completely new implementation of document secondary indices built on GroveDB.
- Data Contract Update Data Contracts define schemas for the data that represent a particular DApp state. In the previous versions of Platform, Data Contracts were immutable, like Smart Contracts in the Ethereum network. Now, developers can add new properties and define new document types in existing contracts – a feature that we believe will greatly simplify Dapp development.
- Masternode Identities To incentivise Masternode Owners to provide Platform services to the network, fees and block rewards will be distributed between participating nodes (feature coming in v0.23). In Platform, Identities represent accounts with balances. In order to receive payouts, each Masternode must have a Platform Identity. To be clear this Identity should not be tied to a user Identity. With the new version, Platform will automatically create an Identity for each masternode and will keep them up to date. Furthermore, Masternode owners can easily configure Layer 2 reward shares. In the next version of Platform, we are planning to implement distribution of rewards and the ability to withdraw Platform Credits to Dash from an Identity Credit balance.
- Identity Key Purpose And Security Levels In addition to balances, Identities hold asymmetric keys to prove ownership of operations (state transitions) performed on Dash Platform. The purpose of the keys is to authenticate the Identities. There is a need for a variety of security levels for authentication keys. What is more, some Identity keys are used for encryption and decryption. Starting with v0.22, Identities provide information to clients on which keys should be used for what purpose and inform to which degree of authentication would be required to adequately protect the private keys they hold. This functionality is fully described in DIP11.
- Inter-Validator Set Communication. In Platform v0.20, the Tenderdash team introduced optimization of the Peer-to-Peer layer. In the new version, to avoid missing consensus messages between validators, members of the active Validator Set establish direct connections between each other. Additional details can be found here.
Important note for developers: the Platform team reorganized the code base and code workflow in order to improve development speed. Most of the Platform components have been moved to one single mono-repository on GitHub.
We encourage you to come to watch and participate in our Dash Platform Product Review right after the v0.22 testnet deployment. There, our team will summarize the entire upgrade provided with the new version and present some use cases that are enabled by the new improvements.
Dash Platform teams are preparing for the last functional pre-mainnet release – Platform v0.23, which will introduce the Fee System, Masternode rewards distribution, Credit withdrawal transitions (enabling users to convert their Credits on the Platform chain to Dash on the Core chain), and some data serialization improvements handled by Dash Platform Protocol.
Big kudos to the community for their active and serious involvement in Platform development and testing – thanks to you we were able to deploy a significantly more stable testnet than the previous versions.
Follow the Dash blog and social media channels (especially Youtube) for more announcements and updates, and as usual – your thoughts, feedback, and suggestions are greatly appreciated.
Author: Maciej Sikora