We are pleased to announce that we have released a new version upgrade of our Sirius Chain on the testnet to address a few issues. These issues include deadlock resolution, decentralized exchange stability, and the synchronization process. To be in line with the Sirius Chain upgrade, we have also updated the software development kit library for storage nodes. Finally, the Sirius Supercontract is now released as an entirely new layer on the testnet.
The following are the release notes.
|Sirius Supercontracts (merged with Storage)||0.7.0|
Sirius Chain – 0.6.2
The previous Sirius Chain testnet upgrade introduced a fully functioning decentralized exchange engine. This release includes stability fixes for offer transactions. Included also are additional plugins and improvements such as Sirius Supercontract (SC) support, improved block difficulty calculation, aggregated transaction improvements, cache and synchronization fixes, and a flexible configuration property holder.
|Reworked block difficulty calculation.|
|Improved config holder implementation.|
|Fixed exchange patricia tree and several bugs in exchange plugin.|
|Updated cache height on rolling back blocks.|
|Fixed deadlock in node selection.|
To set up the latest Sirius Chain node and participate in test network, follow the onboarding guide available here.
Sirius Storage and Supercontracts – 0.7.0
The new storage release has added in more stability features and support for Supercontracts. We have extended external functions for WasmVM, which allows storage nodes to act as executor nodes using WasmVM. The built-in command line interface for the storage nodes are now extended to include Supercontract CLI Other releases include stability patches for DFMS Supercontract features, and WasmVM function Sirius Chain getters and setters.
|Integrate a new system to process events from blockchain sequentially.|
|Supercontract extended to include VM function logic.|
|Create & Delete File Tx for VM.|
|Deactivate SC by Owner.|
|Deactivate SC CLI for Client.|
|Supercontact code execution result handler implementation.|
|Supercontract code approval to execute implementation.|
|Supercontract code download handler.|
|Supercontract core consensus.|
|Constructor VM function.|
|Deploy CLI should return SC ID.|
|CLI: get SC execution results by Tx ID.|
|CLI to get all execution hashes for specific Supercontract.|
|CLI to getSC statuses and information.|
Sirius Supercontract is our unique digital smart contract code execution system. Current smart contract solutions utilize source code that can be written according to business logic, an execution environment, and a blockchain dependency. Our Supercontract takes it further by leveraging on our storage layer which uses a replication scheme to distribute the contract evenly. Contracts not only make use of distributed machines to execute program code but they also help blockchain nodes to save on memory and compute power, thereby maintaining the performance of the blockchain.
In this release, developers will be able to write their contracts using any programming language that can generate code in web assembly text. ( *.wat ). The wat file will then be uploaded to storage and executed using the Supercontract SDK.
We have developed a few examples for Rust which can be found here:
To learn more about Supercontract usage, go to our developer portal here.
In Sirius Chain, there are two main types of upgrades: software; and configuration. This new test network upgrade will have both. It begins with the Sirius Chain where an upgrade transaction (via upgrade mechanism) will be launched by the team that will change the native configuration.
The height data there is when the upgrade will happen (at height: 1299863).
The nodes need to be upgraded before the specified height in order for it to continue to validate blocks. It should be emphasized that there will not be any changes to the node reputation during this process.
If in fact, a node fails to upgrade before the height, it won’t be able to validate new blocks and therefore won’t be able to participate further. Note that node owners can still upgrade even after the designated upgrade height by following the same onboarding instructions found here: https://github.com/proximax-storage/xpx-testnet-chain-onboarding (pull new docker and run).
Once the test network has agreed on this new upgrade, the storage and Supercontract will be upgraded accordingly.
Actions needed to be taken by the ProximaX Team:
- Launch the upgrade mechanism transaction.
- Upgrade Sirius Chain nodes to 0.6.2.
- Launch Sirius Storage and Supercontract nodes version 0.7.0.
Actions needed to be taken by the community / external contributors:
- Upgrade Sirius Chain nodes to 0.6.2.
- Interested participants can launch their Sirius Storage Drive, Replicator and Executor nodes using the storage onboarding guide below.
For more information, visit our Helpdesk.