Dash Introduces Document Binary Properties In v0.15

Dash Core Group announced the release of Dash Platform v0.15. “This is the 4th release in our newly defined process, and our 5th release overall, where observers of Dash’s development can expect new functionality delivered roughly every 6 weeks. In that regard, observers can expect the next release to arrive sometime between October 6–20,” a release said.

As usual, due to the breaking changes introduced in this release all data on Evonet has been wiped. Developers should make adjustments to their local setups to reflect this. Below you’ll find a list of the most important updates. You can view all of the updates in greater detail by visiting the release notes for each platform component, which are included in the last section of this article.

• Document Binary Properties: There are many instances where developers need to store binary data in their applications. Previously, they had to encode and store them as strings, which required additional space in platform state and increased state transition fees. Now, developers have the ability to define those binary fields directly in a data contract by specifying the `contentEncoding` keyword. This allows developers to use native binary types (e.g., Buffer, ByteArray) to store their data.
• Protocol Versioning: As Dash Platform evolves over time, it is likely that breaking changes will be introduced on the protocol level (i.e., hard forks). This would lead to various incompatibility issues between previously created data and new software versions, as well as different versions of clients and nodes participating in the same network. Previously, DCG developers would handle these situations by wiping data on Evonet and forcing developers to update platform software with each new release. While this approach is fine for early testing, it is not appropriate for testnet and mainnet. To handle different versions of data, nodes, and clients all working in coordination, DCG developers introduced versioning that allows for the smooth rollout of breaking changes without affecting user experience.
• DPNS Improvements: In anticipation of DCG publishing the Dash Platform Name Service (DPNS) DIP, the DPNS data contract was updated with several improvements, including a default name feature for Identity. Using the new `dashUniqueIdentityId` record type, a user can ensure that only one domain will be resolved by his Identity, thus designating a main or primary username to be used in a UI such as the DashPay wallet. When aliases are needed, the user can still register one or many domains with the `dashAliasIdentityId` record type.
• JS Wallet Library Refactoring: Previously, the JavaScript wallet library (wallet lib) relied on methods left over from the early Evolution prototype, most notably, the polling getUTXO method. This method was useful in order to get Dash Platform bootstrapped, but it was slow and introduced a DDoS attack vector on the network. It also lacked some privacy features, such as probabilistic filters. We deprecated this method some time ago, and in this release, it was completely removed. Now, wallet lib uses a Transactions stream with a bloom filter, similar to the current Dash wallet over p2p, but uses HTTP as a transport protocol instead of going directly from node to node. Consequently, transaction processing logic in wallet lib has been significantly simplified. This is an important step toward fully implementing the DAPI SPV protocol.
• Distribution Package Improvements: We’ve made many improvements to the Distribution Package in order to simplify masternode bootstrapping. Most significantly, it includes the following three features: Firstly, the complexity associated with managing environment configuration has been significantly reduced by introducing the `config` command and removing `.env` files. This allows for easy configuration management, like getting and setting values and switching between environments. Secondly, testing and development on a local, standalone node has been simplified due to the implementation of a configurable block miner. Now, due to this block miner, developers no longer need to mine blocks manually. Thirdly, initial setup is now smoother due to moving all data from the mounted directory to docker named volumes.
• Changes to DAPI Endpoints: In order to have more conventional naming among Platform API methods, we’ve introduced a couple of breaking changes to DAPI. The `sendTransaction` and `applyStateTransition` methods are now called `broadcastTransaction` and `broadcastStateTransition` respectively. We removed the Transaction Filter Stream gRPC service in favor of using only Core service for core chain related endpoints. Also, we removed the insecure `getUTXO` and `getAddressSummary` methods, thereby mitigating a potential attack vector for the platform.