Developer Center

Developer Center

  • Getting Started
  • Built-in Features
  • REST API Endpoints
  • Guides
  • Cheat Sheet

›Protocol

Getting Started

  • What is Sirius Chain
  • Setting up your workstation
  • Writing your first application

Built-in Features

  • Account
  • Mosaic (SDA)
  • Namespace
  • Transfer Transaction
  • Aggregate Transaction
  • Multisig Account
  • Metadata
  • Account Restriction
  • Cross-Chain Swaps
  • Exchange Market
  • Decentralized Exchange Market
  • Liquidity Provider
  • Storage

Protocol

  • Node
  • Block
  • Cryptography
  • Transaction
  • Validating
  • Consensus Algorithms
  • Receipt
  • Inflation

REST API

  • Overview
  • Tools
  • Serialization
  • Websockets
  • Status Errors

SDKs

  • Overview
  • Architecture
  • Languages
  • Extending Sirius Chain Capabilities
  • SDK Development
  • SDK Documentation

Wallets & Explorers

  • Wallets & Explorers

Cheat Sheet

  • Sirius Chain Cheat Sheet

Guides

  • Overview
  • External Guides
  • Account

    • Creating and opening an account
    • Getting account information
    • Getting the amount of XPX sent to an account
    • Reading transactions from an account

    Account Restriction

    • Preventing spam attacks with account restrictions

    Aggregate Transaction

    • Sending payouts with aggregate-complete transaction
    • Creating an escrow with aggregate bonded transaction
    • Asking for mosaics with aggregate-bonded transaction
    • Signing announced aggregate-bonded transactions

    Block

    • Listening to New Blocks
    • Getting block by height

    Cross Chain Swaps

    • Atomic cross-chain swap between Sirius public and private chains

    Metadata

    • Account Metadata
    • Mosaic Metadata
    • Namespace Metadata
    • Account Metadata (Deprecated since 0.7.0 Sirius Chain release)
    • Mosaic Metadata (Deprecated since 0.7.0 Sirius Chain release)
    • Namespace Metadata (Deprecated since 0.7.0 Sirius Chain release)

    Monitoring

    • Monitor transaction

    Mosaic

    • Creating a mosaic (SDA)
    • Getting the mosaic information
    • Getting the asset identifier behind a namespace with receipts

    Mosaic Levy

    • Modifying Mosaic Supply

    Multisig Account

    • Converting an account to multisig
    • Modifying a multisig account
    • Creating a multi-level multisig-account
    • Sending a multisig transaction

    Namespace

    • Registering a namespace
    • Registering a subnamespace
    • Getting the Namespace information
    • Linking a namespace to a mosaic
    • Linking namespace to account

    Transfer Transaction

    • Transfer transaction
    • Sending an encrypted message

    Storage

    • Data Modification Cancel
    • Data Modification
    • Download Channel
    • Download Payment
    • Drive Closure
    • Finish Download Channel
    • Prepare Bc Drive
    • Replicator Offboarding
    • Replicator Onboarding
    • Storage Payment
    • Verification Payment

Storage

  • Overview
  • Participate
  • External Economy
  • Roles
  • Verification
  • Challenge
  • Rewards
  • Transaction Schemas
  • Built-In Features

    • Drive
    • Replicator
    • Verifier
    • Supercontracts

    Protocols

    • Cross-Block Protocol
    • Fair Streaming

    Storage User Application

    • Overview
    • Getting Started
    • Managing Drives
    • Managing Drive Files
    • Downloading Data

Consensus Algorithms

Background Information

Like any blockchain implementation, a fair and autonomous network ecosystem will always have a consensus mechanism that determines the different participating actors for a service. Sirius Chain uses Proof-of-Stake and Proof-of-Greed.

NXT's Proof-of-Stake Optimisation

Sirius Chain official has selected Proof-of-Stake (“PoS”) as its consensus algorithm for Sirius Chain. PoS is more economically efficient and has a higher performance than Proof-of-Work (“PoW”), making it a more attractive network for participants. PoS is also relatively easier to scale up, which is vital for the continued expansion of Sirius’ core services.

Sirius Chain has used NXT’s PoS as a reference, as it is arguably one of the most established and mature forms of a PoS implementation. Sirius Chain has an enhanced version of NXT’s consensus mechanism. Firstly, parameters were discovered that gave better control over the duration required to sign (validate) a block. Secondly, its further expansion has solved the problem of long blocks by providing a more "concentrated" block time. The selected parameters also help prevent zero-fee attacks and encourage nodes to take an average commission fee for creating a block.

In the standard version, Nxt blocks are generated every 60 seconds on average. With Sirius Chain official modification, blocks are generated every 15 seconds on average. Given that the full token supply already exists after the genesis block is validated, the blockchain state is redistributed through the inclusion of transaction fees which are awarded to an account when it successfully creates and validates a block. This process is known as “validating”, and is similar to the mining concept found in PoW.

Proof-of-Greed Extension

In the PoS model used by Sirius Chain, network security is governed by peers having a stake in the network. Although the incentives provided by Nxt’S algorithm do not promote centralization in the same way that PoW algorithms do, Sirius Chain official has created a new mechanism that decentralizes the block forging process even further. This mechanism is called Proof-of-Greed (“PoG”).

In PoG, instead of indicating a fixed transaction fee, an end-user that wants to execute a transaction on Sirius Chain will need to first offer the maximum fee he is willing to pay. Unconfirmed transactions form a Transactions Pool, from which Validators take transactions, form their own blocks, and request a fee that is not more than the maximum specified by the consumer end. Then the selection process begins. PoG’s algorithm takes into account not only the stake and age of the Validator, but also the size of the fee requested. The less fee the Validator requests, the higher the possibility that its block will be recorded on the Sirius Chain.

PoG also solves another major problem found in other blockchain networks, this being that there is no fee adjustment framework. With PoG, the fee size is adjustable for both consumers end-users and Validators.

Zero-fee Attack

If PoG’s focus is on penalizing greedy validators, then the question that arises is whether there is a potential vulnerability if validators behave in a complete opposite manner, by validating transactions for free. The scenario of a Zero-fee Attack is where malicious validators attempt to manipulate the PoG algorithm by taking zero fees, and as a result, forging the most blocks and potentially taking control of the network.

To combat this, mathematical parameters have been included in the PoG algorithm to ensure that validators that take an average fee have a higher chance of forging a block. This eliminates the possibility of a Zero-fee Attack.

Large-stake Attack

In PoS, the wealthiest and oldest validators are more likely to be selected for validating transactions. This could become a vulnerability for the network if a validator with a 51% stake decides to launch a Large-stake Attack by maliciously attempting to take control of the network, earn the majority of fees, and even reverse transactions.

With PoG, this can be prevented. PoG ensures that there is a fair spread when it comes to selecting and rewarding validators, meaning that even a validator with a small stake has a chance of having their block recorded on the blockchain.

- the number of nodes.

- the number of transactions in the block from the node , .

- how much commission node took from the transaction , , .

- maximum that node can take from the transaction , , .

- the greed of the node , .

where is the average cost of block recording in blockchain for a validator.

If is less than or close to the , then . In this case, the validator's behaviour strategy can be arbitrary, that is, it can take any percentage of the maximum possible commission without reducing its probability of creating the next block.

The parameter is set by the node for the whole block in the form of two variables and .

- parameter of the node , .

,

where and is variable parameters that are needed to be researched and modelled to get the best value.

Now we have a possibility of every node to be chosen. Because of new parameters, even nodes with low stakes can get the right to forge a block due to their generosity.

← ValidatingReceipt →
  • Background Information
  • NXT's Proof-of-Stake Optimisation
  • Proof-of-Greed Extension
  • Zero-fee Attack
  • Large-stake Attack
  • Follow our profile
  • Ask development questions
  • Join our Discord channel
  • Explore our Youtube channel
  • Explore Github
Protocol
BlockConsensus AlgorithmsCryptographyInflationNodeReceiptTransactionValidating
Built-in Features
AccountAggregate TransactionCross-Chain SwapsExchange MarketDecentralized Exchange MarketMetadataMosaicMultisig AccountNamespaceTransfer TransactionStorageLiquidity Provider
References
REST APISDKsCheat Sheet
Includes Documentation Forked from NEM
Copyright © 2025 Sirius Chain