Rubix Blockchain

The Rubix Proofchain protocol is a deterministic state-machine that is designed to address the scale, cost, and privacy shortcomings of blockchain protocols that rely on one sequentially organized chain of all global transactions. The protocol divides the global state machine into a large, but finite number of state-machines called Proofchains. While each Proofchain maintains one state, together all Proofchains represent a globally accessible singleton state that is immutable. This paper explains various components that make up the protocol.

A Proofchain PTi is a chain of all transactions bound by the utility token Ti (note that there will be a total of about 51.4 million RBT utility tokens in the Rubix Network). A small set ofRBT tokens are committed by the genesis node G. All proofchains with the RBT tokens committed in the genesis node G originate with the genesis node. All such RBT tokens are stored and committed on the IPFS by the genesis node G. The node G’s ownership of such tokens is globally verifiable. All those RBT tokens that are not pre-committed to the node G are mined by validators. In such cases, once the RBT token is mined, the corresponding Proofchain of that token starts with the validators node that has mined the token.

Every transaction in Rubix network is bound to one or a set of tokens. There are two types of tokens: Asset tokens and Utility tokens. There will be about 51.4 million native utility tokens (named Rubix or RBT tokens). Asset tokens represent both (a) unique digital assets like tickets, coupons, credits, vouchers or collectibles and (b) the digital form of any real world assets like land, shares, vehicle etc.. These tokens are Non-Fungible Tokens (NFT) much like Ethereum’s ERC721 tokens. They are unique and cannot be interchanged. Such tokens do not add any value on its own to the network and hence are not limited in supply not are restricted in creation. When compared to its Ethereum model ERC 721, Rubix asset tokens are more dynamic. Unlike ERC721 which use a parameter “value” during the creation itself, Rubix asset token’s value can vary during the life, depending on the underlying utility limited in supply not are restricted in creation.

An asset token Ai bound by utility tokens worth x units holds its price value at x. In the next transfer of token Ai, let us assume it is bound to a transaction with utility tokens worth y units; the value of the asset token Ai then changes to y units. Thus, in Rubix platform, the current value of any asset token depends upon the earlier transaction it was involved in. If an asset token has not been transacted even once in the network, it effectively holds no value in the network.

Rubix native utility tokens (RBT) are capped about 51.4 million in total. With Rubix’s breakthrough Proofchain architecture, the network does not require expensive miners or overpowering stakeholders with proof of stake protocols to maintain the network integrity.

While a small portion of the tokens (56 in total) are pre-created to facilitate faster bootstrapping, all except the 56 tokens are mined by the nodes in the network. Since a full Rubix node can be set up even on a laptop with basic specifications, most computing nodesin the world would be eligible for being a miner.

Rubix introduces Proof of Pledge (PoP) protocol where all Rubix nodes consent to be validators (miners) & any node can be chosen as a validator based on the quality of network, system requirements & balance of proof credits left (more on this explained later in this paper). Rubix mining protocol is eco-friendly & carries low carbon footprint. Mining also means that nodes accumulated tokens in a decentralized & egalitarian method rather than by aggressively concentrating hash power to mine tokens. The PoP consensus is detailed in the subsequent sections.

A Node looking to transact must register on the Rubix network. Rubix full nodes can be set up on most laptops & desktops. A Rubix node will automatically be registered as a peer-node on the Inter Planetary File System (IPFS). An IPFS peer node is automatically assigned a Peer ID. Peer ID is a cryptographic hash of the public key of the peer node.

IPFS uses a public-key (or asymmetric) cryptographic system to generate a pair of keys: a public key which can be shared, and a private key which needs to be kept secret. With this set of keys, an IPFS peer node can perform authentication, where the public key verifies that the peer with the paired private key actually sent a given message, and encryption, where only the peer with the paired private key can decrypt the message encrypted with the corresponding public key.

DID creation take 2 input parameters, first a 256x256 PNG image of users' choice. Second seed is a SHA3-256 hash H, that is generated from user and machine characteristics. Decentralized Identifier needs to satisfy two properties: Uniqueness and Randomness. Uniqueness is required to distinctly refer each node and randomness property is essential for share generation phase. The PNG image provides randomness since its chosen by user whereas the hash H contributes towards achieving uniqueness.

DID Embedding Process

1. The 256*256 PNG image is converted to bits.

2. First 256 bits performs a XOR operation with the SHA3-256 hash H.

3. A hash of H is created to embed with the next bits 256-511 of the PNG image bits.

4. Subsequently, a hash chain of hashes is created, and each hash is embedded to corresponding PNG image bits

5. The embedded bits are finally converted back to a 256*256 image

The DID for node i, Ki, is split into two secret shares using the Non-Linear Secret Sharing (NLSS)6 cryptographic techniques – (a) a public network share Kin and (b) a private share Kip. Upon splitting, the two shares are 8 times the size of the original DID. Ki and Kin are stored by the node in the IPFS. The IPFS hashes of Ki and Kin, H(Ki) and H(Kin) respectively,are shared across other peer nodes in the network using gossip protocol. Any peer node, to perform a transaction with node i, fetches the Ki and Kin from the IPFS using H(Kin) and H(Kin).

Kip is the secret knowledge known only to the node i.To authenticate the node i to the Rubix Network, knowledge of the private share knowledge of the private share Kip is necessary. Since only the node i has the knowledge of the private share Kip, only it can authenticate successfully to the rest of the network.

The DID Token for node i, Ki is split into two secret shares using the Non-Linear Secret Sharing (NLSS) cryptographic techniques – (a) a public network share Kin and (b) a private share Kip. Each of the shares expand into 8 times upon splitting. Ki and Kin are stored on the IPFS & are globally accessible as well as verifiable. Ki and Kin are inseparable from the Peer ID of the node i and hence cannot be faked. The private share Kip is secretly and securely stored by the node i. Using the NLSS cryptographic techniques, each pixel of the DID token K is split into two secret shares. Kin and Kip are reconstructed from the split shares of all pixels of K. Knowledge of either Kin or Kip does not help in the reconstruction of Ki. To reconstruct Ki, knowledge of both Kin and Kip as well as the Non-Linear function Fn used for splitting into the secret shares is needed.

Since Kip is the secret knowledge possessed by the node i, only node i can authenticate itself to another peer node. In other words, to authenticate to another peer node, knowledge of the private share Kip is necessary. The authentication process involves cryptographic Proof of Work from the node i. Let us say that the node i would like to authenticate itself to node j. Node j would issue a cryptographic challenge by asking for the values of the 256 pixels from the private share Ki. Node j would randomly select the 256 position values that make up the challenge. Note that node j would be honest in picking the 256 position values since it is seeking the identity of another node. There is a total of 1,572,864 pixels (each RGB pixel can take 24 values & there are a total of 256x256 or 65,536 pixels; 65,536 x 24 = 1,572,864) in a DID token. Upon receiving the challenge, Node i would return the values of the 256 pixels of the private share Kip. Node j combines the values of the 256 pixels of Kip with the values of the corresponding 256 pixels of Kin to compare the result with the values of the corresponding 32 pixels of Ki. (note that each pixel of Ki is expanded to 8 pixels while splitting into Kip & Kip. A complete match would successfully authenticate Node i to Node j.

Rubix introduces the lightweight, low carbon footprint consensus protocol, a combination of (a) Proof of Work (PoW) & (b) Proof of Pledge (PoP).Validators perform work to validate the transaction & verify cryptographic signatures. Validators earn proof credits in return for the work performed. The credits earnt as a result of work are pledged by the validators to secure the network using the PoP algorithm. Proof of Pledge (PoP) is the most important part of the consensus in the Rubix Network. Proof of Pledge (PoP) is not the same as PoS.PoS requires validating nodes to stake native tokens continuously, in order to validate & also to earn rewards. Further the power of the nodes with higher coin stakes continue to increase, leading to more concentration. In the case of PoP, only outstanding proof credits are pledged, not the native RBT tokens. When the outstanding proof credits are converted into RBT tokens, validators need to earn new proof credits before being eligible for ⍺ validators (more in this later in this section). Since nodes are in continuous competition with each other to convert the outstanding proof credits into RBT tokens (before the credits deprecate in their value as the network moves into next level), accumulation of proof credits in order to control the network is not possible. Hence, every node in the network gets equal chance to become a ⍺ validator & there is no scope for concentration in validator powers. Eliminating the need for staking also obviates the need for rent seeking, a crucial bone of contention with PoS algorithms.

The Rubix Proofchain protocol is a deterministic state-machine that is designed to address the scale, cost, and privacy shortcomings of blockchain protocols that rely on one sequentially organized chain of all global transactions. The protocol divides the global state machine into a large, but finite number of state-machines called Proofchains. While each Proofchain maintains one state, together all Proofchains represent a globally accessible singleton state that is immutable. This paper explains various components that make up the protocol.

Blockchain protocols such as Bitcoin1 & Ethereum8 in general achieve a globally accessible singleton state by organizing all global transactions sequentially as blocks (each block having a finite number of transactions) and organizing the blocks as a hashchain. Such blockchain protocols require exhaustive mining-based Proof-of-Work (PoW) consensus algorithms to secure the state, which results in high latency, low throughput, and high transaction costs. While the Proof-of-Stake (PoS)⁷ consensus protocols may alleviate the energy & throughput issues associated with the PoW consensus, PoS protocols suffer from concentration (nodes with higher existing stakes may continue to gain larger voting power), security (“nothing-at-stake” & impersonation risks). Further, both PoW & PoS protocols require every node to store the entire global state, which results in significant storage inefficiencies.

In contrast to the sequential transaction architecture of blockchains, Rubix Proofchain processes transactions in an asynchronously parallel manner. Each transaction achieves finality on its own without waiting to be pooled with unrelated transactions.

The Rubix global state will be made of about 51.4 million Proofchains. Each Proofchain is bound by one unique utility token. A ProofChain PT is made of all transactions that use token Tn to confirm. All transactions within a Proofchain PT are validated individually and sequentially. However, transactions of different Proofchains are validated asynchronously and parallelly.

Every transaction in Rubix network is bound to one or a set of tokens. There are two types of tokens: Asset tokens and Utility tokens. There will be about 51.4 million native utility tokens (named Rubix or RBT tokens). Asset tokens represent both (a) unique digital assets like tickets, coupons, credits, vouchers or collectibles and (b) the digital form of any real world assets like land, shares, vehicle etc.. These tokens are Non-Fungible Tokens (NFT) much like Ethereum’s ERC721 tokens. They are unique and cannot be interchanged. Such tokens do not add any value on its own to the network and hence are not limited in supply not are restricted in creation. When compared to its Ethereum model ERC 721, Rubix asset tokens are more dynamic. Unlike ERC721 which use a parameter “value” during the creation itself, Rubix asset token’s value can vary during the life, depending on the underlying utility limited in supply not are restricted in creation.