Release Highlights include: Identity v2 improvements, Headers first synchronization in JavaScript SDK, Porting DPP to Rust, a New Fee System, Same-block execution, Dashmate Improvements, Protocol Version Signaling, Decentralized API with HTTPS, Dash Network Deploy Tool updates

Dash Core Group is pleased to announce the release of Dash Platform v0.24 on testnet. The primary focus of this version was the introduction of the Rust port for the Dash Platform Protocol, which was originally implemented in JavaScript. Another major improvement is an implementation of same-block execution approach for Platform chain. This allows block commitment and signing within a single block, an improvement over the previous two-block system.

This version also includes two groundbreaking features to the blockchain industry: total balance verification and fee refunds. The total balance verification protects against inflationary bugs and attacks. It ensures that the total amount of Dash on Platform is always equals to the amount brought in minus the amount withdrawn. With this release, we’re also introducing an update to our state transition fee system, dividing fees into storage and processing components. Furthermore the implementation of decentralized identities on Dash Platform has seen numerous enhancements allowing more fine grained requests, lower storage and processing costs. 

As with our previous updates, v0.24 brings many other technical improvements. These touch on dependencies and Platform components such as the Dash Network Deploy tool, Tenderdash, Dashmate, GroveDB, and the JavaScript SDK. We would like to mention that the release notes for this update also encompass changes from Platform v0.23. Although it was never formally announced or launched on the testnet, its developments have been integrated into v0.24.

While this release of the Platform remains in the beta stage, the first component, Dashmate, is now fully prepared for mainnet nodes deployment. We recommend utilizing Dashmate to configure your first Evonet masternode.

Release Highlights

• Identities DIP11 Implementation In this release, we finished implementing the identity specification described in DIP11. Changes include adding an Identity Update State Transition, introducing an additional Identity key purpose for masternode payouts, and implementing an Identity key ownership proof.
• Identity Storage Optimization Previously, it was necessary to fetch all identity data when its balance changed due to a new state transition. This was slow and inconvenient, especially for identities with many keys and information. Platform v0.24 introduces Identity Trees, which make it possible to access balance or specific keys as needed, making the system much faster. Lastly, various tests and fixes have been implemented to improve the overall performance and reliability of the system. This improvement is a part of Identity v2 initiative.
• Total Credits Balance Verification To provide additional security and prevent the possibility of inflationary bugs, this version verifies all identity balances against the total number of credits created on Platform. This recently introduced GroveDB Sum Trees provide this industry-first capability.
• Headers First Synchronization in JavaScript SDK The new chain synchronization improves security and reliability in Dash SDK wallets. The SDK now supports SPV client capabilities – it performs full chain synchronization and verification by asking randomly selected masternodes to return blockchain data.
• Porting Dash Platform Protocol to Rust from Javascript Our long-term goal has always been to move to Rust for its performance and security advantages. Dash Platform Protocol, one of our core components, was ported to Rust and integrated into Platform for this release. We also created WASM bindings for the Rust DPP implementation and utilized them in our JS SDK. End users of the SDK shouldn’t notice any difference in how the SDK functions.
• New State Transition Fee Calculation As part of our revamped fee system, we have split state transition fees into two parts: storage fees and processing fees. Storage fees cover the cost of storing data created by state transitions, while processing fees compensate for CPU time and memory used during state transition execution. Fee calculations are based on the specific operations executed during state transition processing (i.e., signature verification, IO, hashing, etc.). Furthermore, a fee prediction validation process ensures identities have a sufficient balance to pay the state transition fees.
• State Transition Fee Distribution Fees are no longer centralized in a single pool. Instead, we have implemented a distributed fee allocation method that involves Evolution masternodes participating in consensus. The distribution is based on epochs (~18 days), which serve as intervals for fee allocation. Processing fees are distributed at the end of each epoch, while storage fees are allocated to epoch pools. Masternodes receive their share of storage fees from the epoch pools gradually over a period of 50 years. This new approach promotes decentralization and equitable compensation for masternodes throughout the extended timeframe.
• Fee Refunds Fee refunds are a standout feature that sets Dash Platform apart from others in the industry. In contrast to typical web3 systems, Platform offers users a refund when they delete stored data. When a document is deleted, users receive a refund of the storage fee they initially paid, with the deduction of credits already distributed to masternodes.
• Same-Block Execution Before this update, the execution process involved two blocks, with each block requiring a signature from the subsequent one. This approach introduced inefficiencies in storage and processing, as it necessitated an extra block to commit previous block changes, impacting space requirements, network throughput and state transition processing speed. It also required maintaining two state versions: one for the latest block and one for the previous block, since the newest block created the signature for the previous one. In this release, the state is updated and signed in the same block, mitigating the problems described above. This improvement was inspired by Tendermint, which is also working on implementing this capability.
• Dashmate Improvements We made many enhancements to dashmate in this release, including a reworked dashmate setup wizard that supports Evonode setup. Dashmate is now user-friendly, providing multiple install options (npm, Mac/Windows/Debian packages) and an HTTP API for interacting with dashmate programmatically. Numerous bug fixes have resulted in Improved stability also.
• Protocol Version Signaling Previously, we used feature flags, which functioned similarly to sporks, to upgrade the network protocol version. Using feature flags for network protocol version updates was a centralized solution that could never go to mainnet. Instead, as of v0.24, when an EvoNode owner updates Platform on their node it will automatically signal they have a new version. If the majority of masternodes signal support, the new version is locked in and activated at the end of the next epoch. This new approach is a significant improvement and removes a source of centralization from Platform.
• Decentralized API with HTTPS DAPI services now support HTTPS, enabling the development of web-based dApps. This feature is integrated into dashmate, offering developers and masternode operators several options. For local networks and testnet,  self-signed can be created, or you can specify your own certificate file. Dashmate also has integrated support for using ZeroSSL for automatic certificate generation and renewal. In the future, more providers will be added to provide a range of choices.
• Dash Platform Benchmark Suite This tool is designed to measure the performance of various components within Platform. Benchmark configurations can be created to insert the state transitions necessary to obtain metrics on Drive processing time. Additionally, the suite enables measurement of specific component functions allowing you to assess the performance of individual components such as DPP accurately.
• Dash Network Deploy Tool updates In collaboration with Dash Incubator, we have integrated dashmate to ensure an efficient deployment experience and remove duplicated functionality. This version includes improved smoke tests that cover a wider range of features, enhance performance, and strengthen reliability. Additionally, arm64 support was added to provide more infrastructure flexibility and reduce costs.

We encourage you to follow our Dash Platform Product Review right after the v0.24 testnet deployment. It summarizes the whole increment provided with that version and brings some use cases that are covered with these improvements.

What’s next?

Version 0.24 was a massive undertaking that we are all very proud of. For the last two or so months we got to a point where adding more people would not have sped up development. This is why we started parallel work on version 0.25. The most major difference between v0.24 and v0.25 is a rewrite of the block execution logic from Javascript to Rust. Having one part of the project in Javascript (Block Executor) and other parts in Rust (Protocol – Drive – GroveDB …) required an adapter called the Protocol WASM bindings. This adaptor was often a source of issues and was very time-consuming. 

Having the main Platform Application logic all in Rust is a major simplification of the application architecture and will accelerate the development pace going forward. It will also greatly reduce memory overhead and speed up state transition block processing allowing more transactions per second. We are confident that while this approach might have added more development work in the short term, the benefits will allow us to reach a stable Mainnet faster.

After this 0.24 release, our goal is to get a beta release of v0.25 out for internal and external developers to test and work on as soon as possible. This is why we are splitting the next release into three phases: v0.25.0-beta.1, v0.25.0-beta.2 and finally renaming it to v1.0.0-rc.1.

The first phase is estimated to be complete in approximately a week with a deliverable of a version to an open Devnet that we will make public, giving external developers the choice to try out this nightly version. Doing this is necessary to preserve our main testnet for testing the actual release upgrade process.

Here is a non-exhaustive list of more notable features that will be present in our Beta-1, all features in this list are done and in testing unless otherwise stated.

• Porting of Executor from Javascript to Rust: This was a major undertaking and was the second of the two major components that needed to be ported. While this is currently in testing, we ran this version on a Devnet that produced over 1000 blocks before we stopped the test. We are still in testing and fixing issues, but hope to be done shortly.
• New More Efficient Masternode List Synchronization: The previous masternode list synchronization was overly complex as it relied on light client synchronization logic, with the help of the Core team we now have a more efficient solution.
• Initialization on Core v20 Activation: Activation of Platform happens when v20.0 of Dash Core activates. This works both for mainnet and testnet.
• Efficient Data Serialization: Before data was serialized as CBOR which encoded keys as well as values, since keys are known based on versions this type of serialization was not efficient. We moved to Bincode serialization for all structures known at compile time and an even more efficient custom serialization for Documents (which is the bulk of storage).
• Non-unique Key Hashes: Storage of non unique key hashes that can be used for signing state transitions and for withdrawing from the system.
• Cryptographic Proofs: While we have long had some sort of cryptographic proofs, they were incomplete up till now. This is a major achievement that means that all data returned to light clients after a query will be proved.
• Client Side Verification Feature and Bindings: Verification of these proofs is simple through a drive sub feature (Beta-1). This also entails creation of bindings so platform proof verification is supported in multiple languages other than Rust. (C/iOS Beta-1 / Java-Javascript Beta-2).

In the second phase we will be reorganizing into two platform teams, one will be actively testing finished components while the other will be working on the following final features. These features are generally for items that are less important for developers but needed for the mainnet release, these are:

• Withdrawals Finalization: Withdrawals of Credits into Dash are close to being complete in Beta-1. Enough that they can be tested. However even though the transaction is created it is not yet redeemable in Dash Core. This feature will be complete in Beta-2.
• Versioning: A simple and comprehensive versioning scheme to allow for protocol upgrades for new efficient data structures is currently in the works. Without this, while the first system would work, it would be very difficult to upgrade. (Beta-2)
• Core Block Reward Processing: A part of the Core block reward will be sent to Platform to be distributed among Evo nodes as part of the incentivization mechanism. The distribution part is all done, but the receiving part still needs to be accomplished. (Beta-2)
• Data Contract Bounds: This will allow data contracts to specify that they require specialized keys for their usage. This feature will allow apps to query multiple keys efficiently by their identities for a given app. In Dashpay for example all “contacts” can be requested in one event instead of querying DAPI for each contact in a displayed list. (Beta-2)
• Masternode Voting: This will allow contracts to specify that specific documents can only be created by a key marked with a voting purpose field. This will enable a simple version of DAO governance contracts on Platform. (Beta-2)
• Fee System Finalization: Tweaking the parameters of fees based on data gathered. (Beta-2 / v1.0.0-rc1)
• Maybe) State Sync: State sync is a much more efficient way of transferring data between nodes. We are going to try to have this be a post Mainnet first release feature. However in our continued effort of transparency it is best to add here as there might be a possibility that we find out during testing that it would be required. (Maybe Beta-2)

To recap here is the updated rough timeline:

v0.25-beta.1 – Estimated 22th May Open Devnet – Start of testing phase.

v0.25-beta.2 – Mid June Testnet – Second period testing phase.

V1.0-RC-1 – Mid July testing phase over – Release candidate

Deployment and Testing

Platform v0.24 introduces several breaking changes which make previous Platform data invalid. Platform state data has hence been wiped. On the other hand, there have been no changes to the Dash Core Payment chain, ensuring the preservation of all historical payment transactions and blocks.

Please join us with testing the platform version v0.24 and setup your node for testnet. To update your existing node please update the distribution package and reset platform data.

We would like to thank all developers, testers, masternode owners and community participants who have made this release possible.

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.

Release Notes

• Dash Platform v0.24
• Dash Network Deploy Tool v0.24

Please note that the Dash Platform repository has been moved to the dashpay GitHub organization. All development and pull request activity can now be found at https://github.com/dashpay/platform. 

Authors:

Ivan Shumkov, Lead Platform Software Engineer

Samuel Westrich, Chief Technology Officer

ThePhez, Head of Documentation