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.
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.
- 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.
- 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.
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.
- 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.
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.
Ivan Shumkov, Lead Platform Software Engineer
Samuel Westrich, Chief Technology Officer
ThePhez, Head of Documentation