Dash has a long history of innovation and development, with multiple significant products and features released over the years. Launched on 18 January 2014, Dash quickly developed new features focused on speed, privacy and usability, making it ideal for use as a digital currency. Built to deliver financial freedom and shape the future of payments for people around the world, Dash has an ambitious roadmap and proven history of delivery.
EVONET
EVONET
EVONET
TESTNET
TESTNET
TESTNET
TESTNET
TESTNET
TESTNET
TESTNET
TESTNET
TESTNET
TESTNET
Dash Core Activation
TESTNET
MAINNET
MAINNET
Last updated on 25-December-24
Dash was launched by Evan Duffield with the uniqueX11 hashing algorithm as its defining feature, and initial development focused on dynamic adjustment of mining difficulty, known asDark Gravity Wave. This was soon followed bymasternodes, providing a powerful and incentivized set of full nodes which form a backbone for the network and offer services to users.Sporks were released to help deliver a smooth release process of new features, without hard-forking the network, and finallyPrivateSend was released to make Dash a truly fungible currency.
While initially based on the Litecoin project, Dash rebased to Bitcoin in early 2015.InstantSend, a method of locking transactions secured using the second-layer masternode architecture, was released soon afterwards. Work continued throughout the year to build adecentralized governance system and release up to 10% of the block reward toproposals presented to the network. The first superblock was mined on 7 September 2015, making Dash the world’s first Decentralized Autonomous Organization (DAO).
Within 24 hours, the network completed a historic vote, reaching consensus to authorize developers to begin work on 2MB blocks, guaranteeing future capacity. Meanwhile, the hash rate multiplied rapidly as powerful mining hardware was released, increasing 16-fold over the course of the year. The management of the core team saw further professionalization and the introduction of quality assurance measures. Bitcore and Insight were released with Dash extensions, based on a network-funded effort to port the X11 hashing algorithm to JavaScript.
2017 saw Dash supported on major hardware wallets and two releases to optimize preparation of PrivateSend funds, and better manage the growing list of governance objects using a tool calledSentinel. Meanwhile, fees on all transactions were reduced by a factor 10 across the board, and ownership of Dash Core Group was transferred to an irrevocable trust, with the decentralized network itself named as beneficiary.
Named devnets allow for the creation of multiple independent devnets. Each one is identified by a name which is hardened into a “devnet genesis” block, automatically positioned at height 1.
Watchdogs have not been used since 0.12.2.x; instead, all required information about Sentinel is included in masternode pings. For this update, additional information was added to ensure that masternode pings weren’t changed by an intermediary node. All messages and logic related to watchdogs were removed. Improvements were made to the proposal message format and to proposal validation and processing, lowering network traffic and CPU usage. Handling of triggers was also improved.
Instead of requiring PrivateSend collateral to be N times the PrivateSend fee, any input which is greater than or equal to 1 PrivateSend fee (but less than or equal to 4) can now be used as collateral. Inputs greater than or equal to 1 PrivateSend fee but strictly less than 2 will be used as collateral with OP_RETURN outputs. This lowered the number of inputs a wallet needs to handle, and improved privacy by eliminating the case where a user accidentally merges small non-private inputs together. It also decreased global UTXO set size.
Android and iOS versions of DashWallet were updated with the new branding guidelines, modernizing the look and feel of both apps.
The ability to buy and sell Dash on Uphold through a web view within the Android app was also integrated, allowing for easier onboarding of users.
The ability to request a payment via NFC was added, allowing users to tap supporting payment terminals and wallets to receive payment information.
The ability to use DashWallet on iPad was added so users can pay and receive payments on their tablets.
Many new languages and currencies were added so that users all across the world can use DashWallet in their native language and view exchange rates in their local currencies.
Dash Core v0.13 introduced Automatic InstantSend, where transactions with four or less inputs will default to InstantSend, at no additional charge to users.
TheDeterministic Masternode List provides a single source of truth for all transactions requiring validation by masternodes, such as InstantSend transactions. The list is fully derived from on-chain data. This ensures all nodes will come to the same consensus regarding the current state of the valid masternode list.
Special Transactions provide new structures to enable non-financial transactions on the blockchain. This feature will lay the groundwork for future uses of the network on layer 2, like Blockchain Users.
Previously, masternodes had two keys for their masternode: owner (to prove ownership) and operator (to operate the masternode and use it to vote). The second key was broken into two: operator and voting, such that the masternode may delegate voting if they choose.
Users may now unlock their wallet using their fingerprint to allow for seamless use of the app.
DashWallet is now integrated with an iOS library that connects it to the Dash blockchain, and may in future be used by other iOS clients to do the same.
DashWallet can now confirm whether a received transaction was sent via InstantSend.
The price sources are now aligned between both the iOS and Android versions of DashWallet.
Long Living Masternode Quorums provide for increased scalability of the network by improving consensus and expanding the universe of potential use cases for the network. These quorums drastically reduce the amount of messages required to validate transactions, and avoid each individual node on the network having to store consensus data in-memory until a transaction is mined. These quorums can be very large depending on the level of security required for the use case.
ChainLocks drastically reduce the risk of a 51% mining attack on the network. This feature allows a Long Living Masternode Quorum to sign a block and propagate a message to the network indicating that nodes should reject blocks at the same height that do not match the block specified by the quorum. This not only makes reaching consensus quick and unambiguous, it also makes chain reorganizations below that block impossible.
Users may transfer Dash from their Uphold account to their wallet within the app, and buy and sell Dash through an embedded webview.
Improvements were made to ensure exchange rates align with other frequently used Dash applications.
Support for LLMQs and ChainLocks was added to the wallet, ensuring users would be able to benefit from added security and instantly respendable payments.
EVONET
Dash Platform will be released onto a public testnet that developers can connect to to experiment with the functionality.
Users will be able to connect to Evonet using the Decentralized API (DAPI); create test identities and names; and create, update and delete documents.
Users will get to explore the Dash Platform Naming Service (DPNS) and DashPay contract.
Several libraries will be available to developers, including the Dash SDK, DAPI-client, DPNS-client, and DPP libraries.
A developer hub will offer helpful documentation and guides to the new functionality.
DashWallet’s UI will be unified across Android and iOS for a more consistent look and feel.
DashWallet iOS will introduce a dark mode consistent with Apple’s guidelines.
Users will be offered more flexibility in how they manage their security settings.
Users will be able to quickly access key features from the home screen.
This release will bring Dash up to date with Bitcoin v0.15.2, benefiting from a number of fixes and optimizations made to Bitcoin up through that release.
Users will benefit from an updated UI on the desktop wallet to match the updated Dash branding. This includes updated colors and styles to match the style guide, removal of unnecessary elements to clean up the UI, and new icons.
This release will include several optimizations made based on the findings from the recent stress tests.
Improvements to the BIP70 feature allow for a more efficient payment experience at the point of sale. Users/Merchants that implement this protocol benefit from refund options, the ability to split payments to multiple addresses and will have a more secure experience.
The allocation of block rewards — excluding proposal funding — between masternodes and miners is changing from a 50–50 split to a 60–40 split over a multi-year transition period.
The Dash Core experience is now more consistent across all supported operating systems in regards to fonts, graphics and screen layouts.
The new signature recovery system initially sends signature shares to a single deterministically selected node, instead of propagating signature shares to every node until one has enough to recover the signature. This optimization is expected to reduce the load by several orders of magnitude.
Proof of Service (PoSe) for Masternodes is enhanced by ensuring a minimum protocol version is running during DKG.
Network threading has been optimized by eliminating unnecessary repetition of loops through all nodes by implementing event polling (epoll) on Linux.
This release also introduces over 650 updates from Bitcoin v0.16 as well as some updates from Bitcoin v0.17.
EVONET
Allows for the smooth rollout of breaking changes without wiping development networks.
Platform test suite is arepo containing consolidated tests across the platform, makes testing and updating tests much easier across all components.
Allows developers to use native binary types (e.g., Buffer, ByteArray) to store their data.
Ability to record the creation or update time of any document stored on Dash Platform.
Support for config templating and multiple nodes inmn-bootstrap.
Allows a user to specify a primary username for their Dash identity.
DIP11 Identities andDIP12 Dash Platform Name Service have been released.
The send and receive tabs were removed to create more space and to remove redundancy with the shortcut bar.
Labels were shortened and/or reformatted to avoid overlap with other UI components on small screens.
A back button was added, support for non-English phrases was implemented, warning messages were updated
Numerous fixes and changes to the core data design and the Masternode and quorum list downloads.
EVONET
The DashPay Alpha Program engages the community with DashPay wallet testing on Evonet.
Users will be able to register themselves on the network and start sharing their personalized usernames with other Dash users.
Users will be able to make their username more identifiable with a display name, picture and bio.
Users will be able to request contacts by username and create a list of users they want to transact with.
Users can exchange Dash with friends, family and merchants by username or cryptographic address.
TESTNET
Improvements to represent binary data as byte arrays as opposed to strings so data is stored more efficiently. JSON Schema has also been extended with the ‘byteArray’ keyword, thereby allowing developers to more easily define binary properties in their data contracts.
Several changes were made to the underlying structure comprising an identity within Dash Platform
This was a known bug that prevented many developers from successfully starting nodes on Evonet.
Establishing consensus between L1 and L2 chains based on the height of L1.
This allows identities to be funded by leveraging the speed of InstantSend.
Storage of data state in Merkle trees for use with light clients.
The distribution package (dashman f.k.a. mn-bootstrap) has been significantly updated in order to improve user experience and accommodate the new platform components.
Ability to fund identities without ability to double spend.
Further improvements were made to the chain sync process to prevent delays in sending payments.
Improvements were made to help users who have forgotten one or two words of their recovery phrase to still attempt to recover their wallet.
The UX associated to forgetting your PIN were implemented, updates were made to support a newer Android SDK (29), crashes associated to backing up to a file and importing a private key was made.
TESTNET
A special type of node that provides peer information to other nodes to improve scalability.
Improvements to address several possible attack vectors and for scalability on Mainnet.
Add more logs for better clarity and troubleshooting of Drive behavior.
Readable and informative messaging for proper error handling.
TESTNET
New quorum size to support asset lock special transactions.
Security improvements when core is interacting with platform.
Estimated 500+ backports from Bitcoin Core.
TESTNET
Implement the second part of Identity Funding design that includes ChainLock proofs to better support client proofs.
Enable deterministically specific logic on the network to allow bug fixes and to enable new functionality without wiping the data.
The mn-bootstrap local node doesn’t support chain locks and instant locks so we had to introduce fallback during development and on CI.
Improvements to Asset Lock Proofs (identity funding) to avoid duplicate logic and data it’s better to use Core which already implemented this logic and has all required data.
Remove insight as a dependency and transition functionality to DAPI to improve stability and to remove redundancy.
We continuously improve the Dash Platform distribution package (formerly known as mn-bootstrap) to make it more convenient and reliable. Since this version, we consider it mature enough to get a nice name and strongly encourage you to start using it to run testnet fullnodes and masternodes.
Slow builds and lack of available functionality in Travis CI significantly slowed down the development process. We migrated to Github Actions and implemented some caching tricks. New CI builds are much more flexible and running up to 10 times faster.
TESTNET
To archieve consensus on platform blockchain, a specific set of masternodes, called validators, verifies and signs blocks. Up to version 0.19, the validator set was static and hosted on nodes controlled by DCG. With version 0.20, Long-living Masternode Quorums (LLMQ) are used to dynamically distribute and rotate the validator set among all masternodes. This approach evenly distributes the load and makes the network much more secure and reliable.
Previously, clients needed to use trusted full nodes to ensure the validity and integrity of data retrieved from the platform network. In this version, DAPI provides efficient cryptographic proofs alongside the platform data, which enables light clients (e.g. mobile wallets) to securely interact with Dash Platform.
Validators previously used non-aggregated EdDSA signatures of the platform state cryptographic digest in order to provide cryptographic proofs and guarantee network consensus. The number and overall size of these signatures made proofs resource-intensive for light clients to use. In version 0.20, the BLS threshold signing mechanism is used to produce only one signature, which mobile wallets and other light clients can easily verify.
Previously, full nodes as well as validators relied on and verified all types of P2P messages. This means that full nodes also received network traffic containing messages only relevant to validators for achieving consensus. In the new version, full nodes no longer receive intermediate consensus messages produced by validators. Instead, validators produce only one message with a BLS threshold signature to propagate the resulting consensus decision to the remainder of the network. This heavily reduces network load as many messages no longer need to be propagated to full nodes, resulting in 99.5% less bandwidth usage.
Dash Platform now attaches additional metadata to DAPI responses, such as the current platform blockchain height, as well as the synchronized core blockchain height observed and agreed upon by all nodes participating in network consensus. Since the platform and core blockchains are asynchronous, platform uses this core height to ensure all platform nodes have a deterministic view of the core network state.
The new version of Dash Platform Protocol updates the JSON Schema specification used to define data contracts to the most recent 2020-12 version, and employs strict validation rules to prevent potential user errors in data contracts submitted to the network. A special regular expression engine is also employed to mitigate ReDoS attacks.
Previous versions of the JS Wallet library did not always receive all requested transactions and instantlock messages from DAPI during synchronization. This has been resolved in version 0.20.
The latest version of Dashmate contains 20 fixes and improvements. The most significant of these were designed to make setting up local development networks more convenient and reliable, as well as performance improvements and Windows support.
Integration of the Liquid Quick Exchange into the wallet to allow for the purchase of Dash with Visa credit cards from within the Dash Wallet.
Improvements to the deep link UX so that there is a seamless user experience between the newly released DashDirect app and other apps that use this protocol.
This aligns with a more common standard of input/output organization that provides for better anonymity.
UI improvements to better educate users of the importance of their passphrase and prevent users from taking screenshots of their phrase.
UI improvements to the status and backend changes to improve the performance of the sync.
Multiple bugs and UI improvements associated to Uphold, fingerprint authentication, UI navigation, and the auto-logout feature, and some code refactoring in preparation for the DashPay upgrade.
TESTNET
To simplify getting your friends and family on the Dash network, you can send them invitations so they have everything they need to create their own username.
As a brand new user who doesn’t have any Dash, an invitation will allow them to create their username right away without needing to wait to acquire Dash first.
TESTNET
Implementation of error codes and more descriptive messages so that client applications can handle them better and so bugs are easier to investigate.
At the moment, we store state in different merk trees which adds some overhead for memory and disk. It also requires very complex logic to ensure atomicity and to handle cross-database transactions which are not implemented. A new more robust, and secure state tree design will be defined.
As part of the new state tree design, MongoDB will be replaced.
Testnet will be updated to include nodes across multiple data centers to simulate real-world issues with latency and performance which could impact scaling.
An improved upgrade process will avoid the need to wipe L2 data allowing for safe transition between protocol versions.
TESTNET
The first of its kind, a hierarchical authenticated data structure (HADS) based database relying on an innovative provable data storage system. This will allow features not possible with any other database currently in existence. The first release will offer secondary indices and will hold cryptographic proofs for the integrity of stored content.
This allows contract schemas to be modified without data loss or the need to create a new contract. This is a clear and obvious differentiator between Dash and smart contract networks which do not have the ability to do this.
When a Masternode has a Dash Identity with a balance attached, the Masternode owner can receive rewards for their participation in Platform consensus. This gives an additional revenue stream for Masternode owners.
Future Dash Platform features will require various security levels. Performing a sale of a very valuable digital asset should require a very high-security level while publishing cat pictures probably would not. With this feature, users can keep the highest security level keys on their hardware wallet, yet perform less critical actions directly from their phone.
To speed up the development and build process, Platform components code was migrated from standalone repositories to one multi-package repository. This mono-repository approach significantly reduces routine operations that need to be done during development.
Improves the distribution of quorum load across masternodes while also expanding the security of InstantSend. This isaccomplished by only changing a subset of masternodes in a quorum during quorum member selection while also limiting the number of quorums each node is selected for at once.
Reduced the proposal fee from5 DASH to 1 DASH in order to make the governance system more accessible. This change was driven by a masternode approvedproposal.
Added aGovernance tab to allow Dash Core Qt users to access governance proposal details more easily.
Implemented anew special transaction and aspects ofDIP23 necessary to support the full enhanced hard fork mechanism to be released in the subsequent version of Dash Core.
Introduced deterministically verifiable InstantSend locks (DIP22) to better support the Platform identity system. This allows InstantSend transactions to be verified in the future rather than just ephemerally.
Backport completion for Bitcoin Core v0.18 increased from 83% to 86% and v0.19 completion increased from 41% to 53%. Additionally, 18% and 10% of backports were completed for v0.21 and v0.22 respectively.
Dash Core Group has officially engaged with a professional auditing firm to perform a security audit on the Core codebase.
TESTNET
Remove the functional gap regarding the specifications of DIP0011. This includes implementation of an Identity Update State Transition, the introduction of Identity Public Key security improvements, added functionality required for credit withdrawals, and the implementation of an Identity key-ownership proof.
An incentivizing fee model that will compensate Masternodes for processing and storage costs as well as prevent spam. The implementation of the new fee calculation system is based on the operations required to process state transitions and the amount of data it stores on the Masternode network. Although the storage fee calculation with the new model is precise, processing fees are still a subject for improvement. Fee refunds for deleting data will also be implemented in the upcoming version.
A system where Platform fees are collected in pools to be distributed to Masternodes over time. This design incentivizes Masternodes to continue hosting and to avoid letting their node go offline. State Transition storage fees are distributed to every Epoch (~18 days) up to 50 years in the future. When a new Epoch starts, Masternodes are getting rewards for providing service in the previous Epoch.
Platform credits are exchangeable for Dash. Masternodes will have an easy way to withdraw their Platform rewards.
Improved security and reliability for chain synchronization in Dash JS wallet. JS Wallet will become a real SPV client that performs full chain synchronization and verification by asking randomly-selected Masternodes to return the requested chain data.
To measure performance of Platform components, this version introduces a benchmark tool. This tool is deeply integrated with Platform blockchain runtime and provides convenient instruments for developers to experiment and track performance over time.
TESTNET
Porting DPP to Rust makes it more secure and performant. It will also make block processing faster. To integrate Rust DPP into JS components we provide WASM DPP. This is the first step towards porting Platform to Rust. JS was nice for experimenting and prototyping but now we need something more sustainable.
A limitation inherited from the Tendermint project on which our consensus engine was originally derived, block signatures only would sign the state of the previous block as well as all state transitions of the current block. Hence to get proven data from DAPI you would need to wait for the next block commitment. This was incompatible with our desired proof system and storage system. This improvement also significantly reduces the load on the network and decreases the time needed to insert data into Platform, resulting in better UX.
Currently, you can convert Dash to Platform Credits by creating or topping up an Identity. Credits are mainly used to pay state transition fees. Masternodes get their rewards for hosting Platform in Credits (block rewards and ST fees). Withdrawals allow Masternodes and other Identities to convert their Credits back to Dash.
Dash Platform Protocol (DPP) previously used the CBOR encoding mechanism that implements schemaless data serialization. Since all data on Platform is stored in predefined structures, there is no need to store structure information as well. By only storing values we dramatically reduce the size of serialized objects.
When a user adds data to Platform they pay for permanent storage. However, not all data stored in Platform must be permanent. Users can define in data contracts the ability for documents to be updated or removed. The introduction of fee refunds allows users to get credits back when they delete data.
An Identity consists of various data such as its balance and a collection of public keys used for various purposes and security levels. The new Identities storage implementation allows updating or fetching of only specific or multiple parts of Identity. This reduces state transition fees and the load on the network.
A new GroveDB sum trees feature allowed us to implement a protection mechanism against inflationary bugs on the blockchain. This feature added sums to nodes of a specific type of Merkle AVL tree. In this tree, root nodes hold the sum of all integer values in the tree. Any time a value is added, removed, or updated in a sum tree, every parent node and hence the root’s “sum value” is updated. The credit verification mechanism compares every block of all credit balances in the storage with the expected amount of credits in the system. This prevents inflationary attacks that would mint new credits or tokens outside of the predefined supply.
This is a component to enable future governance features on Platform.
From this version onwards, DAPI requests are served via HTTPS to allow for building applications for browsers.
A High Performance Masternode is a new type of Masternode which will be used to serve the network by participating in consensus on both the Dash Platform chain and the Dash Payment (Core) chain. In this system, the standard Masternode would continue serving only the Dash Payment chain. HPMN’s will have greater requirements than a standard Masternode such as 4k Dash collateral and higher performance specs as they would be running two chains instead of just one.
BLS signature library update for the new signature scheme for standards alignment and improved security.
Backports from Bitcoin Core from BTC v0.19/v0.20/v0.21/v0.22.
One of the goals for the v19 Hard Fork was to activate basic BLS scheme and start using it in various on-chain and p2p messages. The motivation behind this change is the need to be aligned with IETF standards. Unfortunately, a few edge cases were missed in our functional tests and were not caught on testnet either. v19 activation attempt on mainnet hit one of these edge cases and mainnet stopped producing blocks. As an intermediate solution v19.1.0 was released which delayed the start of the signaling for the v19 Hard Fork until June 14th.
To resolve these issues we had to rework the way BLS public keys are handled including the way they are serialized in the internal database. This made it incompatible with older versions of Dash Core, so a db migration path was implemented for all recent versions.
As a side-effect, the solution implemented to resolve v19 Hard Fork issues opened a path to simplify v19 migration for mobile wallets.
With previous implementation mobile wallets would have to convert 4k+ pubkeys at the v19 fork point and that can easily take 10-15 seconds if not more. Also, after the v19 Hard Fork, if a masternode list is requested from a block before the v19 Hard Fork, the operator keys were coming in basic BLS scheme, but the masternode merkleroot hash stored in coinbase transaction at that time was calculated with legacy BLS scheme. Hence it was impossible to verify the merkleroot hash.
To fix these issues a new field nVersion was introduced for every entry in mnlistdiff p2p message. This field indicates which BLS scheme should be used when deserialising the message – legacy or basic. nVersion of the mnlistdiff message itself will no longer indicate the scheme and must always be set to 1.
Recent changes to dsq and dstx messages allowed mobile clients that get masternode lists from mnlistdiff message to determine the masternode related to these messages because the proTxHash was used instead of the masternodeOutpoint. Once the v19 Hard Fork activates the signature of dsq and dstx messages will be based on the proTxHash which should make it possible for mobile clients to verify it.
Before this version ChainLocks were either enabled or disabled. Starting with this version it’s possible to set SPORK_19_CHAINLOCKS_ENABLED to a non-zero value to disable the signing of new ChainLocks while still enforcing the best known one.
TESTNET
Masternode block rewards will be split between normal Masternodes and High-Performance Masternodes (HPMN). The HPMN part will be accumulated in credits and distributed over time between nodes as incentivization to serve Platform. Nodes will get rewards every Epoch (~18 days) if they provide the services (propose new Platform blocks).
This is the addition of more finite processing fees and the adjustment/revisiting of existing numbers to make sure all costs are covered adequately and fees are calculated properly.
Test and improve protocol upgrade processes to optimize the implementation of breaking changes for different levels of the system.
Prepare Dash Platform for storing and maintaining Non-fungible tokens. While using Platform storage mechanism, provide a way to keep NFT data also on chain.
Implement metrics for Platform components required for network monitoring including further stress tests.
Security experiments and tests by DCG.
Stress tests are performed with a stress test suite on a dedicated network.
Prior to DashCore v20.0, 10% of block rewards were set aside for the Dash DAO treasury which funds development and other network efforts. Once the DashCore v20.0 hard fork goes into effect on mainnet, the treasury system allotment will increase to 20% of block rewards to align with theproposal approved in September. Miner and masternode rewards will change to 20% and 60% respectively upon activation of the change.
Sentinel functionality has been integrated directly into v20.0, so it will no longer be necessary for masternodes to run the standalone Sentinel application. Several RPC commands have been updated to prevent conflicts between DashCore v20.0 and existing Sentinel installs. It is recommended to remove or disable Sentinel after updating masternodes to v20.0.
Introduced a new type of special transaction, “Asset lock”, to support platform identity funding
The masternode reward reallocation (MN_RR) hard fork, first included in Dash Core v20, will be activated after v21 is adopted by masternodes. This hard fork enables the major feature included in this release: Masternode Reward Location Reallocation. The activation will also initiate the launch of the Dash Evolution Platform Chain.
Once the MN_RR hard fork activates, part of the masternode subsidy in the coinbase will be moved into the Credit Pool (i.e., to Platform) each time a block is mined. Evonodes will then receive a single reward per payment cycle on the Core chain – not rewards from four sequential blocks as in v19/v20. The remainder of evonode payments will be distributed by Platform from the credit pool. This is to incentivize evonodes to upgrade to Platform because only nodes running Platform can receive these reward payments.
Dash introduced sporks in 2014 as a way to provide smoother upgrade transitions than hard forks. While this innovation has been useful, the network has matured to a point where they are no longer necessary on mainnet due features like enhanced hard forks. Consequently, this version hardens all sporks on mainnet. Sporks remain in effect on all devnets and testnet; however, on mainnet, the value of all sporks are hard-coded to 0, or 1 for the SPORK_21_QUORUM_ALL_CONNECTED spork. These hardened values match the active values historically used on mainnet, so there is no change in the network’s functionality.
MAINNET
Various network experiments, revisiting codebase, preparations and potential bug fixes for mainnet release with tight collaboration with Dash Community (taking usage of Community projects utilizing Dash Platform).
The first mainnet roll out of Platform will be bundled with the roll out of Core v0.21. The Dash Network will be encouraged to complete their upgrades as soon as possible.
MAINNET
These versions were to ensure a successful activation under specific conditions that were being observed. These were a mandatory upgrade for all Evonode operators. Contrary to other activations this version will activate the Platform chain as soon as 67 Evonodes in the Genesis quorum have upgraded and are properly configured.
The release of the DashPay mobile wallets will allow users to upgrade from Dash Wallet and easily create contested and non-contested usernames, make username payments and allow Masternode owners to vote on username requests.
The maximum number of compressed block headers that can be requested at once has been increased from 2000 to 8000. This change is expected to reduce blockchain synchronization times for clients using compressed block headers since they will be able to obtain headers faster.
To reduce bandwidth usage, the DSQ message is broadcast using the inventory system instead of relaying to all connected peers. While this should reduce the bandwidth needs for all nodes, the effect will be most noticeable on highly connected masternodes.
Platform withdrawal processing has been updated to accept withdrawal transactions from more Platform quorums. Previously, transactions were only accepted if signed by one of the first two active quorums. With this change, withdrawals can be signed by any of the valid quorums.
To improve censorship resistance and mitigate network partitioning risks, Dash Core nodes connected to the onion network now aims to maintain at least two outbound onion connections and protect these connections from eviction. As a result of the low percentage of gossiped addresses being onion nodes, it was often the case where, unless you specify `onlynet=onion`, a node would rarely, if ever, establish any outbound onion connections. This change ensures that nodes accessing the onion network maintain a few onion connections. As a result, network messages will continue to propagate across the network even if non-onion IPv4 traffic is blocked, reducing the risk of partitioning. Note: only nodes connected to the onion network are affected by this update.
This supports the Platform PoSe system to ensure that Evonodes that are not providing sufficient service to the network are banned to incentivize the owner to address the underlying issue so they can effectively contribute and continue earning rewards.
Allows p2p connections to be encrypted with virtually zero overhead.
To help new nodes get in sync with the current state faster, state sync will replicate the state from other nodes instead of processing the entire blockchain.
This is to ensure that Evonodes that are not providing sufficient service to the network are banned to incentivize the owner to address the underlying issue so they can effectively contribute and continue earning rewards.
The IBC protocol provides a permissionless way for relaying data packets between blockchains, unlike most trusted bridging technologies, the security of IBC reduces to the security of the participating chains. The IBC application layer can be used to build a wide range of cross-chain applications, including but not limited to token transfers, interchain accounts (delegate calls between two chains), non-fungible token transfers and oracle data feeds.
German
Greek
Spanish
Filipino
French
Italian
Dutch
Polish
Portuguese (Brazil)
Russian
Vietnamese
Turkish
Ukrainian
Chinese (Simplified)
Korean
Japanese
Thai
Arabic
Persian