PPIO is a decentralized data storage and delivery platform for developers who value affordability, speed, and privacy. But we’re offering more than just storage. What separates PPIO from other projects on the market is our emphasis on providing data distribution and data transfer technologies and services. With regard to data transmission, we have given much thought on how to ensure that data transmission traffic is implemented in a fair and verifiable way. This is our state channel mechanism and here’s everything you need to know about it.
The Traditional State Channel Mechanism
The state channel is an existing concept in the world of blockchain and is mainly used for high-frequency transactions and micropayments. In scenarios where the two occur, the amount of transactions is exceedingly large, and if each transaction is performed on a decentralized chain that requires consensus, performance will suffer.
The introduction of a state channel is essential to balance both the high throughput of transactions with the decentralization of the verifier. More specifically, the state channel takes high-frequency micropayments between two traders that would ordinarily be on the blockchain and moves them off-chain. When a series of payments is completed, or if a dispute arises, then arbitration is carried out on the blockchain.
If the above sounds a bit much, the following will illustrate the state channel. Let’s assume both A and B begin with 10 assets; a series of high-frequency micropayments will occur between them.
The whole process is roughly divided into the following steps:
Either A or B will create a state channel smart contract (referred to as C).
A and B each put 10 assets into the contract. At this point, the state channel is turned on and enters the open state. This process is also going to be on the chain. The current distribution, or allocation status, at this time is[A:10, B:10].
Note: Distribution means that both sides of the transaction can approve the asset allocation under the chain. The total amount is the same, either A or B. If the contract terminates at this time, the assets of the distribution will be returned to their respective accounts.
As the state channel between A and B is now open, transactions between the two can begin. If A transfers one asset to B, then the distribution is [A:9; B:11; N:1], and B gets the signature of A which confirms the allocation status. From here, B transfers three assets to A, changing the distribution totals to [A:12; B:8; N:2]. As before, A gets the B’s signature confirming the current allocation status. Here N denotes a nonce — a cryptographic term that denotes a single-use arbitrary number. Each time the two sides of the chain change the asset allocation according to the agreement, they will increase the value of the nonce by themselves. Honest traders will use the nonce’s largest allocation scheme as the current allocation scheme. By always referring to the largest value, the smaller nonce value will become invalid and can be discarded at any time.
In the process of the transaction, either party can submit a state submissionto the smart contract C at any time. If A initiates the state submission, C will verify the signature of B. Conversely, if B initiates it, C will verify the signature of A and the value of the nonce. As stated, the smart contract only accepts the distribution scheme that is larger than the nonce value assigned on the last chain. If both the nonce and signature are permitted, then C receives a new allocation scheme and updates the nonce value. The two sides continue to trade until the final allocation scheme is assumed to be [A: 1; B: 19; N: 50], hereinafter referred to as the final state. Afterward, we can assume that the state channel has been submitted and accepted by the smart contract.
The status channel request is closed. At this time, the closed state channel can be initiated by either party, i.e. according to the chain allocation scheme in the contract. Once smart contract C receives a request to close the channel, a temporary closing state is initiated in which, for a valid period of time, the other party can still submit a new valid allocation scheme which will return the state channel to the open state. If the other party fails to return the state channel to the open state during this period, the state channel will enter a closed state. In our example, B initiates a closed state channel request, so the state channel enters the closing state.
Although the distribution scheme on the chain is now [A:1; B: 19; N:50], the last allocation scheme under the chain is actually [A:4; B: 16 N:55]. If, for example, B happens to be a bad actor (i.e. does something malicious and does not follow the rules), then B may try to use the old distribution plan to allocate assets and increase their own benefit.
At this time, because the contract is in a closing state, as long as A finds out the transaction of the channel closure request on B’s chain on time, A can immediately submit the updated distribution scheme [A:4; B:16; N:55] to the contract, so that the contract can be put back in an open state to prevent B’s fraudulent withdrawal. Afterward, if A wants to close the contract, A can re-initiate a request to close the state channel to the contract. After that, as long as B can’t give an updated allocation scheme greater than N:55, the state channel will eventually enter a closed state after the grace period.
Note: State submission and a closed state channel request can also be merged into one step for specific implementations.
Final Asset Allocation: When contract C enters the closed state, either party can trigger the final asset allocation, which is the actual asset allocation based on the last valid allocation plan determined on the chain.
Looking back at the whole process, the only steps required to write to the blockchain are the parts related to the smart contract on the chain: the creation of the state channel, the submission of the allocation plan, and the submission of the final state. The rest are operated under the chain on the state channel. The design and operation of the state channel mean the transaction is submitted only once to the blockchain in order to maximize performance and to reduce the computational load.
The Design of PPIO’s State Channel Mechanism
As we summarized in our PRoute Intelligent Routing article, PPIO has three core modules:
- POSS is a P2P Object Storage Service that provides storage similar to AWS’s S3.
- PCDN is a P2P Content Delivery Network, that targets traditional CDNs, just like AWS’s Cloud Front.
- PRoute is an adaptive network intelligent routing based on P2P which achieves the fastest speed and the lowest delay by establishing the most reasonable path between two nodes. This is the implementation of the protocol layer. Currently, there is no similar product as part of AWS.
In addition to the POSS module, PCDN and PRoute use more bandwidth, and the transmission of network data occurs in real-time and is very frequent. If everything is written to the blockchain, it would be a huge computational waste. In fact, the high-speed transmission of network data, in essence, is really just high-frequency transactions and micro-payments, so when designing PPIO, we used a traditional state channel mechanism for reference to reduce bandwidth.
In the design of PPIO, there are two key roles of the User and Miner. Simply put, the Miner transmits data unilaterally to the User. The following is the design of PPIO’s simplest state channel for data transmissions.
- The User (U) creates a smart contract (C) on the blockchain. U then transfers 10 assets to C. Since PPIO is designed as a one-way channel, only U can engage the open state after it is transferred to the asset. The allocation scheme is [U:10; M:0].
- Data transfer begins. U requests data from the Miner (M). M returns the correct data to U. U will give M a Voucher that lists the new state allocation scheme with a U signature. Since the real-time requirements of network transmissions are very high, M needs to give the data first, before taking the Voucher. At this time, the allocation scheme gradually becomes [U:9; M:1].
- Data transfer continues as part of the state channel allocation scheme. Over the course of the transfer, U’s assets will decrease, while the M’s assets will increase. Eventually, U runs out of assets that were previously stored in the state channel. The allocation scheme becomes [U:0; M:10].
- Final state submission: M uses the latest Voucher to withdraw money from the smart contract on the blockchain. After verifying the correct signature of U in Voucher, C accepted M’s withdrawal. After that, the state channel closes and enters the closed state, after which the state channel can no longer be traded on.
- If U requests further data from M, M will no longer provide services because the assets have been used up. If on the other hand, U creates a new state channel contract then transfer assets, U can request data from M again.
Prevention Against Malicious Behavior
While PPIO’s entire state channel is straight-forward when parties are honest, we have also accounted for situations with bad players. The following is a simple attack and defense analysis if either the User or the Miner does not follow the rules.
- Suppose the User is being a bad player, and after requesting data from the Miner, does not give the Voucher. For network performance, the design of PPIO is to give certain data first and then Voucher. If M, after giving a certain amount of data, finds that U has not given the Voucher will cease to share any more data and will mark U as a malicious user.
- If instead, the Miner is a bad player and the User finds that the data is abnormal or wrong, then U, firstly, will not give the Voucher, then will close the state channel and submit it to the smart contract, and finally will flag M. If there is a Verifier in the network, U can also report M to the Verifier, after which the Verifier will verify M’s actions and analyze whether M has performed other malicious acts.
With the state channel, there may be some slight losses on one side when both sides of the transaction do not engage in fair play. However it does not affect the overall design, so the bandwidth incentive in PPIO does not require any collateral from a Miner; this is different from what would take place if storage is involved.
- Storage works on a long-term timeframe which means a Miner must offer a type of insurance that they will correctly store the User’s data for the agreed-upon time period. This acts as compensation if data is lost. In storage scenarios, it is necessary to compel a Miner to provide storage services honestly and reliably by requiring this insurance.
- The deterministic nature of data storage makes it possible to verify the persistence of all that is stored. Deterministic data can be organized by a Merkle tree, and then the path from the leaf node to the Merkle root can be used as proof of data holdings. Verification of this proof can be done using smart contracts or trusted third parties.
Bandwidth is different. Bandwidth is instantaneous and uncertain. Bandwidth transmissions are relatively short compared to data storage, and what data is transmitted is generally unknown before transmission. These two points make it difficult for a User to mathematically limit a Miner to only transmit the correct data. It is also difficult to constrain a Miner by a proof so that a Miner does not perform a malicious act.
Once a Miner becomes a bad actor, a trusted third party or a smart contract cannot accurately determine whether that Miner is malicious or whether a User has framed a Miner. Therefore, even if a Miner offers insurance, the third party or a smart contract does not know how to deal with that insurance in case of disputes. Therefore, bandwidth scenarios are markedly different from storage scenarios.
The idea for bandwidth scenarios is to use the state channel to implement a ‘step-by-step’ approach which means that only small transactions are made in order to minimize big losses. If the other party is a bad actor, the transaction is immediately stopped and a new, honest partner can be found. That way, even if the other party is malicious, the losses are not great.
This only explains the basic principle of PPIO’s state channel. In some scenarios, the state channel has a more complicated usage, however, the basic principle remains unchanged
The Owner is not a P2P transmission role, but a payment and settlement role. For PPIO’s PCDN architecture, each Peer needs to specify an Owner. The expenses incurred by the Peer are borne by its Owner, and the income earned by the Peer is also received by his Owner.
As shown in the figure below, the same Owner can connect multiple Peers.
This role can be easily understood as: the developer is on the demand side, while the mine pool is on the supply side. In other words, it’s a CoinPool — a proxy payment gateway. For a further understanding of why we’re structuring things this way, click the link to read Why PPIO Designed Proxy Payment Gateways.
The data distribution contract upgraded by the state channel is shown below.
Efficiency and value have always been the yardstick for our continuous desire to innovate and advance the technology we know best. In this article, we shared how we designed the PPIO state channel based on traditional state channel mechanisms to fairly transmit data between parties. Based on a practical case, we analyzed how the two roles of User and Miner can effectively transmit data based on such a design while avoiding unnecessary losses caused by malicious behavior. Finally, we explained why that bandwidth incentives do not require any collateral from Miners, which is fundamentally different from storage scenarios. For a deeper understanding of how the state channel can be used for PCDN scenarios or how PPIO smart contracts work, check out our popular article on the subjects: Creating Better Smart Contracts For Data Delivery. And as always, if you have any questions, ask us below or jump onto our Discord community channel to chat with the team.