Today I am very pleased to announce the release of Dash Evolution v1.0.0 and mark the turning of a new page in our project’s history. This release has been a culmination of a great many efforts over many years.

Features

Today’s release supports most of the core functionalities that we wanted for v1.0.0. It is occurring under an accelerated release schedule, and as such some features that we originally envisioned at release did not make it in. Most notably, balance withdrawals will not be active until the code is fully reviewed and tested, something we have not yet had time for. This had been previously communicated with the voting network that approved this plan. We estimate at this point that the next release enabling withdrawals will come out the Monday following the first distribution of credits which should be 9.125 days after activation.

Features that are supported in v1.0.0 include:

• Decentralized Identities (create, update, top up balance, credit transfer),
• Data Contract support (create, update, historical support, various mutability configurations),
• Document support (create, replace, delete),
• Document-based NFT basic support (transfer, sell),
• Dash Platform Name Serve (DPNS) contract,
• Dashpay contract,
• Verification of total system balance based on Sum Trees technology (a security measure),
• A fee system with fee refunds when removing data from system,
• Contested resource masternode vote resolution,
• Reward distribution to Evonodes,
• Protocol versioning support with hard fork upgrades,
• State transition execution cryptographic proofs,
• Platform State with efficient cryptographic proofs for light clients based on GroveDB (storage system) hierarchical authenticated data structures,
• A scalable byzantine fault tolerant consensus solution using threshold cryptography and same block execution,
• A GroveDB visualization tool that enables developers to see how their data is stored to properly optimize their data contracts.
• A decentralized API with 23 different Platform queries :
  • getIdentity: Fetches the identity details based on the provided request.
  • getIdentityKeys: Retrieves the keys associated with a specific identity.
  • getIdentitiesContractKeys: Obtains contract keys for multiple identities.
  • getIdentityNonce: Returns the nonce of a specified identity.
  • getIdentityContractNonce: Provides the contract nonce for a given identity.
  • getIdentityBalance: Retrieves the balance of a specified identity.
  • getIdentityBalanceAndRevision: Fetches both the balance and the revision number of an identity.
  • getDataContract: Fetches a specific data contract.
  • getDataContractHistory: Provides the history of data contract updates.
  • getDataContracts: Retrieves multiple data contracts based on the request.
  • getDocuments: Fetches documents based on the provided request.
  • getIdentityByPublicKeyHash: Retrieves an identity using a public key hash.
  • getConsensusParams: Returns the current consensus parameters.
  • getProtocolVersionUpgradeState: Fetches the state of protocol version upgrades.
  • getProtocolVersionUpgradeVoteStatus: Provides the vote status for an Evonode voting in a protocol version upgrade.
  • getEpochsInfo: Retrieves information about epochs.
  • getContestedResources: Lists the votes currently happening for specific contested resources.
  • getContestedResourceVoteState: Provides the state of a contested resource vote, including who is winning.
  • getContestedResourceVotersForIdentity: Retrieves information about who voted for a contested resource to be assigned to a specific identity.
  • getContestedResourceIdentityVotes: Fetches details on how a particular identity voted in contested resource votes.
  • getVotePollsByEndDate: Lists vote polls that are ending soon.
  • getPrefundedSpecializedBalance: Returns the prefunded specialized balance based on the request.
  • getPathElements: Provides direct GroveDB information path elements based on the provided request. This is for advanced usage only.
• 11 helper queries to get core chain based information :
  • getBlockchainStatus: Provides blockchain and network info for Payment blockchain
  • getMasternodeStatus (will be activated within first two weeks): Provides masternode status
  • getBlock (will be activated within first two weeks): Fetches a payment chain block
  • getBestBlockHeight: Fetches best chain tip height
  • broadcastTransaction: Broadcasts a payment chain transaction
  • getTransaction: Fetches a payment chain transaction with metadata
  • subscribeToBlockHeadersWithChainLocks: Data stream with historical and upcoming payment chain blocks and chain locks
  • subscribeToTransactionsWithProofs: Data stream with historical and upcoming transactions, merkel blocks and instant send locks filtered with specified bloom filter.
  • subscribeToMasternodeList: Data stream with historical and upcoming simplified masternode list diffs (DIP0004) 
  • getBestBlockHash: Fetches best chain tip hash
  • getBlockHash: Fetches a payment block hash by height

Stability

While the system has proven to be very secure thanks to innovations such as GroveDB sum trees and an acceptable amount of testing, the testing phase was cut slightly short for the purpose of getting a release out faster. It is expected that some issues may arise, mainly as a result of the differences between a smaller, DCG-controlled network (testnet) and a fully decentralized, global network, with more nodes than are used on a testnet, as well as some additional related nuances. To be clear this means that there is a likelihood of a chain stall on Mainnet in the first few months, but a close to non-existent chance of an attack that would cause money to be lost.

In addition, since we were testing up till the date of release we uncovered a few issues that might warrant a patch update within the upcoming weeks.

Dashpay and DPNS

We have decided to release Dashpay and Dash Platform Name Service in v1.0.0, two features that inspired the idea of creating Dash Evolution. That means that as soon as Platform activates, you will be able to get your Dash username.

In order to prevent early adopters of DPNS to capture all popular names, such as Coca-Cola, for the purpose of reselling at a higher value later, we have introduced a “contested usernames” system. A Dash username that contains only letters, 0s, 1s and hyphens is considered a contested username. In order to get a contested username, a user must submit to register a username and pay a 0.2 Dash fee. The fee does not guarantee that the user is awarded the name, but it allows them to try to get it. A two-week voting phase will then start where masternodes vote on who, if anyone, the name will be awarded to. Other contenders for the same username can only join in the first week of voting. Masternodes and Evonodes are both able to vote and each vote is weighted based on their collateral. Masternodes are weighted 1 for 1000 Dash, and Evonodes are weighted 4 for 4000 Dash. They can also vote to lock a name so that it is not awarded at all. Locked names will be unlockable for a higher fee in a future version of Evolution. It is expected that unless a user can prove that they are, for example, the actual Coca-Cola company, names like that should be withheld from being awarded until Coca-Cola actually comes around to get the name.

Examples of names that would be contested:

Sam, Slim-Shady, Coca-Cola, only1

Examples of names that are not contested:

Trekkie123, LEET02, T2T4, only2

0s and 1s are included in the contested usernames as all usernames have a normalized version to prevent phishing. For example: the usernames “lemon” and “1emon” can be made to look alike in certain fonts, which can be used for a phishing attack. A user that gets the username lemon makes it impossible for another user to get the username 1emon.

Minimal requirements

What are the minimal/recommended specifications for an Evonode?

We strongly recommend at least 4 CPUs or vCPUs at release. While it is possible that Evonode operators could get by with only 2 CPUs and 8GB of Ram, such a configuration will only work with light usage of Platform and you might see yourself missing a few payments if the chain gets any significant usage. If your configuration allows for easy updating we recommend starting with the recommended settings at release, then adjusting downwards or upwards depending on usage.

Installation

Documentation is provided here: https://docs.dash.org/en/stable/docs/user/masternodes/setup-evonode.html

We will also provide a tutorial for upgrading from an existing Core node in the next 24 hours.

Release can be found here: https://github.com/dashpay/platform/releases/tag/v1.0.1