# Sirius Release - rc/v1.6.0

**URL:** <https://agora.multiversx.com/t/sirius-release-rc-v1-6-0/26>\
**Category:** Releases\
**Created:** [September 19, 2023, 8:58pm UTC](https://agora.multiversx.com/t/sirius-release-rc-v1-6-0/26 "2023-09-19T20:58:20Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![schimih](https://avatars.discourse-cdn.com/v4/letter/s/ecae2f/32.png) [@schimih](https://agora.multiversx.com/u/schimih)\
**Post date:** [September 19, 2023, 8:58pm UTC](https://agora.multiversx.com/t/sirius-release-rc-v1-6-0/26/1 "2023-09-19T20:58:20Z")

</div>

# Contents

This document explains the contents of the rc/v1.6.0 release codenamed Sirius. It is split in 3 sections:

- the **features** list containing detailed insights of the feature along with the external impact and the relevant pull requests list
- the **smaller features and fixes** area contains the one-pull request small features or fixes along with the external impact details
- the **merges** area contains the list of pull requests used to update feature branches as the work progressed on multiple areas at once. It is here for reference purposes only.

# Features

## 1. Optimise consensus signature check [#4467](https://github.com/multiversx/mx-chain-go/pull/4467)

A new feature optimizes CPU usage by changing how block signatures are verified during consensus. Previously, each signature share for block consensus proof was individually verified, costing about 3ms per signature. With ~400 signatures in the metachain block, this takes around 1.2s of CPU time per block, with an additional 200ms for the shards. The optimization involves assuming all signature shares are valid during aggregation and only verifying the aggregated result. This verification time was reduced to 3ms in a previous update (PR #4314). However, if an aggregated signature is invalid, it introduces an extra 3ms cost, as the leader will need to check each signature individually. To ensure consistent optimization, a penalty, termed ‘pseudo slashing’, will be imposed for submitting invalid signatures. This penalty involves an additional consensus message that provides proof of invalid signatures, which isn’t mandatory but, if sent, will allow nodes to temporarily blacklist misbehaving nodes. Blacklisted nodes will face dropped messages, rating drops, potential jailing, loss of block rewards/fees, and a waiting period before they can join consensus again.

**Full description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#1-optimise-consensus-signature-check-4467).

## 2. Refactor resolvers [#4692](https://github.com/multiversx/mx-chain-go/pull/4692)

This feature solves a technical debt by splitting the functionality of a resolver component in 2. The resolver component should be able only to respond to requests from the p2p network and the requester should be able only to request missing information (send the request packet on the p2p network)

**Full description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#2-refactor-resolvers-4692).

## 3. Multikey [#4741](https://github.com/multiversx/mx-chain-go/pull/4741)

This feature added multikey support that will enable the node to sign on behalf of more than one key. For it to function, a multikey node will be required for each shard of the chain (including the metachain) and the exact set of keys should be given to all the nodes. A detailed description of the feature is available [on the multikey docs page](https://docs.multiversx.com/validators/key-management/multikey-nodes)

**Full description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#3-multikey-4741).

## 4. PubKeyConverter refactor [#4716](https://github.com/multiversx/mx-chain-go/pull/4716)

The original implementation of the `PubkeyConverter.Encode` method did not propagate the error to its caller. Instead, it logged the error and returned an empty string. This behavior can be problematic as it might hide potential issues and security threats. Furthermore, the logger’s presence in the PubKeyConverter constructor became unnecessary, therefore the `hrp` was given as input, especially considering our vision for sovereign shards where each shard could have its unique human-readable part (`hrp`).

**Full description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#4-pubkeyconverter-refactor-4716).

## 5. Peers rating handler fixes [#4800](https://github.com/multiversx/mx-chain-go/pull/4800)

This feature solves several bugs in the p2p peers rating components that are used whenever a node will try to determine which p2p peers have a better response history to maximize the chance of receiving a response.

**Full description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#5-peers-rating-handler-fixes-4800).

## 6. Governance v3 [#4879](https://github.com/multiversx/mx-chain-go/pull/4879)

The voting smart contract is implemented in go, and it is running on the system VM alongside the other known contract (staking, auction, delegation). The voting contract currently does not have any enforcement, proposals are voted for to keep track of decisions.

`MinQuorum`, `MinPassThreshold`, `MinVetoThreshold` can be expressed in terms of either stake or voting power, the result is the same. We also have a `MaxDuration` - which is a maximum number of epochs a proposal can run. This prevents users from locking their tokens in the Governance contract for a very long time if the proposal is made incorrectly or malicious with a very high duration; a `ProposalFee` - to prevent spam (when more community addresses are whitelisted or the governance becomes completely open);

Once a proposal gets registered and the proposal fee is paid - the voting can start from the start vote nonce until the end vote nonce. After the `EndVotePeriod` any whitelisted address can send one more transaction in order to close the proposal - at that time it will be calculated if the proposal is voted or not. With that transaction all the votes for that selected proposal will be deleted from the trie. For every valid vote there will be a new entrance created in the trie with the key: `proposal+callerAddress`. These will be deleted when a proposal is finished. `ProposalFinish` call will clean all the storage and only after will set the proposal to the computed state - passed or not. Same proposal (“GitHub commit”) cannot be set more than once.

To deploy a proposal, one might use the transaction data field formatted as:

```auto
proposal@<githubcommithash(40bytes as hex)>@startVoteEpoch@endVoteEpoch

```

ProposalCost: 1000eGLD

User makes a transaction with `vote@<proposalX>@<VoteType>`: The governance contract will ask the staking, validator and delegation contracts how much stake/delegated eGLD he has. From the staked/delegated eGLD we compute the voting power using the quadratic formula.

The governance contract will compute the gas according to the number of storage GETS he needs to do to compute the voting power for each user. The user does not need to provide how much eGLD he staked/delegated, the governance contract will resolve this.

For contracts like MultiversX Community Delegation, Liquid Staking contracts, we made a new endpoint called `delegateVote@<proposalX>@<VoteType>@<delegateTo>@<balanceToVote>`

First we compute the total staked/delegated for that contract, compute if the `totalVoted += balanceToVote < totalStaked` for the contract. We assign the votes to the user the contract have delegated, recomputing the user’s voting power with the quadratic formula.

**Full description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#6-governance-v3-4879).

## 7. DNS v2 [#5045](https://github.com/multiversx/mx-chain-go/pull/5045)

Integrated new DNS functionalities:

- `saveUserName` can be called multiple times, and it will change the current username of the user
- `deleteUserName` will delete the username of the user Both endpoints can be called only by special/whitelisted smart contracts.

**Full description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#7-dns-v2-5045).

## 8. WebSocket outport driver [#5142](https://github.com/multiversx/mx-chain-go/pull/5142)

Refactored the WebSocket driver. The new drivers now support sending messages marshaled with json marshaller or the gogo proto marshalled. The new WebSocketHost implementation can run in server or client mode. A detailed description of the feature is available [on the indexer docs page](https://docs.multiversx.com/sdk-and-tools/indexer)

**Full description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#8-websocket-outport-driver-5142).

## 9. Sync missing trie nodes [#4616](https://github.com/multiversx/mx-chain-go/pull/4616)

If there was a bug during processing and a trie node was missing (either because it was deleted or because it was never saved in the first place), that validator would have not been able to move forward with block processing. When a missing trie node is reached, sync it from the network. In this way, the network nodes will be able to repair themselves.

**Full description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#9-sync-missing-trie-nodes-4616).

## 10. Balance data tries [#4636](https://github.com/multiversx/mx-chain-go/pull/4636)

The keys where the values are saved in a data trie are not random. Because of this, the data tries are not balanced, thus resulting in more intermediary nodes. When saving some data in the data trie, do not save at `key` but rather at `hash(key)`. This way, the keys will be random, resulting in balanced data tries. In order for this change to be backwards compatible, add Version field to trie nodes. Nodes that are accessed will be automatically migrated to the new version (where the storage key is hash(key)) Added a builtin function that will migrate data trie nodes when it is called. Added a new API endpoint which will return true if the data trie of a specified account is fully migrated.

**Full description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#10-balance-data-tries-4636).

## 11. Sharded persister [#5010](https://github.com/multiversx/mx-chain-go/pull/5010)

Added the possibility to split a storer among more than one directory, each having its own level DB instance. The keys are routed in their respective data shard in the same manner as wallet addresses are split among chain shards. The number of data shards is configurable and backward compatible as the information is saved in a file, in the same directory where the data shards reside. This split will improve data access, especially when dealing with state trie nodes.

**Full description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#11-sharded-persister-5010).

## 12. Trie sync optimizations [#5291](https://github.com/multiversx/mx-chain-go/pull/5291)

Improved trie sync process with parallelization. This is achieved by syncing the main trie and data tries in parallel.

**Full description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#12-trie-sync-optimizations-5291).

## 13. VM v1.5 [#4789](https://github.com/multiversx/mx-chain-go/pull/4789)

This feature integrates the VM v1.5 and the smart contract processor v2. The following set of features will become available: Multi-async on a single level, ManagedBigFloats, ManagedMap, BackTransfers.

**Full description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#13-vm-v15-4789).

## 14. State package refactor [#5334](https://github.com/multiversx/mx-chain-go/pull/5334)

Moved the accounts implementations in their own package. Removed duplicated code and increased code readability.

**Full Description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#14-state-package-refactor-5334).

## 15. Full archive refactor [#5345](https://github.com/multiversx/mx-chain-go/pull/5345)

This feature is a complete refactoring for the full archive solution. The old solution was based on the idea that full archive nodes would still connect on the p2p network by overriding the sharding counters but in practice, it did not perform well. This new solution relies on a secondary, optional p2p network on which only the full archive nodes will join. Since this network will mostly contain full archive nodes, the connection between the nodes and the request-response cycles will be optimized.

**Full Description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#15-full-archive-refactor-5345).

## 16. VM-query with block coordinates [#5512](https://github.com/multiversx/mx-chain-go/pull/5512)

Added support for vm query execution on the chain state at the provided block nonce and block hash.

**Full Description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#16-vm-query-with-block-coordinates-5512).

## 17. Logs & events changes [#5490](https://github.com/multiversx/mx-chain-go/pull/5490)

Currently, we do not have information of how ONE contract calls another contract intra-shard. All we have are token operations. Intra-shard token operations are taken from log/events on ESDTTransfer/ESDTNFTTransfer/MultiESDTNFTTransfer and transferValueOnly log/events. So we do not know whether one contract calls another using ExecuteOnDest/ExecuteOnSame/AsyncCall or what function and how it is called (if there are logs generated by the underlying SC then we know - but that is not standard).

**Full Description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#17-logs--events-changes-5490).

## 18. Transaction execution ordering refactor [#4918](https://github.com/multiversx/mx-chain-go/pull/4918)

The grouping of transactions in the block give precedence to source and destination shards (transactions are grouped into miniblocks, by the sender and destination shards, each miniblock having only one shard as source for the transactions inside (sender shard) and one shard as destination for the transactions inside (destination shard)). This is useful for the cross shard interactions to be optimized and correctly tracked by the metachain nodes, but does not provide details about the transactions execution order.

Currently, the transactions execution order is re-computed after the actual execution and fed into the outport driver, which serves clients such as indexers or notifiers. In some cases, e.g. multiple smart contract results generated by the same transaction, that need to be executed cross shard in the same destination shard, the execution order for these individual SCRs cannot be correctly determined after execution and all will be treated as a batch and receive the same order.

The execution order of SCRs is currently estimated (post-processing) rather than taken from execution, which makes it less efficient and in some cases is more prone to errors. The SCRs ordering will also become available from the execution component directly, together with the execution order of the other transactions and integrate the ordering into the outport driver.

This feature creates an ordered collection component that can be used during the transactions execution and collect the transactions and SCRs in their correct execution order. This feature introduces this component and its integration.

**Full Description** [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#18-transaction-execution-ordering-refactor-4918).

## Smaller features and fixes can be found [here](https://github.com/multiversx/mx-specs/blob/main/releases/protocol/release-specs-v1.6.0-Sirius.md#smaller-features-or-fixes)

---

<div class="post-metadata">

**Author:** ![drmelone](https://dub1.discourse-cdn.com/flex005/user_avatar/agora.multiversx.com/drmelone/32/20_2.png) [@drmelone](https://agora.multiversx.com/u/drmelone)\
**Post date:** [September 27, 2023, 9:00pm UTC](https://agora.multiversx.com/t/sirius-release-rc-v1-6-0/26/2 "2023-09-27T21:00:07Z")

</div>

What was the reason to limit the usage of the DNS v2 functions to only whitelisted smart contracts?

---

<div class="post-metadata">

**Author:** ![robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@robert](https://agora.multiversx.com/u/robert)\
**Post date:** [September 28, 2023, 8:40am UTC](https://agora.multiversx.com/t/sirius-release-rc-v1-6-0/26/3 "2023-09-28T08:40:35Z")

</div>

DNS v2 will come with a full subscription and auction model for usernames. It is easier to handle this inside one SC. Since mainnet release we did important optimizations on SC processing, consensus, tokenizations and more. Thus one base DNS marketplace SC is enough to handle all the load we forecast the DNS will have.

---

<div class="post-metadata">

**Author:** ![michael](https://dub1.discourse-cdn.com/flex005/user_avatar/agora.multiversx.com/michael/32/17_2.png) [@michael](https://agora.multiversx.com/u/michael)\
**Post date:** [September 28, 2023, 9:55am UTC](https://agora.multiversx.com/t/sirius-release-rc-v1-6-0/26/4 "2023-09-28T09:55:58Z")

</div>

What about multiple DNS ownership by 1 wallet address ? Is that possible and if so can it be traded using that SC like an NFT on a marketplace or would it require middlemen to handle the trades ?

---

<div class="post-metadata">

**Author:** ![robert](https://avatars.discourse-cdn.com/v4/letter/r/e95f7d/32.png) [@robert](https://agora.multiversx.com/u/robert)\
**Post date:** [September 28, 2023, 10:13am UTC](https://agora.multiversx.com/t/sirius-release-rc-v1-6-0/26/5 "2023-09-28T10:13:25Z")

</div>

The DNS v2 marketplace contract allows ownership of multiple addresses, one primary can set as herotag. Also ownership is represented by an NFT, so they can be directly used in marketplaces.

---

<div class="post-metadata">

**Author:** ![eddie](https://avatars.discourse-cdn.com/v4/letter/e/f07891/32.png) [@eddie](https://agora.multiversx.com/u/eddie)\
**Post date:** [September 29, 2023, 12:41pm UTC](https://agora.multiversx.com/t/sirius-release-rc-v1-6-0/26/6 "2023-09-29T12:41:50Z")

</div>

Tested multi key feature. This will be a big one!  
Thinking about the shuffling, resynchronization when changing shards… network traffic will most likely see a healthy decrease (at epoch change, etc).

Can’t wait to “spend” my xEGLD on devnet proposals!  
Will there be a UI for governance?

DNS v2 - another huge one! Same question as above… any UI ?

Trie sync optimizations are ALWAYS welcome! Also the signature check improvement!

⌛🙂