Jointly produced by Tongzhengtong Research Institute × FENBUSHI DIGITAL
Text: Song Shuangjie, CFA; Cheng Dongfeng
Text: Song Shuangjie, CFA; Cheng Dongfeng
guide
guide
Summary
State channels are a popular expansion solution. The Ethereum Foundation recently disclosed an annual budget of US$30 million, of which US$19 million is used for the development of Ethereum 2.0 including state channels and Plasma. The state channel is expected to promote the large-scale commercial application of the blockchain.
Summary
The Impossible Triangle of blockchain means that the three characteristics of decentralization, security, and scalability cannot be well satisfied at the same time.
By isolating off-chain interaction and on-chain clearing, the state channel solution can achieve faster and lower-cost transactions while ensuring a certain degree of decentralization and asset security. As an off-chain expansion solution, the state channel is divided into three levels from general to special: general state channel, state channel and payment channel.
The main problems faced by the state channel include routing problems, channel balance problems, node offline problems, and deposit locking problems.
Compared with the on-chain expansion scheme, the state channel cleverly separates the on-chain and off-chain functions. Adopting this scheme does not need to change the structure of the public chain, and combines the security and decentralization features on the chain and the scalability of the off-chain , but from the perspective of the overall ecology, due to possible problems in the communication process between the chain and the chain, the state channel still belongs to a new balance of security, decentralization and scalability. Compared with other off-chain expansion solutions, the state channel has better privacy and can achieve immediacy. It is especially suitable for high-frequency interaction between fixed parties. Its disadvantage is that it requires intermediate nodes to "advance" funds, requires nodes to be online in real time Introduce a third party to monitor.
Table of contents
Risk warning: intermediary node monopoly, security loopholes
Table of contents
1 Overview of state channels
2 Three levels of state channels
2.1 General state channel
2.2 State channel
2.3 Payment channel
3 Key issues to be overcome in state channels
3.1 Routing problem
3.1.1 Hashed Time Lock Contract (HTLC, Hashed-Time Lock Contract)
3.1.2 Virtual Channel (Virtual Channel)
3.1.3 Meta Channel
3.2 Channel balance problem
3.3 Node offline problem
3.4 Margin lock problem
4.1 Comparison with on-chain expansion solutions
text
text
State Channel (State Channel) is one of the blockchain off-chain expansion solutions. At present, many well-known projects have adopted the State Channel technology solution.
secondary title
1 Overview of state channels
All nodes in the blockchain perform the same calculations and store the same data. Such a redundant architecture ensures security and decentralization, but also causes the blockchain to process transactions very slowly and expensively .
Off-chain expansion, also known as layer 2 expansion, is an application layer expansion solution that does not change the basic protocol of the public chain. Layer 1 (layer-1) provides security, and layer 2 (layer-2) provides scalability . Off-chain expansion currently mainly includes solutions such as state channels, side chains (or sub-chains), and off-chain computing.
The state in the state channel refers to the current state of the blockchain ledger, including account name (or address in UTXO model), balance (or unspent transaction output under UTXO model), contract data, etc. The state channel is to open an off-chain channel between two or more parties for state exchange, so as to achieve lower handling fees and instant arrival.
The process of using state channel transactions is generally as follows:
① The transaction party locks a certain amount of assets on the chain, records and opens a status channel on the blockchain;
② Mutual transactions and status updates are carried out in the channel, but not submitted to the chain;
③When any party wants to close the channel, submit the final state to the blockchain for liquidation. If the other party has an objection, it can apply for on-chain arbitration within the specified time.
When a party tries to cheat and submits a non-final state that is beneficial to itself to the chain, the other party can appeal to the chain by submitting the latest state with a time stamp. After being confirmed, the fraudster will face the penalty of confiscating the collateral. However, this requires the users of the state channel to be online in real time. If a party is offline for a long time, on-chain liquidation will be enforced, which may cause losses. In this case, a third party is generally introduced to monitor whether there is any fraud, but this requires the design of a reasonable third-party economic incentive mechanism.
The state channel scheme is more suitable for scenarios where participants need to exchange states multiple times in a relatively long period of time and are sensitive to transaction fees for a single transfer. For example, chess and card games, Internet of Things smart payment (M2M), gaming platforms, live broadcast rewards, etc.
secondary title
2 Three levels of state channels
As an off-chain expansion solution, state channels are divided into three levels from general to special: Generalized State Channel, State Channel and Payment Channel.
2.1 General state channel
Universal state channel is a modular and standardized state channel development framework, which becomes a state channel or payment channel after instantiation. Developers can easily develop applications based on state channels without being familiar with the relevant technical details of state channels, and users can also install, run and terminate DApps in channels without performing any operations on the chain.
Typical projects include Counterfactual (a development framework for building applications based on off-chain state channels), and Celer Network (a layer-2 extension platform that helps developers quickly build and run decentralized applications).
2.2 State channel
A state channel is a channel for state interaction under the chain. The purpose of state exchange and off-chain expansion is achieved by putting the Turing-complete smart contract on the chain into the off-chain execution. For example, the Go game developed based on the state channel is to continuously exchange state under the chain.
Typical projects include Perun Network (supporting the execution of off-chain smart contracts) and FunFair (a gambling game based on state channels).
The payment channel belongs to the specific application of the state channel in the payment field. Both parties to the transaction can conduct multiple transactions in the state channel until the channel is closed and cleared on the chain. Off-chain transfers are fast and free of fees. When one party tries to commit fraud during on-chain liquidation, there will be an arbitration and punishment mechanism to ensure the security of the assets of both parties.
Typical projects include Lightning Network (BTC state channel payment network), Raiden (Ethereum version of Lightning Network), Trinity (Neo version of Lightning Network), Liquidity Network (payment channel network based on NOCUST protocol).
secondary title
3 Key issues to be overcome in state channels
3.1 Routing problem
In order to expand the payment channel into a payment network, it is undoubtedly more economical to establish a connection between two unfamiliar nodes through a routing node on the opened state channel. As explained by the theory of six degrees of connections, we can connect with anyone else in the world through six degrees of connections. Currently, there are mainly three routing schemes:
3.1.1 Hashed Time Lock Contract (HTLC, Hashed-Time Lock Contract)
Representative project: Lightning Network
The sender sends BTC to the receiver to a 1/2 multi-signature address. If the receiver cannot unlock the BTC within the time specified in the contract by means of "signature + hash ciphertext", then the BTC will be returned to the sender.
As shown in the figure, A wants to send 1 BTC to D through B and C. As the receiver, D first generates a random private key r (equivalent to a key) and public key R (equivalent to a lock), and then sends R to A.
A and B first set up a hash time lock contract, and R is the "lock", where the "time" is 3 days, and the "hash ciphertext" is the private key r that only D knows. This contract means that as long as B can obtain the private key r to unlock R within 3 days, he can get 1 BTC sent by A in the smart contract, otherwise the 1 BTC will be returned to A.
B needs to obtain the private key r to unlock R. According to the same idea, the smart contract between B and C stipulates that as long as C can obtain the private key r to unlock R within 2 days, he can get the 1 sent by B in the smart contract. BTC, otherwise the 1 BTC will be returned to B.
Finally, the smart contract between C and D is the same, as long as D can unlock R with private key r within 1 day, he can get the 1 BTC. It is equivalent to D exchanging private key r for 1 BTC "advanced" by C, C gets the private key r and then uses it to unlock and exchange for 1 BTC "advanced" by B, and then B uses r to unlock A's 1 BTC.
That is to say, D first generates the "lock" and the corresponding "key", and then the lock is passed to A, B, and C in turn; after D receives the BTC, the "key" is passed to C, B, and A in turn. In this way, several nodes realize the safe transfer from A to D without trusting each other. In actual operation, intermediate nodes will receive additional service fees as economic incentives (this also means that the more intermediate nodes passed, the higher the service fee).
3.1.2 Virtual Channel (Virtual Channel)
Representative project: Perun Network
As shown in the figure, both A and B have opened up state channels with I, which are channel X and channel Y respectively. Now A and B send an application to the intermediate node I through the smart contract to establish a virtual channel Z between A and B (shown by the dotted line).
A has locked Z(A) tokens on channel X, and correspondingly I has locked Z(A) tokens on channel Y;
B has locked Z(B) tokens on channel Y, and correspondingly I has locked Z(B) tokens on channel X.
After locking, it is equivalent to establishing a virtual channel Z between A and B, and the corresponding available quotas of A and B in this channel are Z(A) and Z(B) respectively. If A wants to transfer 1 pass to B, 1 pass will be added to the left side of I, and 1 pass will be reduced on the right side at the same time, and the reduced 1 pass will be transferred to B. The effect achieved is similar to that of a martial arts novel In the "fighting cattle across the mountain", A transfers 1 token to B through I as a "springboard". Virtual channels can also be further expanded to form larger networks.
Compared with the hash time lock contract scheme, the intermediate nodes of this scheme do not need to be involved in every transaction, and only need to be automatically executed through the smart contract, so it is more private and low-latency, but it requires the intermediate nodes to lock a sufficient number of Pass to provide "intermediary services" at both ends of the virtual channel. For example, in the above example, the I node needs to lock at least Z(A)+Z(B) tokens.
3.1.3 Meta Channel
Representative project: Counterfactual
The scheme is similar to the virtual channel, but the structure is slightly different. For example, Counterfactual, after instantiating the general state channel, establishes the proxy state channels of A and I, B and I respectively, and establishes the payment channels of A and B on this basis to achieve the same effect as the virtual channel.
3.2 Channel balance problem
In the state channel network, using the routing strategy of the shortest path of the traditional computer network will cause the channel to be unbalanced, which in turn will make the routing strategy invalid, and the pathfinding encounters a "dead end" and cannot effectively transfer value. As shown in Figure 8, the two-way state channel composed of three nodes A, B, and C uses the shortest path to make the available pass of the node in a certain channel become 0, and the two-way channel becomes a one-way channel. The upper left figure is the balanced state, corresponding to the two-way channel shown in the lower left figure. The certificates in the upper middle picture and the upper right picture are concentrated to one side, corresponding to the one-way channels in the lower middle and lower right respectively.
Celer Network proposes a backpressure (BackPressure) routing algorithm, which measures the degree of congestion and channel imbalance of the local network in each time slice, and then performs routing transfer in the direction with the largest backpressure weight, reducing network congestion while achieving channel balance. After testing a payment network composed of 77 nodes and 254 state channels, it was found that the performance of the backpressure routing algorithm was 15 times higher than that of the Lightning Network’s shortest path routing algorithm, and the channel utilization rate was 20 times higher.
Liquidity Network proposes a Revive protocol that allows off-chain rebalancing of payment channels. The protocol rebalances the amount of token assets of each node in multiple channels by enabling a group of payment channel nodes to execute a set of transactions, preventing the formation of one-way channels. The tree-shaped network structure shown in the left figure below cannot be rebalanced, while the network shown in the right figure adopted by Revive contains a ring structure, which can realize the distribution of tokens of nodes in multiple channels from centralized to uniform again. For example, B has 200 tokens in the channel formed with D, and 0 tokens in the channel formed with E. For the right picture, it can be re-deployed through the (B, D, E, B) ring structure , so that there are 100 tokens in each of the two channels composed of B and D, B and E.
3.3 Node offline problem
As mentioned above, the state channel is an interaction under the chain and liquidation on the chain. Any party can close the state channel to achieve the final liquidation and delivery. When both parties are online at the same time and reach an agreement, instant finality can be achieved. But when one party is offline, or the other party launches an attack (such as DDoS attack, destroying the network cable, etc.) to make it offline, and submits a non-final state that is beneficial to itself to the chain, once the offline party misses the arbitration period, the final liquidation result will be It will cause asset loss to the offline party and damage the fairness and security of the state channel.
In this case, people think of outsourcing monitoring tasks to third parties, such as Lightning Network monitors (Monitors), Pisa caretakers (Custodians), Celer Network's State Guardian Network (State Guardian Network).
Monitors obtain rewards through proof, Custodians obtain regulatory opportunities through pledge security deposits, State Guardian Network is a side chain similar to Plasma composed of state guardians, CELR pass (the pass in the Celer Network network) holders pass mortgage The token becomes the guardian of the off-chain state, and the more tokens are mortgaged, the greater the probability of being delegated to guard the off-chain state task, and thus the greater the probability of obtaining more benefits.
With the development of off-chain expansion and large-scale commercial use, through the design of a reasonable third-party economic incentive mechanism, it will bring opportunities for layer-2 service providers.
3.4 Margin lock problem
The routing scheme mentioned in Chapter 3.1, whether it is a hash-locked contract, a virtual channel, or a meta-channel, requires an intermediate node to "advance" funds or lock a deposit. The larger the network size, the larger the average transfer amount, and the larger the security deposit locked in the entire network, the higher the resulting opportunity cost.
The following figure shows the economic model of Celer Network, which is mainly composed of liquidity fund support auction mechanism (LiBA, Liquidity Backing Auction), liquidity fund guarantee mining mechanism (PoLC Mining, Proof of Liquidity Commitment Mining) and off-chain state guardian network three Partial composition. Among them, the PoLC Mining mechanism is a key source of liquidity funds for the Celer network. Simply put, it collects idle funds from liquidity providers through pledge guarantee contracts, similar to how banks obtain funds from depositors, and then serve state channels through the LiBA mechanism. Suppliers provide liquidity funds, similar to bank lending.
Liquidity Network is based on NOCUST's multi-party payment center, which reduces capital lock-up by pooling and sharing mortgage funds. The Lightning Network requires 100% collateral for all transactions, and the collateral is isolated from each other and has poor liquidity.
secondary title
4 Comparison of state channel and other expansion schemes
4.1 Comparison with on-chain expansion solutions
Compared with the on-chain expansion scheme, the state channel cleverly separates the on-chain and off-chain functions. Adopting this scheme does not need to change the structure of the public chain, and combines the security and decentralization features on the chain and the scalability of the off-chain , but from the perspective of the overall ecology, due to possible problems in the communication process between the chain and the chain, the state channel is still a new balance of security, decentralization and scalability.
4.2 Comparison with other off-chain solutions
Note:
Note:
Due to some reasons, some nouns in this article are not very accurate, mainly such as: general certificate, digital certificate, digital currency, currency, token, crowdsale, etc. If readers have any questions, they can call or write to discuss together.
This article was originally created by TokenRoll Research Institute (ID: TokenRoll). Unauthorized reprinting is prohibited. For reprint, please reply to keywords in the background【Reprint】
