Waves 1.2 Malibu is out for Mainnet

TL;DR:

• starting with this release all major updates will have names along with version numbers, Malibu was chosen for this release
• one of the biggest updates in Waves Protocol history is rolling out for the mainnet
• network security was increased by adding VRF to the protocol
• the new script execution model reflects network growth and makes block generation process fairer
• new transaction types were added along with the new version of Ride language to improve users’ and developers’ experience

For a full list of improvements, see the documentation.

A new node release for Mainnet, including major changes to the protocol, has been made available in Waves’ GitHub repository. The new version is the biggest update to the Waves protocol in the last few years and accumulates a result of 11 months of development (the previous major protocol update was in September 2019).

The release is aiming to bring network security to the next level and significantly improve users’ and developers’ experience.

What is Malibu?

Waves Node updates always have had version numbers according to semantic versioning, but remembering numbers is not so easy. It is much easier to refer to a specific version by name, it allows avoiding communication difficulties. After hours of discussion, protocol developers decided to stick to beach names for releases and call this release Malibu, which is a well-known beach city in California. You can propose your ideas for the next release names mentioning Waves Protocol on Twitter.

Verifiable random functions (VRF)

One of the biggest improvements to the protocol is an addition of Verifiable random functions to make our LPoS algorithm resist to “stake grinding” attacks. WEP 8: “Adding VRF in Consensus” was proposed in October 2019 and describes all the motivation and implementation details.

Before VRF implementation it was theoretically possible to predict the next block producer and attack them with a denial of service preventing them from generating the block, hereby delaying the block production or choosing another validator favourable to attackers. The uniqueness and pseudo-randomness properties of the VRF are crucial in ensuring that generators cannot manipulate the block generation process to gain advantages.

The new script execution model

Over the last months, decentralized applications based on Waves protocol have grown and are currently thriving. Despite seeing growth in our userbase and transactions, for example, due to projects like Neutrino, the network has remained performant and transaction fees were stable, contrary to many other networks, thanks to a unique execution model with limited complexity and a non-Turing complete approach.

However, this approach also has a downside. At the moment users can send failed transactions without having to pay a fee. To validate these transactions, miners use resources without getting any profit. However, a large number of failed transactions can reduce the speed at which valid transactions hit the block.

This situation is unfair and WEP-9 “Accept transactions with failed script result“ was proposed to accept transactions with failed script results by debiting the fee from the sender of the transaction. The need for these changes has been described in this article.

With the new execution model scripts resulting in an error will be recorded to the blockchain. Errors can be caused by an exception with throw() function or false result, but if an exception was thrown before complexity 1000 was reached the transaction will remain free and will not be recorded to the blockchain.

Another important change is a new maximum complexity for @Verifier functions. Previously it was the same with @Callable functions and equal to 4000, however, with this update, @Verifier maximum complexity is reduced to 2000. It will not degrade developer experience, because since the Ride v3 release in September 2019 various business logic moved from verifiers to callables. As such, the maximum complexity for a @Verifier can be reduced.

This proposed change helps to make the network more robust and DDoS resistant, which is a required property for growth and adoption.

RIDE v4

With the new node release, the Ride standard library will be upgraded to Version 4, which includes many functions that were long requested by our community. The full list of changes and comparison with Ride v3 will be a subject for another article, but some of the features worth mentioning.

New execution results

Previously, calling a dApp’s function could only result in the transfer of tokens (up to 10) and recording/updating data to that dApp’s storage. In Ride version 4, you’ll be able to issue a token at the moment of calling a function and immediately send it! Functions also allow sponsorship, enabling for token, re-issue, and burn transactions.

Ethereum compatibility

One of the new functions is ecrecover which works the same as in Solidity. The function allows for deriving a public key from a message signed with ECDSA. It opens the door to new opportunities such as Ethereum transaction validation in Ride contracts and possible data validation, for example from Coinbase price data feeds.

New functions

We were constantly getting requests to enrich the standard library with functions to simplify work with List variable types. The new version of Ride introduces several handy functions to work with lists. New functions like indexOf, lastIndexOf, median, containsElement, makeString, min and max can help dApp developers to keep application design simple and secure.

Fair function complexities

Some long existing functions in Ride were changed too. Many function’s complexities were changed according to new benchmarks, leading to a more precise assessment of the resources spent.

For example, getInteger/getBoolean/getBinary/getString functions’ complexity was decreased from 100 to 10. In other cases, the complexity was increased, for example, for toBytes it was changed from 1 to 8.

Some of the functions also have new limitations for arguments. Existing network dApps were analyzed to align their limitations with common sense.

Ride has a number of functions connected to hashing, cryptography, and other relatively complex computations whose speed depends on the size of incoming data. We measured how significantly the function’s execution speed depends on the argument size and conclude that the difference could be several times slower. For instance, the execution of the function blake2b256(bytes: ByteVector) with a 128kb argument could be ~10 times slower than with a 16kb argument, although it’s the same function and the complexity value in Ride version 3 is always 10. The standard library for Ride version 4 has function families that differ by maximum argument size and complexity.

The argument’s maximum size equals the value in the function’s name. A full list of functions is available in the documentation.

Snarks stand for anonymity

zk-SNARK is a cryptographic primitive confirming knowledge of a specific data set (proofs) without disclosing the data itself. In Ride, a function family for zk-SNARK verification has arrived that uses the groth16 protocol — groth16verify and bn256groth16Verify. The functions work in a similar way but use different curves — an older and reliable BLS curve is used in groth16verify, while a new and constantly improving BN254 curve is under the hood of bn256groth16Verify.

Certainly, the most anticipated use of zk-SNARKs for Waves protocol is the possibility for anonymous transactions. The function family groth16verify will enable the implementation of a dApp that hides the sender. A prototype groth16verify is already available on GitHub, an example of bn256groth16Verify usage will be available soon.

New transaction type and simplifications

A new transaction type, “Update asset info transaction” enables updating the data for an issued token. A reissue transaction has been available in the protocol for some time, facilitating reissuance of a token or banning further re-issuance. However, it wasn’t possible to update a token’s name or description. Still, many projects might need to update their token’s name and description — for instance, in case of a change in a company’s name, domain (if mentioned in the description), or the sale of a company/brand. The reissue transaction will remain in the protocol, but the minimum fee will be reduced from 1 WAVES to 0.001 WAVES.

UpdateAssetInfo allows for updating the name and description of a token, but not more frequently than once per 100,000 blocks for the mainnet and 10 blocks for the Stagenet.

Minor changes aiming simplification for developers were made to issue, transfer, mass transfer, and data transactions, which you can find in the documentation.

User experience improvements

Transactions in Waves protocol go to the blockchain in less than 2.5 seconds (median and mean values), but in some edge cases, there were exceptions. The new release solves all issues related to transactions to guarantee the best possible user experience.

Previously, there were situations when dependent transactions could fail due to transaction handling process features. In some rare cases, the user could send 2 sequential transactions, receive a successful response from the node but after some time find out that the second transaction would not be recorded in the blockchain. In the new protocol version, UTX was reworked to improve user experience so that sequential transactions will work perfectly despite any chain reorganizations.

The average block generation time is 1 minute for the waves mainnet (microblocks are generated every ~3 seconds), but in practice, specific block time can vary from 5 seconds to a couple of minutes. Long blocks are generated to reach the target average time and could be harmful to the overall user experience since some services wait for a few block confirmations. To solve this issue the minimal block time was increased from 5 seconds to 15, while microblock time is remaining ~3 sec. The solution will align block times, while block confirmations will not take longer than expected.

Now that the Release is out, what can you do??

This article only covers major changes, to see the full list of changes please visit the documentation.

If you run a node you can download the release on Github, install and start voting for a new feature15 — “Ride V4, VRF, Protobuf, Failed transactions”. All changes will become available when the voting and activation protocol ends.

On Mainnet, every 10,000 blocks the node sums up the number of blocks with support for a feature. If a feature was supported in more than 80% of blocks during the last calculation period it becomes Approved. Otherwise, the voting continues and can take another voting period or more. Before an approved feature becomes Activated another 10000 blocks have to pass. This period is intended for the update of non-mining nodes to a new version.

Join Waves Developers Telegram group to discuss the release
Follow Waves Twitter
Watch Waves Youtube
Subscribe to Waves Subreddit