Breaking through the impossible triangle of the blockchain (5): Lightning Network, off-chain technology, and their limitations

Author: maxdeath, Click "breakthrough Block Chaining impossible triangle" series

Finally, we have passed the "loach" of "scalable" technology and come to the infinitely scalable technology that looks very beautiful.

In scalable technology, we introduced two ideas of scalable POW-leader selection and DAG, and the idea of ​​scalable BFT. We also analyzed the three-stage consensus of HotStuff BFT in detail. Then, from the perspective of the output, we find that both of them reach the same message complexity of O (N). Therefore, if a relatively new and well-designed algorithm is used on the output, both should eventually Limited by the upper limit of network transmission, for example, in a network with a number of nodes of the order of 10 ^ 2, a TPS of the order of 10 ^ 3 can be reached without substantial differences.

In the end, the most essential difference between the two is 1) that POW-like can be used for non-permitted networks, and BFT algorithms need to be used for permission, that is, participating in networks known to consensus nodes; 2) the type of consensus reached by the two, To be precise, the degree of "consistency" is different. The Satoshi consensus achieves probability consensus, while the BFT consensus achieves absolute consistency.

• The halving market disappeared and the risk aversion property became empty, and there was only one Bitcoin price support
• How to understand ETH2.0: start with understanding terminology
• Will Bitcoin become a value storage tool, and how much global demand is there for Bitcoin in the future?

Of course, it must be clear that the classification I made in this series of articles is based on the main line of "scalability" or message complexity, rather than according to permission / non-permission, or consensus type, So in fact, when it comes to algorithms, not all POW-based algorithms are non-permissive algorithms or have the same probability, which requires attention.

The above is a review of previous articles, and the following officially enters the infinite expansion section.

——————————————————————————————————

Fundamentals of Lightning Network

Let's talk about off-chain technology first.

The origin of off-chain technology is a 2015 white paper:

https://lightning.network/lightning-network-paper.pdf

This describes a technology called the "Lightning Network", which allows two nodes to lock a sum of money on the chain to open a payment channel, and then both parties can be off-chain, that is, without having to transfer transactions to the Method for fast and instant confirmation of transactions, as long as the total amount of each transaction is less than this locked value.

Let me first explain how this is achieved:

1. First, Alice and Bob want to establish such a fast payment channel, so the two first draft a mortgage transaction (Funding Tx). The format of this mortgage transaction is: "Transaction name: F; Input: Alice: 100 yuan, Bob : 100 yuan; Output: Alice + Bob 200 yuan. ”Here, Alice + Bob is the joint signature of Alice and Bob. This transaction can be generated by both Alice and Bob under the chain without trusting each other (for students who are interested in specific details, please refer to the white paper). But note that at this time, the two parties have not signed the input of the transaction, because if the mortgage transaction is really generated, then if the other party disappears at this time, the money cannot be returned.

2. Then, the two parties will start to construct the next commitment transaction (Commitment Tx). The transaction format constructed by Alice is: "Transaction name: CA; Input: Alice + Bob 200 yuan; Output: Alice + Bob: 100 yuan, Bob : 100 yuan ", and the transaction format constructed by Bob is:" Transaction name: CB; Input: Alice + Bob 200 yuan; Output: Alice + Bob2: 100 yuan, Alice: 100 yuan ", where Alice2 and Bob2 are privately owned The other address of the key. Both promised transactions will point to a transaction that has not yet been released, so if the previous transaction is not released, then these two transactions are currently illegal.

3. Next, the two parties separately construct a refund transaction (Refund Tx) that points to the committed transaction. The transaction format constructed by Alice is: "Transaction name: RA; Input: Alice2 + Bob 100 yuan; Output: Alice: 100 yuan, delay : 1000 blocks ", and the transaction format constructed by Bob is:" Transaction name: RB; Input: Alice + Bob2 100 yuan; Output: Bob: 100 yuan, Delay: 1000 blocks ". The delay of 100 blocks here means that the miner determines the interval between the transaction and the transaction to which it points. Only after 1000 blocks can the miner consider the transaction to be legal.

4. Next, the two parties exchange the promised transaction and the refund transaction constructed, and sign the transaction of the other party. Take Bob as an example, Bob will receive Alice's transaction "Transaction name: CA; Input: Alice + Bob 200 yuan; Output: Alice2 + Bob: 100 yuan, Bob: 100 yuan" and "Transaction name: RA; Input: Alice2 + Bob 100 yuan; output: Alice: 100 yuan, delay: 1000 blocks ". Bob will sign the signed part of the two transactions and send the transaction back to Alice. Note that at this time, since the first mortgage transaction has not been signed, all subsequent transactions are still illegal, and any problems that occur at this stage will not really affect the money of both parties.

Alice sends two transactions to Bob, and Bob signs the name and sends it back to Alice

5. After both parties confirm that they have received the transaction signed by the other party, they can sign and chain the mortgage transaction: Let ’s take Bob as an example to look at the logic here – Bob holds Alice ’s signature in his hand at this time. Your own promised transaction "Transaction name: CB; Input: Alice + Bob 200 yuan; Output: Alice + Bob2: 100 yuan, Alice: 100 yuan" and Bob's refund transaction signed by Alice: "Transaction name: RB; Input: Alice + Bob2 100 yuan; Output: Bob: 100 yuan, Delay: 1000 blocks ". At this time Bob does not worry about the safety of his 100 yuan, because if he wants, he can announce these two transactions and get back the 100 yuan after 1000 blocks. At the same time, Alice can't take the 100 yuan, because if Alice wants to get back her money, she must first announce the CA, and the CA will immediately return the 100 yuan to Bob. So far, we have completed the creation of a payment channel for the Lightning Network.

6. So, how to pay? In fact, the two parties are not paying, but both update the current balance status in this channel. We assume that Alice wants to pay Bob 10 yuan, then Alice and Bob need to create a new committed transaction "Transaction name: CA1; Input: Alice + Bob 200 yuan; Output: Alice3 + Bob: 90 yuan, Bob: 110 yuan" and "Transaction name: CB1; Input: Alice + Bob 200 yuan; Output: Alice + Bob3: 110 yuan, Alice: 90 yuan" and the new refund transaction "Transaction name: RA1; Input: Alice3 + Bob 90 yuan; Output: Alice: 90 yuan, delay: 1000 blocks "and" transaction name: RB1; input: Alice + Bob3 110 yuan; output: Bob: 110 yuan, delay: 1000 blocks ", and the signatures are exchanged as before, Finally, Alice sends Bob's private key to Bob to complete the transaction.

7. Alice and Bob now have two account balances that are also approved by each other: 100/100 and 90/110. So, how to restrain Alice from not acknowledging after paying the bill? The answer is the key that Alice eventually sent to Bob's Alice2. If Alice tries to get back 100 yuan with the previous CA, then her only way is to issue the CA first and then the RA, but the RA must be issued after 1000 blocks after the CA to be legal. Then, if Bob finds CA on the chain, that is, "transaction name: CA; input: Alice + Bob 200 yuan; output: Alice2 + Bob: 100 yuan, Bob: 100 yuan", because he already has the key of Alice2 At this time, he can immediately construct a transaction "transaction name: P; input: Alice2 + Bob 100 yuan; output: Bob: 100 yuan" to take away the 100 yuan before Alice.

It can be seen from the above that we can say that the Lightning Network can expand its capacity or provide a channel for off-chain micropayments. In fact, it provides a new form of transaction similar to stored value cards or point cards. With this form of transaction, as long as the two parties agree to lock a sum of money in advance, an off-chain channel can be opened, and an unlimited number of fast-track transactions can be performed off-chain.

Basic principles of HTLC

Of course, everyone can see that the application scenario of this technology is very harsh-an off-chain channel is actually a stored-value card, which is only used by both parties. But the lightning network is actually more than that. The lightning network mentioned above is called RSMC, and then there is an advanced lightning network called HTLC. The implementation of HTLC is more complicated. Here, we only introduce the principle of HTLC.

The full name of HTLC is (Hashed Timelock Contract). The basic principle is: suppose A wants to send 1 BTC to C, but there is no off-chain channel between A and C. However, both parties have an off-chain channel with a Node B (this channel must support HTLC and the balance is sufficient). So, the payee C first sets a puzzle and an answer. In fact, it generates a Y by itself, calculates H (Y) = X with a hash, and sends the hash value Y to A. Then, A and B negotiated an off-chain HTLC based on the Y given: "If B can give the pre-image of Y within 2 days, that is, X, then 1.1 BTC of A can be obtained, otherwise, this contract is invalid." Next, B negotiates with C for an off-chain HTLC: "If C can give the original image of Y within one day, that is, X, then you can get 1 BTC of C, otherwise, this contract is invalid." When both contracts are invalid After the establishment, C gives X and gets 1 bitcoin from B, then, B that gets X gives X and 1.1 bitcoin from A. Here, 0.1 bitcoin is the cost of B as an intermediary (in practice, this cost is obviously not so high). Then please note that the "coin" here is similar to that in the previous Lightning Network. It is not a real coin, but a negotiated distribution agreement. If the parties are willing to change, they can go according to this distribution agreement within a given time. Get your own coins back on the chain, or update the distribution agreement again on the basis of this distribution agreement.

The above is the normal situation, so let's see what happens if there is a malicious node here: first, A has no room for evil, because he can only give money from beginning to end. After the contract is established, C is the beneficiary, so there is no reason not to be willing to provide X to receive the money. And if C provides X, then B has no reason not to use X to collect money from A. This principle applies to situations where there are multiple intermediaries-the recipient will first provide X to get his own money, and then a rational relay node will naturally not be willing to pay this money for no reason, so he will definitely use X from He got money at the last node. Of course, the construction of this payment chain needs to meet a principle, that is, the longer the chain, the more lenient the time set when the initial payment is made, because each node needs to reserve enough time for itself to prevent it from being taken too late from the previous home money–

Added to say that if the agreement between B and C is "If C can give the preimage of Y within 47 hours, that is, X, then you can get 1 BTC of C, otherwise, this contract is invalid." Then, if C is dragged to 47 hours X is given in the last minute of this time. At this time, because A's term is two days, B has only 1 hour left to get "money" from A. Note that the "money" here needs to be quoted because it is still just a "protocol" for transactions in the Lightning Network. B can use this protocol to get money from the chain, but then it needs to close the Lightning Network channel, and B can only get the real "money" after the lock-up period. Therefore, what B needs is to negotiate a new "property distribution agreement" with A through the chain within this hour. Then, if A does not cooperate, B will take the money back on the chain as a "last resort" . Therefore, if B has too little time for himself, it will probably only be able to make a "last resort". Even this choice was too late.

In order to avoid this situation, each node will inform in advance a time it needs to reserve, which is equivalent to "want to pass from me, but in addition to the transaction fee, you have to give me a day of processing time", so, The longer the path, the longer this time will accumulate. But beyond that, we still say this technology is "safe". "Safety" needs to be quoted here. The specific reason will be discussed in the next article.

Limitations of Lightning Network

With HTLC, we have achieved a more ideal state-everyone locks certain funds on the chain, and daily micropayments can be made off-chain through this relay. This method may seem cumbersome, but all these steps are performed off-chain, which is also the origin of the word of the earliest two-tier network-in the eyes of supporters, the ideal state of the blockchain should be the first-tier settlement Network, plus the second-tier payment network.

So, can we say that we have achieved infinite expansion? It looks like there is something wrong. Because from an application perspective, Lightning Network can indeed solve part of the payment scenarios, but on the one hand, we cannot replace all payment scenarios with stored-value cards or point cards. On the other hand, the opponents of Lightning Network are not completely It's alarmist-a network that moves most of the transaction scenarios to the second layer is insecure and fairly centralized. One possibility is that the reduction of transactions in the first layer will reduce transaction fees, affecting the security model of the entire blockchain. If you want to avoid this situation, if you also need to maintain the security of the first layer of the network, then The transaction fee needs to be increased, so that the first-tier network is completely unable to conduct daily transactions. Therefore, this system will inevitably degenerate into a centralized system that requires daily reliance on some large nodes that can afford transaction fees and have high mortgages.

Of course, even so, off-chain technology still looks promising, after all, in reality, we have many payment scenarios in which we need to provide mortgages first, and stored-value cards and point cards are not uncommon in reality. So, is it possible for us to promote this method in the field of cryptocurrencies and in the field of small fast payments?

The answer is difficult. Let's compare the difference between the functions implemented by Lightning Network and ordinary transactions, points cards, and recharge cards.

In essence, blockchain transactions assume that the transaction initiator is rational: the transaction initiator wants to initiate a transaction, such as a payment to buy something, so it is the responsibility of the transaction initiator to prove the success of the transaction to the transaction receiver. Therefore, the transaction initiator needs to be able to provide evidence that the receiver can accept-in a centralized system, this evidence is a transaction confirmation from a trusted third party, and in a blockchain system, this evidence is on the transaction Chain and got confirmed. In order to obtain this evidence, the transaction initiator must either produce the block itself and participate in the consensus process, or send the transaction to the miner, entrust the miner to do this, and then pay a certain transaction fee. In this case, the receiver only needs to memorize his private key and verify that his money is received at one time, so he can rest easy.

The above logic is smooth and very close to the traditional centralized system, but the traditional center is replaced by a miner + blockchain. Therefore, in fact, most of the real-life scenarios can be seamlessly connected to such a system and implemented with a blockchain.

However, Lightning Network transactions need to assume that both the transaction initiator and the receiver are rational. In fact, if you analyze the Lightning Network carefully, you are not trading real money.

In blockchain transactions, a transaction is "A pays B10 dollars."

This transaction is authenticated by all nodes, so it cannot be reversed.

In the Lightning Network, the essence of a transaction is "A pays B 10 points. With these points B can be used: a) and B as money; b) pay a certain fee after one day, and replace 10 dollars; c) If A is found to try to cheat within one day, then A is found to cheat and counteracted in time, and A's 100 yuan mortgage is obtained; d) You cannot counteract A in time within one day, so the points are void. "

The authenticity of this certificate only needs to be verified by B.

Among them, b is equivalent to the function of a stored-value card, and it is a very good and reliable stored-value card. Compared with stored-value cards, the advantage is that first of all, you don't have to worry about the money you don't get back, which is equivalent to not worrying. The other party runs, but you usually need to wait for the agreed time to unlock the money, unless the other party is willing to negotiate a new unlock time with you. But think carefully about the use scenarios of stored-value cards-if it is not because stored-value cards usually have discounts, who would use stored-value cards? But function b does not provide a discount, but only provides the convenience of transactions and low fees. So, the attractiveness of using stored-value cards for ordinary users is greatly reduced.

The above shows that Lightning Network can be used as a stored value card without discount. But the more complicated parts are a, c, and d, which are parts other than stored-value cards-that is, this card can not only store value, but also receive points, and points can be exchanged for money, but although this point rule says The exchange is equivalent to currency 1: 1. In fact, the value of points is not only related to your own ability, but also to the security of the network. In the Lightning Network, the receiver not only needs to verify the transaction results sent by the receiver at one time, but also observes the main chain online from time to time to prevent the transaction initiator from cheating. If the transaction initiator cheats, the transaction receiver needs to initiate a countermeasure to take away the deposit of the transaction initiator.

In summary, the application scenarios of Lightning Network are subject to the following restrictions:

1. Regardless of whether it is used for payment (stored value card) or receipt (points), users need to be very high-frequency traders in order to be willing to pay for the liquidity of transaction fees and the risk that points cannot be converted. However, this must be based on the premise that the Lightning Network transaction fee is lower than the on-chain transaction fee.

2. Users of the Lightning Network need a higher technical threshold-a sum of money received is not insurable, and they must also maintain regular observations on the chain. To be more realistic, the technical threshold of bitcoin can already be deterred by most ordinary users, but after all, after understanding the basic concepts, a bitcoin inactive trader can still use a wallet by himself and remember the mnemonic. Word when it comes to a true "user" of Bitcoin. However, if you want to use Lightning Network, especially if you need to receive money through Lightning Network, then basically you have no choice but to rely on the organization that provides Lightning Network services, because no one can guarantee that they can observe the chain at any time and react in a timely manner. system. then,

3, Lightning Network is not an upgrade without side effects, but another payment option-Lightning Network requires collateral, and redemption of collateral requires higher delay to prevent evil. Therefore, in fact, users who use the Lightning Network actually not only put a sum of money into the Lightning Network for fast payment, but also must voluntarily assume that when you do not need to use this service, you need to exceed the lock-in period to put the money Taking back the liquidity risk, at the same time, you also need to face the risk that the money may not be returned (this we will talk about at the end).

So, what are the application scenarios of Lightning Network? We'll save it for the next part.

Limitations of off-chain technology development

The Lightning Network itself is like opening a door, causing many people to mistakenly think that they have crossed the door, and behind it is a vast and boundless new world. So, with the Lightning Network, many people started to imagine what the second layer network looks like-it should be like the Lightning Network, with an anchor on the main chain to customize the mortgage, and then, in the off-chain world, there should be infinite Possibly, all the scenarios that we can think of on the chain, and even those that we don't know how to move to the chain in reality, can all be implemented off the chain and on the second layer …

However, in fact, behind this door is not a new world, but a dark labyrinth, and door after door.

The technology of Lightning Network is not universal-when it is placed in the transaction scenario, it seems to be natural, because in the transaction we can assume that the transaction receiver is driven by interest (if the chain is not observed regularly) Then the money received by the transaction receiver is gone). But this assumption is only applicable to the scenario where the receiver of the transaction is driven by interest, but not to the general scenario.

Someone may ask-what is this scenario you are talking about?

In fact, there are many such scenarios-such as documentary evidence, such as traceability, such as almost all platforms established based on real evaluations … These scenarios cannot be moved off-chain using technologies similar to Lightning Network, because we cannot find Recipients driven by interest are responsible for consistently observing whether consistency has been tampered with. For example, we can solve the first step of document certification. It is said that the document certification party needs to provide a certificate to a node to prove that the document is indeed documented. But what motivation does the prover have to observe this chain all the time? Or in another scenario, B has deposited a certain document with 100 yuan of guarantees on the chain. Then, if this later becomes the key evidence of a commercial dispute involving several million yuan of interest, will B be What about giving up your $ 100 guarantee?

This is the biggest limitation of Lightning Network and off-chain technology-

First of all, the Lightning Network can only be used in scenarios where participants have interests and are therefore willing to observe the main chain for a long time and counteract the malicious behavior of the other party.

Second, the design of the on-chain deposit is strongly related to the application scenario, so the off-chain technology for each scenario is not universal. It is even said that the existing technology may no longer be safe as the scene increases and changes.

Then someone might say-in fact we have a universal solution:

No matter what the scene, we simply find a node A to put the deposit on the chain, he is responsible for verifying certain things e, and then, if we find that he is evil, we can take his deposit.

However, this introduces a third question-how to define or describe the evil of node A?

In my opinion, an ideal off-chain technology should be able to use smart contracts to achieve the following functions:

For a certain scenario, a node A puts a deposit in a smart contract. He is responsible for verifying certain things e and ensuring that they can be verified in real time, and e correctly proves p (e). Then, if B needs to know the correctness of e and e, they contact A, and A will provide them with e and p (e). If A fails to provide this proof, then B can provide evidence that he "has not obtained the service he needs", record it as p (e, A, fail), and then take the deposit in the smart contract.

This is why the development of the second layer of network technology is difficult.

1. We know that the small payment, that is, the prepaid card scenario, is a very practical and useful scenario, and it can relieve the pressure on the chain. And in this scenario, the Lightning Network seems to be a perfect solution, without relying on a trusted third party, and it is completely secure, because no one will risk the loss of 100 yuan to steal 10 yuan. But for other scenarios, how much the deposit is a suitable guarantee, which is difficult to generalize in itself. We also need to design different guarantee models for different scenarios. If in the end we believe that "a mortgage of a sufficiently large amount is credible", then, in fact, this is no different from the traditional centralized financial system.

2. The hardest part here is that we need to design mathematically provable p (e) and p (e, A, fail) for different events e. And this is difficult to find a universal solution. For example, zero-knowledge proof is the closest technology to this problem. However, the existing zero-knowledge proof schemes are not universal. It is very difficult to prove different problems. At the same time, it is difficult to describe some scenarios mathematically. Therefore, in many cases, we still have to rely on trusted third parties to provide p (e) and p (e, A, fail). And this seems to me to lose most of the meaning of off-chain technology. Because of the same thing, we can compare the following implementations:

We want to be able to verify the authenticity of an event e.

1) Centralized solution: An authoritative organization or a trusted third party verifies it and is responsible for providing a statement s (e) that the event is true.

2) Alliance chain scheme: Some authoritative organizations verify it and put forward a statement that the event is true s (e), reach a consensus through a BFT consensus algorithm, and release it on the chain. As long as more than 2/3 of the institutions are reliable, then e is true.

3) Public chain scheme: The miner verifies it and proposes a statement s (e) about the event being true, reaches a consensus through a consensus algorithm, and releases it on the chain. As long as more than 1/2 of the computing power / equity / mortgage / selected nodes … are reliable, then e is true.

3.5) Mortgage-based POS solution: The miner verifies it and puts forward a statement that the event is true s (e), reaches a consensus through a consensus algorithm, and releases it on the chain. As long as more than 1/2 of the nodes that are mortgaged are reliable, then e is true.

4) True · off-chain solution: A miner A performs a partial mortgage on the chain, verifies e, and provides proof that e is true p (e). If the miner's verification is incorrect or cannot provide p (e) when needed, others can use p (e, A, fail) to take A's mortgage. If p (e) and p (e, A, fail) are reliable, we guarantee that if the value of e is less than the mortgage, then e is real.

5) Pseudo-off-chain solution: A miner A performs a part of the mortgage on the chain, verifies e, and provides a proof p (e) that e is true and passed the trusted third-party T authentication . If the miner's verification is incorrect or cannot provide p (e) when needed, others can obtain p (e, A, fail) through a trusted third party T and take away A's mortgage. Then, if a trusted third party is reliable and the value of e is less than the mortgage, then e is real.

The limitations of the off-chain solution are obvious through the comparison of the above schemes:

If for a scenario where the profit for evil is strictly less than the mortgage and there are mathematically provable p (e) and p (e, A, fail), the true off-chain solution is very meaningful.

If the evil profit cannot be accurately estimated, or for general-purpose scenarios, then using a mortgage off-chain solution, compared to a mortgage-based POS solution, is equivalent to reducing the security of e from the entire chain's 1/2 mortgage to A mortgage of a node. Correspondingly, the output has also been improved accordingly, because this transaction is no longer verified by all miners participating in the mortgage, but only verified by A.

If there is no mathematically provable p (e) and p (e, A, fail), then the off-chain solution is actually just a more complex solution to implement an authentication or arbitration system that depends on a trusted third party.

————————————————————————————————

This article has been written for a long time, and the writing is too long, so it is divided into two articles. The second half will be posted in these two days.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!