Update release for Waves protocol

The improvements offer new opportunities for dApp development on Waves, also enabling the implementation of interchain functionality.

The release has already been published on the Stagenet. The update’s main improvements include:

– The ecrecover function, implementing an algorithm for ECDSA signature validation

– New methods for working with lists in the Ride programming language

– SponsorFee for setting up a sponsored asset in Ride

– Extension of the wavesBalance function in Ride.

Support of ECDSA algorithm

Since the release of the Ride programming language, it has had the sigVerify function, facilitating the validation of signing data with a private key. For instance, this function was often used in Verifier dApp smart contracts and in MultiSig smart contracts.

A signature is formed based on an elliptic curve, meaning that if a certain type of elliptic curve is not supported by the protocol, it cannot be validated. Previously, only the function sigVerify was used for signature validation, which worked solely for Waves’ native elliptic curve, ED25519.

Upon release 1.2.5, data on a public key used for singing with the ECDSA algorithm, can be obtained directly within a smart contract written in Ride:

ecrecover(messageHash: ByteVector, signature: ByteVector) : ByteVector

Thanks to this functionality, the Waves protocol can be integrated in apps on other blockchain platforms, built on the secp256k1 curve.

Upon the release of this update, a data signature made on the Ethereum blockchain can be validated within a smart contract on Waves. This functionality can be used, for instance, for building interchain oracles.

Ride’s collection of cryptographic functions continues to expand. The ECDSA signature validation function comes as an addition to the hashing and RSA signature validation functions, as well as the zkSNARK support function added in the previous update.

Expansion of list functionality in Ride

Ride is a non-Turing complete programming language, as it doesn’t have standard cycles and recursions, which enables the evaluation of code complexity and compliance with a limit before execution. Thanks to this feature, fees on Waves are non-linear: before sending a transaction, a user knows what amount of WAVES needs to be attached as a fee.

However, this feature creates restrictions on using lists. Therefore, the new release features six new methods for working with lists, which makes using data arrays more convenient:

• indexOf/lastIndexOf — determining an element’s location inside an array
• containsElement — determining the fact of an element’s presence on a list
• min/max — determining the minimum/maximum element of a list
• makeString — transforming a list into a line by a divider.

These functions are well known to classical app developers, and they operate the same way as their alternatives in standard programming languages.

Examples of using the new methods are available here.

Receiving account balance in WAVES

Thanks to the update, the function wavesBalance will return BalanceDetails. BalanceDetails includes four Integer-type attributes:

• regular is the number of WAVES tokens that belong to an account
• available is the available balance, or the number of WAVES owned by an account, minus those which the owner leased out
• effective is the number of WAVES tokens that other users leased to an account added to its available balance
• generating is the minimum value of the previous attribute over the last 1,000, used in the PoS algorithm.

This functionality enables more efficient work with a user’s account and precise evaluation of its balance. Moreover, this update is a major step towards dApp for stakers, facilitating tracking their balances.

Other improvements

Several other improvements are aimed at making the dApp development process more convenient.

Waves has the mechanics for sponsored transactions, which enables paying fees with assets other than WAVES. Thanks to the new release, it is now possible to set up the sponsored token functionality with the function SponsorFee. At its invocation, it is sufficient to indicate AssetId and a new value for minSponsorAssetFee.

To make life easier for developers, alongside this improvement we also reduce the sponsored transaction fee from 1 WAVES to 0.001 WAVES.

In addition, it is now possible to receive extra information on a token within a smart contract invocation, using the function assetInfo, which now returns token data as an Asset structure, including the fields id: ByteVector, name: String, description: String, quantity: Int, decimals: Int, issuer: Address, issuerPublicKey: ByteVector, reissuable: Boolean, scripted: Boolean, minSponsoredFee: Int|Unit. All of these data can be used in a smart contract algorithm on Ride.

An example of the assetInfo function invocation is available here.

A complete list of improvements and their detailed descriptions are available in the documentation. You can also check out the update on GitHub.The improvements can already be used for developing dApp and testing them on the Stagenet. The update will be available on the Mainnet over the next few months.

For the Stagenet operation, we suggest the following tools:

– Stagenet Explorer — https://stagenet.wavesexplorer.com/

– IDE with support for Ride V4 — https://ide-stagenet.wavesexplorer.com/

– Node API — https://nodes-stagenet.wavesnodes.com/

Read Waves News channel
Follow Waves Twitter
Watch Waves Youtube
Subscribe to Waves Subreddit