You are presented with multiple paper abstracts, alongside the associated literature review and chapter titles. Given the provided information, you are going to do a literature review. Please generate a coherent literature review that synthesizes the content, draws connections between different works, highlights major findings, and identifies any gaps in the existing research.

Literature Review Title: A Survey on Consensus Mechanisms and Mining Strategy Management in Blockchain Networks 
Chapter Title:  A. Off-chain and Side-chain Techniques 
1. Abstract of Cited Paper (BIB001):  The increasing popularity of blockchain-based cryptocurrencies has made scalability a primary and urgent concern. We analyze how fundamental and circumstantial bottlenecks in Bitcoin limit the ability of its current peer-to-peer overlay network to support substantially higher throughputs and lower latencies. Our results suggest that reparameterization of block size and intervals should be viewed only as a first increment toward achieving next-generation, high-load blockchain protocols, and major advances will additionally require a basic rethinking of technical approaches. We offer a structured perspective on the design space for such approaches. Within this perspective, we enumerate and briefly discuss a number of recently proposed protocol ideas and offer several new ideas and open challenges. 
2. Abstract of Cited Paper (BIB002):  Motivated by the recent explosion of interest around blockchains, we examine whether they make a good fit for the Internet of Things (IoT) sector. Blockchains allow us to have a distributed peer-to-peer network where non-trusting members can interact with each other without a trusted intermediary, in a verifiable manner. We review how this mechanism works and also look into smart contracts—scripts that reside on the blockchain that allow for the automation of multi-step processes. We then move into the IoT domain, and describe how a blockchain-IoT combination: 1) facilitates the sharing of services and resources leading to the creation of a marketplace of services between devices and 2) allows us to automate in a cryptographically verifiable manner several existing, time-consuming workflows. We also point out certain issues that should be considered before the deployment of a blockchain network in an IoT setting: from transactional privacy to the expected value of the digitized assets traded on the network. Wherever applicable, we identify solutions and workarounds. Our conclusion is that the blockchain-IoT combination is powerful and can cause significant transformations across several industries, paving the way for new business models and novel, distributed applications. 
3. Abstract of Cited Paper (BIB003):  In the setting of blockchain based transaction ledgers we study the problem of “simplified payment verification” (SPV) which refers to the setting of a transaction verifier that wishes to examine the last k blocks of the blockchain (e.g., for the purpose of verification of a certain transaction) using as only advice the genesis block (or some “checkpoint” block that is known to it). 
4. Abstract of Cited Paper (BIB004):  Bitcoin owes its success to the fact that transactions are transparently recorded in the blockchain, a global public ledger that removes the need for trusted parties. Unfortunately, recording every transaction in the blockchain causes privacy, latency, and scalability issues. Building on recent proposals for "micropayment channels" --- two party associations that use the ledger only for dispute resolution --- we introduce techniques for constructing anonymous payment channels. Our proposals allow for secure, instantaneous and private payments that substantially reduce the storage burden on the payment network. Specifically, we introduce three channel proposals, including a technique that allows payments via untrusted intermediaries. We build a concrete implementation of our scheme and show that it can be deployed via a soft fork to existing anonymous currencies such as ZCash.

Literature Review:
For cryptocurrencies, one popular and straightforward approach to throughput enhancement is to adjust the parameters, e.g., the block size and confirmation time in Nakamoto-like protocols. A typical example of this approach can be found in the Segregated Witness proposal (SegWit) [168] for Bitcoin soft fork, which lifted the block-size limit from 1MB to 4MB. However, the study in BIB002 points out that such a reparameterization approach is constrained by the network's bandwidth (e.g., for block size) as well as the blockchain's security requirement (e.g., confirmation time). Thus, such an approach does not really scale out the throughput as the network size increases. With the emphasis on compatibility to the existing consensus protocol or network realization, alternative approaches, e.g., the Lightning network  , that aim to lower the frequency of global block validation/synchronization, are proposed by the development communities, specifically for value transfer networks. The Lightning network  and its variations such as Blind Off-chain Lightweight Transactions (Bolt) BIB005 and the TEEbased Teechain  introduce the concept of (bidirectional) micro-payment channels between two nodes via untrusted intermediary relays. Specifically, the payment channels are realized as logical channels overlaying on the existing blockchains (e.g., on Bitcoin  or on ZCash BIB005 ) and therefore do not modify the underlying consensus protocols. The value transfer between the two end nodes on each channel is kept "off-chain" as a local sequence of mutually-agreed balancestate updates, also known as commitment transactions  . In other words, the sequence of transactions on an established channel are not broadcast to the entire network and kept locally between the two end nodes as well as the intermediaries when needed. Then, transactions of value transfer over a channel are not confirmed as normal transactions and cannot be spend until the "closure" of the channel. When closing the channel, only the most recent commitment transaction is broadcast and needs to be mined by the blockchain network. By doing so, the requirement of validating/synchronizing every transaction across the network is relaxed and the number of transactions to be mined is greatly reduced, hence making the underlying blockchain network more throughput-scalable. Due to the lack of trust, simply relaxing the consensus requirement and keeping transactions in local payment channels will incur the risk of double spending. To address this problem, the technique of 2-of-2 multisignature 21 is enforced in the Lightning networks and a number of specifically designed smart contracts (i.e., scripts in Bitcoin) are introduced. To establish a channel, a funding transaction has to be created jointly by the end parties and broadcast to the network in order to lock their submitted tokens in escrow. An order of broadcast is defined by creating for each party a different version of every subsequent commitment transaction, i.e., in the form of a half-signed transaction containing only the signature of the counterparty, with the same balance outputs. An accompanying revocable transaction BIB003 is also created to enable updating the balance changes. It also provide a means of revoking transactions in case a violation occurs or a waiting time limit is reached. In normal scenarios, only the latest commitment transaction is broadcast to close the channel. Otherwise, by broadcasting the right version of revocable transactions, one end node is able to provide the publicly verifiable proof of recognizing a malicious behavior by the counterparty, and claim all of its deposit in the funding transaction as a punishment. Other than the off-chain schemes that aim to reduce the amount of transactions over the network, an alternative design is to extend an existing blockchain-based value transfer network with multiple "side-chains" BIB001 . A side-chain is an independent blockchain network that validates a subset of transactions and keeps track of the corresponding assets. Such a design introduces parallelism into the existing network and each side-chain is only responsible for validating a fraction of the total amount of transactions in the network. Therefore, it is able to increase the transaction throughput by adding more side-chains. As in the off-chain techniques, side-chains do not modify existing consensus protocols. Instead, the fundamental goal is to enable bidirectional atomic value transfer between side-chains. More specifically, any value transaction between side-chains is either completely confirmed by both side-chains or not at all. Meanwhile, the value carried by the transaction can be imported from and returned to a side-chain with no risk of double spending. To achieve such a goal (also known as "two-way peg" in BIB001 ), special proofs of value locking and redeeming are needed whenever inter-chain transfer happens. Especially, since the consensus nodes of the receiving sidechain usually do not track the state changes of the sending side-chain, providing a compact, non-interactive proof of events occurring on side-chains becomes the utmost concern of the network designers. In BIB001 , the Simplified Payment Verification (SPV) proof is adopted from  based on the proof-of-inclusion path in Merkle trees to provide compact proofs of value locking for atomic transfer (cf. Figure 8 ). Further enhancement of the proof is also proposed in BIB001 by introducing a trusted cross-chain federation of mutually distrusting functionaries (i.e., approving nodes). Out of the federation, the majority vote in the form of an m-of-n multisignature is used to replace the SPV proof for locking/redeeming a cross-chain pay-to-contract transaction. Furthermore, an SPV proof is accompanied by an array of block headers, whose parent is the block containing the SPV-locked transaction on the sending side-chain. This can be informally considered as a "proof of PoW" shown to the receiving side-chain that the transaction in concern is sufficiently deep in the sending side-chain and thus safely locked (see also our discussion about (8)). In  , a formal primitive called Non-Interactive-Proofs-of-Proof-of-Work (NIPoPoW) is proposed to fill the gaps of compactness and non-interactiveness in the proposal of BIB001 for PoW- Figure 21 . A graphical example of the hierarchical blockchain with levels 0, 1 and 2. A block with header bh is of level µ if bh < D(h)/2 µ (see also  ). Besides the regular hash pointer to the previous block, a block of level µ also maintains a list of hash pointers (interlinks) to the most recent preceding blocks in every level µ ′ such that µ ′ > µ. The genesis block is defined to be of infinite level and hence every other block has to include a pointer to it. based side-chain networks. To avoid tracking/validating every block on the sending side-chain, the study in  proposes to replace the linear list-based blockchains with a skiplist-like data structure called interlink (see Figure 21 and also BIB004 ). As with SPV, a valid NIPoPoW of transaction confirmation also contains an array of blocks (i.e., suffix proof) preceded by the block in concern as a stability proof of that block in the chain. Instead of validating the entire source side-chain, NIPoPoW only has to include 2m blocks in expectation from each level of the hierarchical blockchain in the proof. Here, m is a system-determined security parameter to ensure that for every level µ, the proof only needs to include a number of blocks from the tail of level µ to span the last m-size suffix of blocks in the higher level µ+1. Compared with a secured SPV proof for inter-chain transaction, with NIPoPoW the number of source-chain blocks tracked by the receiving side-chain is only a polylogarithmic function of the source side-chain's length.