An Introduction to ProximaX
A distributed network comprises of various nodes. In a blockchain network, some of the nodes are validator nodes while the rest are just nodes. ProximaX is slightly different from a traditional blockchain network. In fact, it is an integrated distributed network where the main blockchain protocol integrates with the off-chain service units. The different off-chain service units are again distributed. So the node actors in the entire ProximaX platform are vast, diverse, specific and precise.
Say for example if it is blockchain, the node actors are validator nodes and validator verifier nodes.
If it is a storage unit then the node actors are Acceptor nodes, Replicator nodes, Storage verifier nodes, etc.
If it is a streaming unit, then the node actors are stream discovery nodes, stream landing nodes, stream verifier nodes, stream distributor nodes, stream sender nodes, stream receiver nodes, etc.
If it is a content review unit, then the node actor is censorship node.
With such a wide range of nodes in a network, the real challenge is the management of these nodes. If the role of all the nodes is precisely defined and managed as per the laid framework then service to the business/consumers can be delivered through blockchain technology which has never been achieved before. That’s exactly what ProximaX aims to deliver.
All the node actors of a specific unit reach consensus to deliver a specific service relevant to that node. Say for example, if it is about storing a file, the node actors of the storage unit will come into effect. If it is about streaming, the node actors of both the storage unit and the streaming unit will come into effect. The consensus mechanism used for different units is different. The execution of a service in a unit is termed as “work done”. For every “work done”, there is an incentive to the node actors who provide/run that service.
In order to properly organize the incentives for every “work done”, the off-chain service units are further quantified numerically.
- 1 GB storage space/month is quantified as 1 SO unit.
1 SO unit= 0.004 USD - 1GB streamed data is quantified as 1 SM unit.
1 SM unit= 0.02 USD - 1 supercontract instruction code is quantified as 1 SC unit.
1 SC unit= 0.000005 USD - 1 XPX worth paid content is quantified as 1 RW unit.
1 RW unit= 0.005 USD
The above unit rates of various units are just an initial proposal and may be considered as a reference rate, the actual rate varies and that depends upon the proposal given by the consumer who requests a particular service. The consumer generally specifies its own rate in the contract and the node actors which agree to that rate are chosen to run that service. Once an agreement is reached, the contract is executed and the service is rendered to the consumer. For the “work done”, the nodes are incentivized.
The nodes selection and rejection are generally termed as on-boarding and off-boarding of nodes in ProximaX. The selection and rejection criteria of nodes vary from one service unit to the other.
Say for example, if it is about the ProximaX Sirius Blockchain, then the node selection criteria is on the basis of wealth and age of the node.
If it is about the storage unit, then the node selection criteria is on the basis of storage capacity of a node.
If it is about the streaming unit, then the node selection criteria are on the basis of bandwidth of the node.
Dynamic node selection & rejection
The node selection and rejection are again a dynamic process and that depends upon the requirement to deliver a particular service. Out of the several nodes which have been selected, few of them serve a particular service request and that is an automated process, which depends upon the requirement and execution of the contract.
For example, if a storage service request is initiated by a consumer and in the contract the consumer has specified the storage size then the node actors who seek to provide that service must comply with the storage capacity requirement to be considered to provide that service. That means the node must have a capacity equal to greater than the storage capacity mentioned in the contract to be eligible for selection.
Core Service of ProximaX
The different core services offered by ProximaX platform are:-
- Blockchain- Sirius chain
- Storage Unit(Off-chain)
- Streaming Unit(Off-chain)
- Supercontracts
- Content Review Unit
Although blockchain is specified as a unit in ProximaX, it provides a decentralized immutable ledger for all the activities in other off-chain units. Say for example, if a contract for utilizing storage space or streaming is to be executed, then it is to be executed on Sirius chain. When a transaction is to be carried out it has to be on-chain. So the Sirius chain may be considered as a pole for state management, recording and statistics management of all other off-chain service units.
Storage Unit
In storage unit, the acceptor nodes propagates the file, the replicator nodes replicates the file. The storage verifiers dynamically check which replicator has gone off-line, in that case, it replicates to the next available replicator. Acceptors charge SM unit, replicators charge SO & SM unit both.
In the commercial part of Storage tokenomics, the consumer or the end-user who wants to rent a decentralized storage service, has to pay in XPX which is the platform’s native token. The automated inner exchange then converts the XPX into service units like SM, SO etc, depending upon the use case.
In the Storage contract part, a contract is offered by the consumer which mentions all the details such as storage size requirement, duration, price, etc which is then accepted by the storage node actors (acceptors, replicators, etc). Once the contract is accepted it must be honored, otherwise just like incentives to provide the service exists, so as the penalty for not honoring the contract. As a part of Proof-of-storage the replicators, acceptors have to stake the required units to be eligible for providing a certain service as per the storage contract. If the contract is accepted and agreed, the replicators and the acceptors must provide and run the service requested by the consumer, else the staked units by the replicators/acceptors are forfeited and the reputation is also degraded.
For allocating replicators and acceptors to a storage contract “self-assigning and discovery” mechanism is used. For providing and running the service the replicators, acceptors are incentivized with SO, SM units depending upon the use case.
The replicators ultimately store the file of the consumer. So storage drive capacity of a replicator is an important parameter. But the “self-assigning & discovery” mechanism always checks the location & reputation of a replicator in addition to storage capacity. Once the mechanism discovers that a replicator is capable to run the service of a storage contract, the public key of the replicator is included in the contract, which is an indication that the replicator is selected for that job.
A consumer can perform all the functions such as upload, delete, modify, rename, copy, etc. in the decentralized storage unit of ProximaX. The relevant command may be used for the respective functions.
Streaming unit
In streaming unit, two types of streaming exist- Storage streaming & Live streaming.
Storage Streaming
In storage streaming, the data is pre-recorded and then using the streaming unit, it is streamed to the end-user. The acceptors pre-load the streamed data, the replicators replicate the streamed data to the end-users. The streaming happen between nodes in a distributed network and the propagation happens by cryptographically signing the data between the nodes. Both storage unit and streaming unit are required for streaming the data or content.
Live Streaming
In live streaming, the data or content is streamed live, that means recording, transmission, distribution, etc. all happen simultaneously and instantly to the end-users. Here the node actors are many and bandwidth plays an important role for the selection of the node actors. The stream sender broadcasts the streamed data and the stream receiver receives the streamed data, but in between stream sender and stream receiver there are other types of node actors which ensures smooth streaming of data between the two end points.
Stream landing node can receive the streamed data and can broadcast it to multiple stream distributor nodes and/or stream receivers.
Stream verifier nodes verify and report the live streaming status. If the quality of the streamed data is reported as poor then re-election of the stream landing node is done.
Stream distributor node distributes multiple content to one or more stream receivers. This node is most important when it is about handling heavy traffic. In other words, when the streaming is to be done to a huge number of end-users.
Stream discovery node discovers all these nodes in the distributed network of streaming unit for a streaming job.
Live streaming is of two types- 1-to-1 and 1-to-many type.
One important point to note about the streaming unit is that, on-chain transaction for rewarding is avoided as that can cause significant delay or interruption in live streaming. An alternative arrangement is made which uses time tags to determine the reputation with respect to the bandwidth of a node actor. The reputation score is drawn as the weighted bandwidth statistics via an indeterministic process.
The bandwidth requirement is relatively lower in 1-to-1 live streaming as compared to 1-to-many live streaming.
1-to-1 live streaming
As a proof of bandwidth requirement the stream verifier nodes first stake their SM units to be eligible for the live streaming.
The stream sender performs the latency and bandwidth check on these stream verifier nodes and select one of them as the stream landing node.
Now the communication between stream lending and stream receiver is established via stream landing node.
The stream lending node is very very important which routes the streamed data from stream sender to stream receiver. If there is some interruption detected in the live streaming that indicates that the stream landing node is a faulty one and that is replaced by another one from the stream verifier node.
The performance is verified by using time tags. The stream sender sends a time tag to the stream landing node which is signed by the stream landing node and sent back to stream sender.
Similarly, the stream landing node sends the time tag to stream receiver which is signed and sent back to stream landing node.
If the connection is poor, some of the time tags may not reach from one node to the other. So the performance check of live streaming is done by tallying the “time tags” with the “signed and sent back” time tags by the nodes. In case of poor streaming some of the time tags will be missing and lower in numbers in total as compared to the “signed & sent back” time tags by the nodes. Based on the performance check, the streaming protocol switches the faulty stream landing node with a new one from the stream verifier nodes.
Based on the “work done”, the nodes incentivized.
1-to-many live streaming
In 1-to-many live streaming, the real challenge is huge bandwidth requirement. The stream landing node alone may not be able to route the streamed data to a number of receivers. Therefore the streaming from stream sender to stream receiver is routed through stream landing node as well as stream distributor node. Stream distributor node has the capability to route the streamed data to a huge number of stream receivers. If it is about live broadcasting to a huge number of audience, then this type of arrangement is required for using the distributed streaming unit of ProximaX.
All other process of streaming protocol is same as 1-to-1 live streaming.
Database unit
The database unit of ProximaX is a private or hybrid blockchain offering. It supports IPFS and the applications can take advantage of this unit & utilize the pre-existing libraries.
Supercontracts
A supercontract of ProximaX differs from Smart contract because it can be modified unlike smart contract. A supercontract is more preferable for businesses as amendment very often happens during the process of business execution. The amendment may be due to something which was not included while writing the contract, the amendment may come as a force measure due to unforeseen reason, the amendment may also be due to fact that the contract is written by a less competent party. A supercontract is more useful and more practical than a smart contract.
A supercontract ideally requires storage unit where it is required to be uploaded and the execution is done on-chain. Both the approval and amendment of a supercontract is done based on the consensus of the pre-defined authority as mentioned in the contract. ProximaX also supports a variety of programming languages Java, C++, Python, C#, Golang, Js and Rust, etc to code a supercontract.
Content review unit
The content managers can use the decentralized content review unit. It allows censorship of content. So the consumers can filter the content as per their choice.
Sirius chain & consensus
Sirius chain is the main blockchain of the ProximaX platform. Any business can deploy its decentralized applications on the top of Sirius chain. Unlike other blockchain infrastructure, ProximaX Sirius offered everything to the application at one place so that the on-boarding can be smooth, the development can be cut short and the business can head straight to its goal quickly.
For any traditional business, the domain name, the account, the contracts are a part of the standard framework of business. Everyone needs it. In the decentralized ProximaX Sirius, the business applications can use all these features-
(1)Account-
An account is needed by any application & it consumes any of the service they render.
(2) Namespace-
The domain representation of an application can be created through namespace.
(3) Mosaics-
Any type of service that is rendered by an application must be quantifiable, so that the digital representation of the business services can be done. In order to facilitate this objective mosaics can be created as contracts on Sirius chain. It can represent anything the application wants to. Say for example, a share, a vote, a coin, an animal or anything the business developer wants.
(4) Metadata-
Accounts, Namespaces, Mosacis are immutably recorded on Sirius chain. That cannot be modified. So in order to have additional flexibility to the business purpose the metadata can be added as an attachment. The metadata can be modified or deleted.
(5) Multilevel Multi-signature-
It is a very useful feature of Sirius chain from a business perspective. The multiple parties at multiple level of a business can reach an agreement and co-sign from their respective accounts using this multi-signature function.
(6) Cross-chain transactions-
It is essential for the business applications developed on the top of ProximaX Sirius to interact with the main chain. From business point of view, it is most important because from time to time it may require interacting with the main chain tokenomics, therefore the interoperability is needed between the applications and the main chain for swapping of assets. Sirius chain supports atomic swap of assets between the main chain and the side chain. This feature will also ensure a healthy business ecosystem.
(7) Aggregated transactions-
Multiple transactions can be batched together & executed by generating a one-time disposable contract. This is known as aggregated transactions in Sirius chain and it saves a lot of time.
An application can onboard, run the service and off-board if it decides to do so. For off-boarding it just requires to close the storage drive.
Node selection & Security
Sirius chain selects the validators based on the stake(PoS) and age of the node. But the security is guaranteed by PoG. So Sirius uses a kind of hybrid consensus which is a combination of PoS and PoG. The generic disadvantage of PoS is nullified by PoG. So this mechanism of consensus makes the network scalable, secure and resource efficient. To become a platform of multiple dApps and to ensure the smooth performance of the dApp ecosystem it is essential to have a liner and scalable consensus, therefore PoS is chosen over PoW. The selection of PoS of Sirius chain is derived from the NXT’s PoS. The block generation time is Sirius is reduced to 15 seconds as against 60 seconds of NXT.
The validator nodes are selected based on the amount of XPX staked by the node and the age of the node. The minimum stake required to become eligible for selection is 250,000 XPX. However, the recommended stake is 2,500,000 XPX.
Once satisfying the eligibility criteria, the nodes are run through validator software which checks the account history of the node, amount of XPX staked and the age of the node. A reputation is given to the node & based on the reputation it is selected as validator node. If selected, the node becomes a validator node and start processing transactions. The validator nodes receive a share of block rewards.
PoG
PoG in Sirius chain makes the network decentralized and punish the greedy nodes. Some of the dishonest nodes may try to counter PoG and may start processing the transactions with zero fees(which is known as zero fee attack) and try to control the network and forge the blockchain with malicious intention. But PoG is also having another provision which includes a mathematical algorithm so that most of the transactions are assigned to those validators for processing who take average fees.
The other kind of attack is large stake attack in which the nodes can stake large amount of tokens and may gain 51% of the staking power and may ultimately gain the absolute power of the network and may forge a blockchain with malicious intention. But PoG ensures that all the small stake holder and large stake holder gets a fair opportunity to process the transaction and forge the blockchain.
Token ecosystem
The various types of tokens which are quantifiable in ProximaX platform are XPX, Mosaics, Service Units. All these three tokens are part of the internal economy of ProximaX.
The external economy is upto the decentralized applications who can implement their own payment method. They can choose any crypto asset or fiat as their payment method.
The external economy can interact with the internal economy for various purposes such as using storage unit requires SO unit, using streaming requires SM unit, etc. But it is essential to have the external economy to bridge upon with internal economy. For that “automated inner exchange” facilitates the interoperability between the external economy and internal economy. So not only the dApps can accept any payment method they want to from their consumer base, but also they can have it converted into XPX and subsequently from XPX to other service units such as SO, SM, etc.
This form of tokenomics is essential to incentivize all the defined “work done” in ProximaX platform. The dApps can be self-organized, they can leverage the various core service units of ProximaX and remain in synergy with the entire platform so the coupling of the dApps with the ProximaX platform will remain smooth, frictionless.
Conclusion
While the mass adoption was not as per the anticipated pace over past few years, this form of blockchain technology, which is offered by ProximaX by integrating the distributed network with the off-chain service units can at least be more mobile to business and enterprise grade application. The flexibility will not make this platform obsolete in future and it can very well adapt to the changing business needs. The developer friendly platform may encourage adding more units in future. ProximaX really wins it when it is about management of vast and diverse node actors. I can see a great potential of ProximaX to serve the businesses as an underlying platform.
More information & resources
- ProximaX Website
- ProximaX WhitePaper
- ProximaX at a Glance
- ProximaX Telegram
- ProximaX Medium
- ProximaX LinkedIn
- ProximaX Facebook
- ProximaX GitHub
- ProximaX Twitter
- ProximaX Instagram
- ProximaX Reddit
- ProximaX YouTube
Image courtesy
- proximax.io