top of page

Qbit platform

Qbit is a multi-asset privacy-oriented blockchain platform based on Proof-of-Stake/Proof-of-Content/Proof-of-Time configurable consensus with UTXO (unlinked transaction outs) principles. Qbit focuses are:

  • Entity-based management

  • Various kinds of typed transactions

  • Schnorr signatures/multi-signatures by default

  • Support of different signature schemes

  • Out-of-the-box privacy transactions for the value transfer (blinded transactions)

  • Ability to define various asset types and make asset emissions (tokens)

  • Scalable architecture

  • Atomic swaps support

  • Ultra-fast transaction processing

  • Multichain support with sharding principles (including different parametrized consensuses for each shard)

  • Smart contract support

  • Fast virtual machine (QVM) with asm-based machine codes (qASM)

  • Flexible integration infrastructure to support alts- and side- chains (gatekeepers)

  • DApp creation support infrastructure (front-to-back)

  • Built-in support of the "open digital organization" principles

​

Consensus

Qbit network supports chrono-time synchronization protocol. This p2p protocol guarantees, that the Network Universal Time is calculated properly for every peer in the Network through time-tickets interexchange with the relative near peers. And within an almost constant time slice it should be equal for all nodes in the network. Network universal time is used to support time-bound consensus protocol.

​

Proof-of-Time (PoT)

Every node selects the next node who will be authorized to make the next block for the chain (main or shard). Simplified common algorithm should be the following (applicable to the every node on the network):

  • Every node collects other node states along with own state into sorted list 

  • Gets current Network universal time  and use it as seed to the monotonous pseudo-random digits generator

  • Selects node number from the list

  • If selected node is current, than in the next time frame (time slice) node produces a new block-(s) with the selected transactions and broadcasts the block header with transactions merkle root calculated, so the rest of the network awaits for this info

  • Proof check is simple: each block header contains “cycle of peers” or active peers, who is involved into consensus and universal time stamp, which is used as seed number to the monotonous pseudo-random digits generator and block check algorithm is:

    • Make sorted list of peers from “cycle”

    • Init generator with timestamp

    • Make pseudo-random distribution within generator in range 0 - N, where N is the count of peers in “cycle”

    • Use given index from distribution to select appropriate peer and check with the block origin (origin - peer who claims to make a block)

 

This approach will dramatically reduce network overhead. This fact becomes more important if we take into account how many parallel data streams will be processed within all the network.

​

Proof-of-Content (PoC)

Every node in the network, which supports the exact shard or mainchain should provide a so-called content challenge and be able to check previous challenge made by the previous leader. Challenge scheme look like:

 


 

 

 

 

Where block hash and tx index - randomly selected block and transaction index in it respecting universal timestamp. This content challenge should be solved by the next leader to be sure, that the content is available under current leaders’ control. And the current leader during block making procedure should declare its own challenge to the NEXT block leader.

​

Proof-of-Stake (PoS)

Additionally to get the right to make blocks, node should have enough QTT tokens on its main address (or key). Initial amount is N tokens. Transaction hash with unspent output should be added to the block header and tx owner must be equal to the origin (pkey of the current leader). And the last action - is to make a signature for the block header data and place this signature to the block header. All this information will be used to check that the origin is the right and legitimate owner of the block.
 

Chrono-time synchronization protocol

To implement the correct consensus algorithm we need strict timings to synchronize universal time in the network. Literally every node (including light clients) should support time synchronization protocol.

​

Chrono-time synchronization based on reachable nodes timestamp interexchange. Timestamp should have microsecond precision. 

​

​

​

 

 

 

 

 

 

 

Each node initiates timestamp exchange during its own non-synchronized schedule. But exchange cycles should not be greater than 2 seconds. And sends a packet with its own timestamp to the nodes. Destination nodes should make replays with their own timestamps. When reply is arrived back, source node make the following actions(see pic):

  • Calculate: N5latency = | N1ts - N5ts |

  • Push N5ts, N5latency into chrono-map

  • Calculate map’s timestamp (summary of the all the nodes timestamps), excluding those nodes who’s timestamp between own timestamp +/- N  block times

  • Calculate: median time = timestamps / peers

  • Calculate: universal time = round (median time)

​

As a result we’ll have: universal adjusted time and max latency in milliseconds, which gives us max time synchronization interval.

PoC.png
PoT.png

The platform is built on the following basic entities: transactions (various types) and blocks. Generic transaction consists of one or more inputs, one or more outputs, including fee. Every input and output contains hash of 'asset' type, thus single transaction can contain several assets to transfer with in&out balance consistence. Value transfer transactions is private transactions with blinded amounts (Pedersen commitment, range proofs). Transactions is not free - you need some QBIT coins to pay for them.

​

Basic transaction types:

  • TxCoinBase / "coinbase": coinbase transaction. This type used internally by mining or block making process. Used in Main chain only.

  • TxBase / "base": used for shards to collect transaction fees in the block. Mining or block emission process.

  • TxBlockBase / "blockbase": special transaction type, that aggregates and send to the miner's address collected fees from shards block making procedure.

  • TxSpend / "spend": spend or send QBIT coins or any other assets to the Qbit user (address or pkey).

  • TxSpendPrivate / "spend_private": spend or send private (blinded amounts) QBIT coins or other assets to the Qbit user (address or pkey). Transactions of this type are 3 times (or more) larger in size, than regular spend transactions. Amounts of private transaction are blinded and visible/claimable only by receiver.

  • TxFee / "fee": special transaction type, that represents Qbit fee for DApp transactions, those resides in various shards.

  • TxAssetType / "asset_type": transaction, that creates token type with attributes (name, description, scale, total amount).

  • TxAssetEmission / "asset_emission": transaction linked with the asset type transaction and enabling actual full or partial emission. Emitted tokens sent to the creator's Qbit address.

  • TxDApp / "dapp": transaction declares DApp instance as entity. Attributes are: name, description, sharding type, instance types.

  • TxShard / "shard": tis type of transaction linked to dapp transaction and creates shard for the selected dapp.

​

Spend or usage of unlinked outs (UTXOs) for the corresponding transactions controlled by byte-code written on QASM, which processed by Virtual Machine (QVM). QASM is the Turing complete language with macro assembler commands, which permits to create sophisticated usage/flow control code. QASM & QVM has 8 register groups:

  • r00-r31: common usage (r00 - used as execution results)

  • s00-s07: signature check bound

  • c00: conditions check result

  • th00-th16: "this" registers (tx hash, tx type, tx inputs\outputs)

  • a00-a07: "amount" reqisters

  • d00: destination register (address, hash, etc)

  • p00: utxo push result (read-only)

  • e00: destination equality check result (read-only)

QASM short example for in[i] verification code:

    mov        s0, 0x2023947283749211              # pubkey
    mov        s1, 0x85389659837439875498347598357 # signature
    lhash256   s2 # hash link, result -> s2
    checksig      # s0 - key, s1 - sig, s2 - message ->

                  # -> result s7 [s7-r/o]
    dtxo          # p0 - pop utxo result

Qbit platform has rich binary-coded extensible network exchange protocol. Basic actions - state changed, block found, time changed, push transaction & etc - all of this actions are wrapped into network exchange messages. Protocol itself has bidirectional dialogue nature (except notifications - this types of messages is unidirectional). Protocol stack works in asynchronous extensible mode and capable to handle thousands requests/messages per second.

​

When transaction is pushed, for example, border checks is conducted and transaction passed to the corresponding memory pool. Mempool pass checks (including qasm pre- post- conditions for transaction ins/outs) and adds this transaction to the mempool tree. When miner collects transactions from pool, transaction selector for next block traverses candidates (priority, left/right linkage) and makes consistent set of transactions for the future block. Note: there have place cross-sharding transaction links, this dependent transactions is postponed until parent transaction will be confirmed.

​

Miner, using specified algo, finds a decision for the next block, check result and trying to broadcast block header to the network and consequently stores found block with all transactions in the chain (mempool is cleaned up from commited transactions).

​

As backend for storage of blocks, transactions and indexes wrapped LevelDb is used. Qbit node or full node provide various methods for search and select stored data (like traditional block-explorers).

bottom of page