A Survey on Consensus Mechanisms and Mining Strategy Management in Blockchain Networks <s> C. Blockchain Networks <s> We describe a peer-to-peer distributed hash table with provable consistency and performance in a fault-prone environment. Our system routes queries and locates nodes using a novel XOR-based metric topology that simplifies the algorithm and facilitates our proof. The topology has the property that every message exchanged conveys or reinforces useful contact information. The system exploits this information to send parallel, asynchronous query messages that tolerate node failures without imposing timeout delays on users. <s> BIB001 </s> A Survey on Consensus Mechanisms and Mining Strategy Management in Blockchain Networks <s> C. Blockchain Networks <s> Bitcoin is a digital currency that unlike traditional currencies does not rely on a centralized authority. Instead Bitcoin relies on a network of volunteers that collectively implement a replicated ledger and verify transactions. In this paper we analyze how Bitcoin uses a multi-hop broadcast to propagate transactions and blocks through the network to update the ledger replicas. We then use the gathered information to verify the conjecture that the propagation delay in the network is the primary cause for blockchain forks. Blockchain forks should be avoided as they are symptomatic for inconsistencies among the replicas in the network. We then show what can be achieved by pushing the current protocol to its limit with unilateral changes to the client's behavior. <s> BIB002 </s> A Survey on Consensus Mechanisms and Mining Strategy Management in Blockchain Networks <s> C. Blockchain Networks <s> Bitcoin is a digital currency which relies on a distributed set of miners to mint coins and on a peer-to-peer network to broadcast transactions. The identities of Bitcoin users are hidden behind pseudonyms (public keys) which are recommended to be changed frequently in order to increase transaction unlinkability. We present an efficient method to deanonymize Bitcoin users, which allows to link user pseudonyms to the IP addresses where the transactions are generated. Our techniques work for the most common and the most challenging scenario when users are behind NATs or firewalls of their ISPs. They allow to link transactions of a user behind a NAT and to distinguish connections and transactions of different users behind the same NAT. We also show that a natural countermeasure of using Tor or other anonymity services can be cut-off by abusing anti-DoS countermeasures of the Bitcoin network. Our attacks require only a few machines and have been experimentally verified. The estimated success rate is between 11% and 60% depending on how stealthy an attacker wants to be. We propose several countermeasures to mitigate these new attacks. <s> BIB003 </s> A Survey on Consensus Mechanisms and Mining Strategy Management in Blockchain Networks <s> C. Blockchain Networks <s> Emerging smart contract systems over decentralized cryptocurrencies allow mutually distrustful parties to transact safely without trusted third parties. In the event of contractual breaches or aborts, the decentralized blockchain ensures that honest parties obtain commensurate compensation. Existing systems, however, lack transactional privacy. All transactions, including flow of money between pseudonyms and amount transacted, are exposed on the blockchain. We present Hawk, a decentralized smart contract system that does not store financial transactions in the clear on the blockchain, thus retaining transactional privacy from the public's view. A Hawk programmer can write a private smart contract in an intuitive manner without having to implement cryptography, and our compiler automatically generates an efficient cryptographic protocol where contractual parties interact with the blockchain, using cryptographic primitives such as zero-knowledge proofs. To formally define and reason about the security of our protocols, we are the first to formalize the blockchain model of cryptography. The formal modeling is of independent interest. We advocate the community to adopt such a formal model when designing applications atop decentralized blockchains. <s> BIB004 </s> A Survey on Consensus Mechanisms and Mining Strategy Management in Blockchain Networks <s> C. Blockchain Networks <s> Blockchain-based cryptocurrencies have demonstrated how to securely implement traditionally centralized systems, such as currencies, in a decentralized fashion. However, there have been few measurement studies on the level of decentralization they achieve in practice. We present a measurement study on various decentralization metrics of two of the leading cryptocurrencies with the largest market capitalization and user base, Bitcoin and Ethereum. We investigate the extent of decentralization by measuring the network resources of nodes and the interconnection among them, the protocol requirements affecting the operation of nodes, and the robustness of the two systems against attacks. In particular, we adapted existing internet measurement techniques and used the Falcon Relay Network as a novel measurement tool to obtain our data. We discovered that neither Bitcoin nor Ethereum has strictly better properties than the other. We also provide concrete suggestions for improving both systems. <s> BIB005
In a Byzantine environment, the identity management mechanism plays a key role in determining how the nodes in a blockchain network are organized. In an open-access (i.e., public/permissionless) blockchain network, a node can freely join the network and activate any available network functionalities. Notice that the term "node" refers to a logical entity (i.e., the identity of a blockchain user) rather than to a physical device. For example, multiple "nodes" associated with different network functionalities can be hosted on the same physical machine. In alternative words, a physical device may appear in multiple identities in the network. Without any authentication scheme, the nodes are organized as overlay P2P networks. Comparatively, in a consortium (i.e., permissioned) blockchain network, only the authorized nodes are allowed to enable the core functionalities such as consensus participation or data propagation. The authorized nodes may be organized in different topologies, e.g., fully connected networks or P2P networks, according to the consensus protocols that the networks adopt. In this paper, we mainly focus on the network protocols in the permissionless cases. In permissionless blockchain networks, the main goal of the network protocol is to induce a random topology among the nodes and propagate information efficiently for blockchain replica synchronization. Most of the existing blockchain networks employ the ready-to-use P2P protocols with slight modification for topology formation and data communication. For peer discovery and topology maintenance, the nodes in Bitcoin-like blockchain networks rely on querying a hardcoded set of volunteer DNS servers, which return a random set of bootstrapping nodes' IP addresses for the new nodes to initialize their peer lists BIB002 , BIB003 . Nodes then request or advertise addresses based on these lists. In contrast, the Ethereum-like networks adopt a Kademlia-inspired protocol based on Distributed Hash Tables (DHTs) BIB001 for peer/route discovery 5 through UDP connections. In blockchain networks, the connection of a node to a peer is managed based on reputation using a penalty score. A node will increase the penalty score of the peer sending malformed messages until the IP address of the faulty node is locally banned  , BIB003 . To replicate the blockchain over all nodes in the network, the messages of transactions and blocks are "broadcast" through flooding the P2P links in a gossip-like manner. Typically, a P2P link in blockchain networks is built upon a persistent TCP connection after a protocol-level threeway handshake, which exchanges the replica state and the protocol/software version of each node  , BIB005 . After the connections to the peer nodes are established, another threeway handshake occurs for a node to exchange new transactions/blocks with its neighbors. The node first notifies its peers with the hashcode of the new transactions/blocks that it receives or generates. Then, the peers reply with the datatransfer request specifying the hashcode of the information that they need. Upon request, the transfer of transactions/blocks is done via individual transfer messages BIB004 . The data transfer in blockchain networks is typically implemented based on the HTTP(s)-based Remote Procedure Call (RPC) protocol, where the messages are serialized following the JSON protocol  . An open-access blockchain network does not explicitly specify the role of each node. Nevertheless, according to the enabled functionalities, the nodes in the network can be categorized as the lightweight nodes, the full nodes and the consensus nodes  . Basically, all nodes are required to enable Figure 4 . The life cycle of blockchain transactions. Note that transaction validation and blockchain mining may happen at the same time with transaction propagation, depending on the consensus protocol adopted by the blockchain. the routing functionality for message verification/propagation and connection maintenance. A lightweight node (e.g., wallets) only keeps the header of each block in its local storage. A full node stores locally a complete and up-to-date replica of the canonical blockchain. Compared with the lightweight nodes, a full node is able to autonomously verify the transactions without external reference. A consensus node enables the functionality of consensus participation. Therefore, it is able to publish new blocks and has a chance to influence the state of the canonical blockchain. A consensus node can adopt either complete storage or lightweight storage. In Figure 3 , we present an example of different node types in a public blockchain network. Meanwhile, the lifecycle of a new transaction is shown in Figure 4 . It is worth noting that the consensus nodes are often referred to as the "miners" or "mining nodes" of blocks in the context of blockchain consensus formation, especially when token rewards of block proposal are involved. Meanwhile, different roles of nodes lead to the inconsistency in their interests. Namely, the transaction-issuing nodes (e.g., lightweight nodes) may not be the transactionapproving nodes (i.e., consensus nodes). For this reason, caution needs to be taken in protocol design to ensure that the consensus nodes act on behalf of the others in a trustless environment, especially on the consensus layer.