Sirius 1.6 Protocol Upgrade

Description

The Sirius Release (rc/v1.6.0) features key enhancements like optimized consensus signature checks, multikey support for chain shards, and advanced voting in Governance v3, along with network repair capabilities and smarter contract processing altogether with VM v1.5 integration.

Background

The Sirius v1.6 release marks a significant update for MultiversX, undergoing the first governance voting process for a protocol release. It represents a succinct approach to the up and coming governance process of MultiversX, which will be introduced with this software upgrade as it can be depicted at point 6 from the release content. Detailed information about the governance voting process from v1.6 onwards will be made available at https://docs.multiversx.com.

Release Contents

1. Optimise Consensus Signature Check: A new feature that optimises CPU usage during consensus signature verification.

2. Refactor Resolvers: Solves technical debt by splitting the resolver component's functionality.

3. Multikey Support: Enables nodes to sign with multiple keys, requiring a multikey node for each chain shard.

4. PubKeyConverter Refactor: Improves error propagation and supports unique human-readable parts for sovereign shards.

5. Peers Rating Handler Fixes: Addresses bugs in the P2P peers rating system to enhance response efficiency.

6. Governance v3: Implements a new voting smart contract with features like MinQuorum, MinPassThreshold, and MaxDuration for proposals.

7. DNS v2: Introduces new functionalities like saveUserName and deleteUserName, accessible by whitelisted smart contracts.

8. WebSocket Outport Driver: Refactors the WebSocket driver for improved performance and versatility.

9. Sync Missing Trie Nodes: Enhances network repair capabilities by syncing missing trie nodes.

10. Balance Data Tries: Implements hash(key) storage for balanced data tries and introduces a migration function.

11. Sharded Persister: Adds the ability to split storers across multiple directories for improved data access.

12. Trie Sync Optimizations: Parallelizes the trie sync process for efficiency.

13. VM v1.5 Integration: Incorporates features like Multi-async and ManagedBigFloats in the smart contract processor.

14. State Package Refactor: Enhances code readability by restructuring account implementations.

15. Full Archive Refactor: Reworks full archive solution for optimised node connection and response cycles.

16. VM-query with Block Coordinates: Supports VM query execution based on specific block coordinates.

17. Logs & Events Changes: Improves intra-shard contract call tracking.

18. Transaction Execution Ordering Refactor: Enhances efficiency and accuracy in determining transaction execution order.

19. Several smaller features and fixes.

Testing and Testnets

The Sirius v1.6 release has undergone extensive testing, including end-to-end, integration, and differential tests. The public testnet is available for validators and builders to participate in a mainnet pre-release upgrade test. Link to public testnet: https://testnet-api.multiversx.com.

Read more about Sirius 1.6 Software Upgrade content: https://agora.multiversx.com/t/sirius-release-rc-v1-6-0/26

Read more about the Sirius 1.6 governance vote process: https://agora.multiversx.com/t/sirius-1-6-governance-vote-process/222

Frequently Asked Questions

What is governance?

Governance democratizes decision-making, enabling interest alignment for all parties participating by allowing them to have a say in the future directions of the protocol.

Who can vote?

Random snapshots of staked EGLD have been taken between 12.11 and 21.11. All users holding at least 1 staked EGLD at the time of the snapshot are eligible to vote.

IMPORTANT NOTE: The more staked EGLD you have during the snapshots period, the higher your voting power will be. Calculated as follows: the square root of the average staked EGLD, or √[(EGLD Staked S1 + ... + EGLD Staked S10)/10]; where S1 is the data from the first snapshot, and so on. For example, a user staking 100 EGLD without doing any restake/unstake action during the snapshots window will have 10 Governance Power.

How many days will the vote last?

The voting procedure for this proposal will span over 10 epochs from the 23.11 to the 03.12.

How will the votes be cast?

Here are the 4 available voting options:

• Yes - You agree that the MultiversX Protocol should be updated with this release.
• No - You disagree that the MultiversX Protocol should be updated with this release.
• Veto - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to MultiversX Protocol, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by MultiversX governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected.
• Abstain - will register your voting power as NEUTRAL to the switch - but even if it may seem unimportant, these votes actually help the proposal and thus put the power in the hands of the people who vote and care about the network. So we encourage users that don’t have a strong opinion to still vote, so that the decision for the proposal is made based on the governance votes rather than users who don’t bother.

How can the proposal pass?

In order for a proposal to pass it needs to pass: Simple majority is needed: more than 50% of votes should be UpVotes.