Blockchain Privacy Protection (2): Privacy Protection Mechanism at the Network Layer

• Blockchain Privacy Threats

         In the previous article, Blockchain Privacy Protection (1): Privacy Protection Mechanism at the Transaction Layer, we divided the blockchain privacy threats into three aspects: 

        Threats to privacy at the network layer    

             Malicious nodes can easily access the network and monitor the communication data at the network layer.    

             ·Channel isolation mechanism

       · Privacy Threats at the Transaction Layer  

            · Transaction privacy threats.    

            · Identity privacy threats.

       · Privacy threats at the application layer  

            ·Privacy leakage caused by user behavior and blockchain service providers.

       The last article mainly summarizes the privacy threats at the transaction layer. Here, we mainly analyze the privacy threats at the network layer. The effective way to deal with this threat is channel isolation technology.

• channel isolation mechanism

       First, a general introduction to channel isolation technology .

       The channel isolation mechanism isolates data from the network level, and protects the data only visible to the nodes in the channel. By isolating the ledger, each node only processes and stores the data of its own channel, preventing attackers from accessing the data, thereby protecting user privacy. However, the channel mechanism also has certain defects. The main one is that there is a certain cost in deploying channels in the blockchain network. Node creation and entry and exit of channels need to modify the network configuration, and the flexibility is relatively weak.

       Then, according to the storage location of the isolated data, channel isolation technology can be divided into two categories: off-chain channel isolation and multi-chain channel isolation .

• Off-chain channel isolation

        Off-chain channel isolation is mainly used in high-frequency small-value transactions. It creates a channel by recording the initial state on the blockchain, and then conducts transactions off-chain. The specific data is guaranteed by the contract, but intermediate transactions are not published. Recorded on the blockchain, when the transaction needs to be aborted, the latest end state is published on the blockchain, and then the channel is terminated and the historical transaction record is destroyed.

• Multi-chain channel isolation

        Multi-chain channel isolation is to build an independent communication network as a channel between specific nodes. The information of each network is stored separately in the corresponding sub-ledger, non-channel nodes cannot access, and the same node can join multiple different channels. In short, multi-chain channel isolation is to build a sub-network at the network level to achieve node communication isolation and prevent attackers from accessing private information, thereby protecting user privacy.

• Off-chain channel isolation

        First of all, let’s introduce the off-chain channel isolation technology. It appeared to solve the problem of limited blockchain ledger capacity. The researchers tried to place small-amount high-frequency transactions on the off-chain micropayment channel, and only started and ended the channel. Information is recorded on-chain. The realization of the off-chain channel isolation technology is mainly divided into two steps: first, the off-chain two-party payment channel is constructed between the two nodes; then, the payment network is constructed through the existing two-party payment channel between the nodes.

• Implementation steps  

        1. Two-party payment channel: The construction of the two-party payment channel is to build a trusted off-chain payment channel between two addresses. First, the assets are escrowed to the on-chain contract to create a payment channel, and then both parties sign the status update to confirm the transaction. The specific transaction process does not need to be recorded on the blockchain. If a party wants to interrupt the channel, after both parties agree, they only need to publish the latest state to the blockchain and redeem the assets corresponding to the latest state.

        2. Build a payment network: If a two-party payment channel is constructed between all participating users, it will lead to a huge waste of storage resources. Therefore, on the basis of the two-party payment channel, users can use the existing two-party payment channel. Make payment, that is to say, you can use the existing two-way payment channels of other nodes to transfer, and conduct transactions with the destination node, so as to build a payment network among all users.

• Typical technology

       Typical off-chain channel isolation technologies include Bitcoin's Lightning Network technology and Ethereum's Raiden Network technology. Among them, the Lightning Network is based on the unspent transaction output model, that is, the UTXO model; the Lightning Network is mainly based on the account balance status model, and will make more use of the on-chain contract mechanism. These two techniques are described below.       

• Lightning Network

       The first is Lightning Network. Its core idea, as mentioned just now, is to complete some frequent small-value transactions off-chain by establishing a state channel, thereby reducing the transaction pressure on the main chain.

       Therefore, the core of Lightning Network is to establish a safe and feasible off-chain payment channel, and at the same time, it combines multi-signature address technology, RSMC sequence expiration revocable contract, HTLC hash time lock contract and other technologies to complete off-chain payment settlement and confirmation. This in turn improves the efficiency of user payment. It mainly uses RSMC to realize the payment channel of both parties, and then further builds the payment network through HTLC. This design not only improves the performance of the Bitcoin system, but also hides the micropayment information between users and protects user privacy.

       However, the Lightning Network also has some shortcomings, mainly in four points:

          There are differences in the community's recognition of Bitcoin's payment attributes

          ·Bitcoin has limited micropayment scenarios

          · There are hidden dangers in security

          Lightning Network technology is not yet fully mature

• RSMC contract

       First, let's introduce one of the core technologies of the Lightning Network - the RSMC contract.

       The Chinese name of RSMC is the serial expiration revocable contract. As the name suggests, it is a revocable contract with execution conditions. Its execution condition is that the height of the block where the contract is located is a sequence number greater than the height of the block where the parent contract is located. This serial number is a parameter of the contract and can be set by yourself. For example, the sequence number of an RSMC is 1000. If its parent exchange is in block 10000, and if the RSMC is written before block 10999, the RSMC will not be executed (equivalent to being automatically invalidated). In order to ensure that this RSMC can be executed, it is necessary to broadcast this RSMC in the network when the current block is 11000. In this way, the height of the block where the RSMC is located must be greater than 11000 to execute.

       Beyond that, for an RSMC to work, it must first broadcast its parent transaction on the Bitcoin network, and then broadcast itself. For example, the picture on the left is an example of RSMC. The blue box in the figure represents the transaction only for Bob, while the purple box represents the transaction only for Alice, and the green box is the capital injection transaction. The channel's funding transaction has two outputs, confirmation transactions C1a and C1b. The two transactions are mutually exclusive, and only one can be broadcast on the Bitcoin network. These two transactions are also asymmetric, with different content and different ownership, that is, Alice can only broadcast C1a, and Bob can only broadcast C1b. Each confirmed transaction has two outputs, one is the normal output and the other is the RSMC contract. D1a is a common output, and Bob can get 0.5 bitcoins from this output; RD1a is an RSMC contract whose parent transaction is C1a. When C1a is broadcast to the Bitcoin network, and after 1000 block confirmations, Alice can broadcast this RSMC to get 0.5 bitcoins.

• HTLC contract

       · Hash value locking , which ensures that only the password R generated by the final receiver can be unlocked and the frozen assets can be obtained.

       Time - locked , which ensures that the transferor cannot take the bitcoins within a certain period of time (before the final receiver unlocks and takes the bitcoins), and also ensures that the transferor cannot take the bitcoins after a period of time if the final receiver does not take the bitcoins. You can get your bitcoins back.

        As shown in the figure, A wants to send 1 BTC to C, but there is no micropayment channel between A and C. But it doesn't matter, A finds a payment path from B to C, which consists of two micropayment channels from A to B and B to C in series.

        So how to do it? First, C generates a secret R and sends Hash(R) to A, A does not need to know R. Then, A and B agree on an HTLC contract: as long as B can show A the secret R within 2 days, A will pay B 1BTC; if B cannot do this, the money will be automatically returned to A after 2 days. Similarly, B and C agree on an HTLC contract: as long as C can show B the hash preimage R within 1 day, B will pay C 1 BTC; if C fails to do so, the money will be automatically refunded to B when it expires.

        After everything is in place, C discloses R to B within 1 day, and gets his share of 1 BTC; now that B knows R, he only needs to show the password R to A within 2 days and get 1 BTC.

        The whole process is easy to understand. If the entire lightning payment network does not charge handling fees, the final effect is that A pays 1BTC, and C gets 1BTC safely, and all the actions in the process take place outside the blockchain.

• Two-way payment channel

        So how to build a two-party payment channel and payment network through RSMC and HTLC?

        First, a bidirectional payment channel is constructed through a serial expiry revocable contract (RSMC). The feature of publishing on the Bitcoin ledger only when the contract is created and terminated to protect user privacy. The figure above shows a specific RSMC creation and payment process.

        1. Asset custody stage: User A and User B each take out part of the assets and escrow to the account signed by both parties. The expenditure of this account needs to be signed by both parties. Thereafter, the payment channel cannot spend more than the total amount of escrow assets in the payment phase. But both parties do not sign the escrow transaction nor broadcast it to the blockchain.

        2. Constructing the channel stage: User A constructs a commitment transaction C1a (commitment transaction 1a, referred to as C1a) and a revocable payment transaction RD1a (revocable delivery 1a, referred to as RD1a), and sends them to User B for signature. The C1a transaction is used to ensure that Bob can get his escrow assets in the event that User A unilaterally terminates the channel. RD1a is used to ensure that User A can unilaterally retrieve the assets under its custody. This transaction has a delay setting, if C1a is recorded in the nth block, then RD1a can only be recorded in the n+1000th block after. Bob constructs the commitment transactions C1b and RD1b symmetrically, and sends them to Alice for signature. After both parties have signed and exchanged the commitment transaction and the revocable payment transaction, the contract is established.

        3. Payment stage: When user A wants to pay another 0.1 unit of assets to user B, the status represented by C1a and RD1a needs to be invalidated, and user A constructs and signs the breach remedy transaction BR1a (breach remedy 1a, referred to as BR1a) and  sends it to user B . This is to prevent a situation where one party still broadcasts the old transaction after the newly confirmed transaction. What are the consequences of this situation? If there is no violation remedial transaction, user A paid 0.1 new assets to user B before, ideally at this time, the new distribution is 0.4 for user A and 0.6 for user B, but user A can choose not to broadcast the new transaction C2a, and use the previous old Transaction C1a is broadcast to the Bitcoin network, so User B gets 0.5 Bitcoin immediately. After C1a broadcasts 1000 blocks, user A broadcasts RD1a again, so that 0.5 bitcoins can be obtained. At this time, the distribution is user A 0.5 and user B 0.5. It can be seen that user B suffered a loss, which is equivalent to that user A did not pay in this latest transaction. Therefore, the violation compensation transaction is used to replace the RSMC in the old confirmed transaction. If one party broadcasts the old transaction, the counterparty can immediately obtain all the remaining funds in the violation compensation transaction. In the left figure, at the same time as the new confirmed transactions C2a, C2b are generated, the violation compensation transaction BR1a is generated, which invalidates the RD1a transaction in the old transaction. If user A still chooses to broadcast C1a in the old transaction, then user B immediately obtains 0.5 bitcoins from output1 of C1a, and then user B obtains the remaining 0.5 bitcoins from output0 of C1a, namely BR1a. At this point, RD1a has no meaning, because all the bitcoins in C1a have been distributed. It can be seen that after adding the violation compensation transaction, the update of the confirmed transaction is safe. For both parties to the transaction, either choose to broadcast the latest confirmed transaction, thereby closing the channel, or broadcast nothing and let the channel continue to run. Then, according to the steps in the construction channel stage, the two parties reconstruct the commitment transactions C2a, C2b and the revocable payment transactions RD2a, RD2b according to the balance distribution after payment, and complete the state change.

       4. Ending stage: When either user wants to end the contract, it announces the commitment transaction first. If the other user does not announce the default remedy transaction within the delay time, it means that the commitment transaction is final, and the user can wait for the delay time. Announcing a revocable payment transaction to retrieve assets.

• Build a payment network

       Sequence expires revocable contract RSMC can only build two-party payment channels, which will lead to huge waste of storage resources and assets. Therefore, HTLC can help two users who have not established RSMC to pass the middleman on the basis of the two-party payment channel. Establish a transaction channel to build a payment network among all users. As shown in the figure, when there are RSMCs between AB, BC, and CD respectively, AD can complete the payment through the existing channel. The specific process has been introduced in the HTLC contract, and will not be repeated here.

     To sum up, Lightning Network technology ensures the asset security of off-chain payment channels through RSMC, and then reduces the number of RSMCs required in the network through HTLC to enhance the scalability of Lightning Network. Using Lightning Network technology, the transaction data between users will not be recorded on the blockchain ledger, which eliminates ledger analysis attacks and greatly ensures the privacy and security of users' ledger.

• Major flaw

1) There are differences in the community’s recognition of Bitcoin’s payment attributes

         The intrinsic value of Bitcoin is mainly manifested in two aspects, one is a store of value similar to digital gold, and the other is an electronic cash payment tool. A considerable number of users in the community are more inclined to the value storage attribute of Bitcoin, and Lightning Network, as an off-chain expansion method, hopes that Bitcoin can perform the function of electronic payment currency, which runs counter to the mentality of many users.

2) Bitcoin has limited micropayment scenarios

       Although the Lightning Network improves the transaction speed of Bitcoin transfers through off-chain expansion, it does not directly improve the Bitcoin cash payment scenario. If Bitcoin wants to be an electronic payment currency, it must have one of the basic properties of money: the intrinsic value is relatively stable over a period of time. On the contrary, the price of Bitcoin often fluctuates greatly, and the price of a single coin is also relatively high, which makes the overall willingness of users to use Bitcoin micropayments to buy goods or services is not high. Because even with Bitcoin supported by the Lightning Network, in the micropayment scenario, it still cannot compare with the convenience of fiat currency, and even compared with the stable currency USDT, it is difficult to have a competitive advantage. It is difficult for users to have the motivation not to use fiat currency that is convenient, safe and stable in value, but to use Bitcoin for daily micropayments. Therefore, the limited micro-payment scenarios of Bitcoin also directly lead to the lack of willingness to use the Lightning Network to pay for Bitcoin.

3) There are hidden dangers in security

        In recent years, the security risks of the Lightning Network have attracted everyone's attention. In August 2019, Lightning Network developer Rusty Russel stated that the old version of the Lightning Network software has serious vulnerabilities. If users do not update, they may lose Bitcoins.

       Since the transactions in the Lightning Network channel are all processed off-chain and involve intermediary routing, the transaction data of both payment parties are easily exposed by hacker attacks. The Lightning Network requires nodes to remain online when making payments. If a node goes offline when a user is making a payment, the user will be unable to pay or the funds will be frozen.

4) Lightning Network technology is not yet fully mature

       There are still many problems to be solved in the Lightning Network, such as node disconnection, routing design, node centralization, security, privacy exposure, etc. The proposed technical solutions include Watchtowers, Atomic Multi-Path Payments , Submarine Swaps, neutrino protocol Neutrino, etc. are still waiting for landing verification.

• Raiden Network

         Lightning Network was born to solve the congestion of Bitcoin, and Ethereum also has its own "Lightning Network", its name is Raiden Network. Even, in addition to the Raiden network, Ethereum has other similar technologies. We can collectively refer to Lightning Network, Raiden Network, and other similar technologies as "state channel technologies". Raiden Network draws on the technical concept of Lightning Network, and the key technologies are also consistent with Lightning Network, including RSMC, HTLC and other technologies. However, the Raiden network also has some design features in combination with the characteristics of Ethereum. Based on the smart contract mechanism of Ethereum, it provides a more convenient off-chain payment channel. The Raiden Network is also divided into two parts: building a two-party payment channel and a multi-party payment network, which simplifies the implementation of RSMC (Sequence Expiration Revocable Contract) and HTLC (Hash Time Lock Contract) in the Lightning Network.

      ·design feature

           ·Smart Contract

           ·Combination lock

      · Implementation steps

          · Two-way payment channel (smart contract)

          · Build a payment network (combination lock)

     ·Major defects

         · Offline problems

         ·Pathfinding problem

• Two-way payment channel

     The payment channel in the Raiden network is mainly divided into several stages: contract construction, balance proof, off-chain payment, and contract cancellation:

      In the contract construction phase, participants create smart contracts for specific channels and publish them on the blockchain ledger;

      In the balance proof stage, the transaction parties in the channel transfer money to the contract account as asset mortgage. After that, the transaction amount in the channel cannot exceed the amount of assets certified. This is to ensure that both parties have the ability to repay their debts. After the proof is completed,

      In the off-chain payment stage, both parties of the transaction sign a new balance certificate by updating the transaction status according to the format specified in the contract to complete the off-chain payment, and each status message is appended with an increasing serial number. Each time the Lightning Network records a new balance state, while the Raiden Network records updated asset changes.

      When a party wants to interrupt the payment channel, it stops signing new status messages and sends the current status message to the smart contract. Within a certain period of time, if the contract does not receive a status message with a larger serial number, the contract will be revoked, and assets will be returned to each participant's account according to the latest accepted status message.

      As shown in the figure, in step 1, user B first pays 3 coins to user A; in step 2, user A pays 1 coin to user B; after that, user A tries to use the balance proof in step 1 to close the channel, and in the User B provides a new balance certificate within a limited time to ensure that the final balance distribution is carried out in accordance with the latest state.

• Multi-party payment channel

        Another problem with Lightning Network is that HTLC has the risk of intermediary users colluding with payee users, compromising the security of the payer’s assets. For example, the secret R of the HTLC contract is generally set by the payee, and then the hash value of R is provided to the payer. people. However, there are certain problems in doing so. In the transfer, if A wants to temporarily change the path, he does not want to transfer money through B. Or B is offline and cannot transfer money, and A has to change the path. After changing the path, before the last HTLC contract expires, B and C may collude, that is to say, after C gets the tokens from the new path, C discloses R to B, so that A is locked in the old path. Coins are transferred to B, causing losses.

        The developers of Raiden Network considered setting up a combination lock composed of three locks for the lock to solve this problem. include:

        (1) Retry hashlock. The secret for the retry hash lock is provided by the payer and may be regenerated by the payer. Regeneration is generally when the payer wants to change the path.

        (2) Receipt hashlock (receipt hashlock). The secret of the receipt hash lock is provided by the payee.

        (3) Time lock, which is used for the lock expiration time controlled by the payer.

        To unlock the transfer before expiration, you need to retry the two secrets of the hash lock and the receipt hash lock, which can be called secretR and secretE.

        After the transformation, take A to transfer money to C through B intermediary as an example, the new transfer method is:

        (1) Payee B sends the receipt hash lock to A, and keeps secretE of the receipt hash lock.

        (2) Payer A uses the receipt hash lock and its own retry hash lock to construct the transfer to B, and A keeps secretR.

        (3) B constructs a transfer to C according to the same lock.

        (4) After A confirms that the above transfer is constructed, it provides secretR to C.

        (5) C owns secretR and secretE, shows it to B, unlocks the transfer, and obtains tokens. B also learned two secrets, showed it to A, unlocked the transfer, and obtained tokens.

      The advantage of this is that as long as A does not provide secretR, C cannot provide secret to transfer intermediary B in the middle of the transfer, causing A to suffer capital losses.

• Major flaw

       Then let's talk about the main flaws of the Raiden network.

        The first is the offline problem: when the Lightning Network ends the channel, both parties can sign a transaction to divide the coins in the multi-signature address, so that it can be gathered and dispersed. But in the Raiden network, each Raiden transaction between the two parties requires the signature of both parties, but the serial number will increase each time. When the channel is finally ended, the two parties have only one way, that is, one of them submits the information of the latest serial number. To the smart contract, and then split the currency through the smart contract (because it cannot be like a lightning channel, both parties can sign directly to initiate on-chain transactions). Now comes the problem. If A transfers coins to B in the last Raiden transaction, but A submits the information of the penultimate transaction to the contract, then A will take B’s coins. In order to avoid this problem, after the information is broadcast, a lock time will be set. If the lock time expires and B does not provide updated information, then the coins will be divided according to the information submitted by A. But if B happens to be disconnected, there is obviously updated information, but there is no way to submit it? Then there's no way. So, this is a big risk when using the Raiden network, be sure to stay online.

       The second problem is a path finding problem. The increase in the number of users will make it difficult to select a route, and the increase in the length of the path will cause some users to go offline, which will bring more serious consequences.

       The above two problems also have a more convenient solution, that is, the payment center. Through a number of payment centers that maintain channels with a large number of nodes, the problem of path finding can be greatly saved, and the possibility of offline transfer intermediaries can be reduced, because the payment center is often online due to economic incentives. However, it still cannot solve the risk of the payment center closing the channel when the ordinary node is offline. In addition, there is also the management risk of the payment center. Because if the payment center closes all channels for some reason at the same time, the gas consumption of the blocks on the chain is very large, which may cause congestion.

• Multi-chain channel isolation

 

         Both the Lightning Network and Raiden Network described above belong to off-chain channel isolation. The multi-chain channel isolation technology maintains multiple blockchain ledgers in the same blockchain system, in which different node groups maintain specific sub-blockchains, and the data privacy and security of the sub-blockchains are guaranteed by setting an access control mechanism. At present, the relatively mature multi-chain channel technology is mainly the channel technology of the HyperLedger Fabric project. The channel technology mainly protects the privacy and security of internal data by independently building blockchains between the internal nodes of different teams. It is equivalent to the same blockchain ledger. Split into multiple shards for maintenance, each shard is only responsible for maintaining different account information and transaction data, and does not need to verify the global ledger information. If necessary, communication between shards is required. Multi-channel technology is used in different The nodes build mutually isolated channels and maintain their own independent ledgers. There is no need to communicate between different channels, so user privacy data is more protected.

        In practical application scenarios, different nodes have different off-chain identities and need to fulfill different business requirements, so different teams will be formed to cooperate according to the business. In order to protect the privacy data between nodes within the same team, the multi-channel technology The internal nodes of different teams independently build blockchains, maintain ledger data, and protect the privacy and security of internal data. Multi-channel technology mainly includes these three mechanisms:

        Identity management : Manage the identity authorization and authentication mechanism of each node, and nodes with different identities have corresponding permissions.

       ·Channel management : Manage the entire life cycle of channel establishment, maintenance, and destruction.

       Transaction management : Manage the publishing, sorting, recording and other operations of transactions within the channel.      

        Channel isolation technology isolates messages at the network level and protects user privacy by limiting the spread of messages. In a permissionless chain system, the blockchain ledger is open to all nodes. Therefore, channels mainly exist in the form of off-chain channels. Build off-chain channels to protect the privacy of ledger data, and at the same time, use the public chain ledger to record the opening and closing of channels to protect transaction security. In the permissioned chain system, traditional authorization and authentication technologies are mainly used. Due to the design and management of access rights, There are more choices for network configuration, usually using a multi-chain mechanism to build different sub-blockchains according to application needs.