| Network Working Group | S. Hommes |
| Internet-Draft | B. Fiz |
| Intended status: Standards Track | R. State |
| Expires: July 9, 2017 | University of Luxembourg |
| A. Zuenko | |
| R. Caetano | |
| Stratumn | |
| V. Gurbani | |
| Bell Laboratories | |
| January 05, 2017 |
ALTO for the blockchain
draft-hommes-alto-blockchain-02
With the inception of the Bitcoin cryptocurrency, the underlying concept of the blockchain has now attracted a large number of application scenarios. Due to the decentralised nature of a typical blockchain service, a reliable communication between the different nodes is a mandatory requirement. RFC7285 describes the idea of using Application-Layer Traffic Optimization (ALTO) that is used to improve the communication in peer-to-peer networks. This document describes the benefits of using ALTO in the context of a blockchain network, and highlights the improvements for a private, consortium and public blockchain.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 9, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
With the inception of the Bitcoin cryptocurrency, the underlying concept of the blockchain has now attracted a large number of application scenarios.
The blockchain is a distributed ledger technology that stores assets in the form of transactions. All transactions are further collected into blocks. The process of finding a new block requires the validation of transactions, which are then included into the blocks. Each block contains a chained hash of its previous block, which protects the blockchain against alterations. Any modification of a block would require a recalculation of all subsequent blocks in the blockchain, which is computational very expensive. This property assures an unchangeable history and allows for non-repudiation and a way to track all transactions that have ever occurred on that blockchain.
A typical blockchain service consists of a number of different nodes that communicate via a peer-to-peer protocol in a decentralised network. Each node, which is further considered as a peer, contains a copy of the whole blockchain. In order to maintain the blockchain copies stored across the different nodes synchronised, a blockchain network will have a broadcasting mechanism for new transactions and blocks. Given that these communications can get relatively large in size, in particular in the case of blocks, traditionally the broadcasting mechanism is performed as follows: (1) A node broadcasts its available transactions/blocks to its neighbours. (2) If the neighbouring node does not have the transaction and/or block, it will issue a request to receive it and the transactions and/or blocks will be transferred. (3) If no new transaction/block was offered to the node, the message will be ignored.
The concept of ALTO can improve the communication in a blockchain network by improving the peer selection mechanism and information propagation. ALTO can provide guidance by selecting the optimal route to other peers in order to optimise the network metrics (e.g. latency, bandwidth) and to assure Quality-of-service (QoS) requirements.
The following paragraphs highlight some important aspects that improve a network of peers belonging to a blockchain network when using Application-Layer Traffic Optimization (ALTO). We further consider three categories of blockchain networks, which are private, consortium and public.
The ALTO protocol is specified in [RFC7285]. An ALTO server discovery procedure is defined in [RFC7286].
There exist different kind of blockchain networks and we separated them in private, consortium and public.
A private blockchain network is considered as a network that is controlled by a single entity. Such a network is typically located at a certain location, or might be separated at different locations that communicate with each other.
The benefits of using ALTO for peer selection are applicable in case of a distributed deployment with multiple nodes. Privacy issues are of less importance since the blockchain network is owned by a single entity that might also operate the ALTO server.
A consortium blockchain network is based on a pre-defined group of participants, for instance a consortium of companies belonging to a certain industry. Each node needs to register before it is allowed to participate in the network, and authentication methods are used to control the access.
The consensus model of this type of blockchain leads typically to an intensive exchange of data between nodes. For instance, the Tendermint developers limit the scale of a core network to 300 nodes due to the excessive communication.
The consortium could also provide topology information or run measurements that are further provided to the ALTO server.
A public blockchain network is considered as a network that is not restricting the access to a certain user group but being available for everyone. Additional registration procedures might be required before joining, but every user is considered as a potential candidate. A typical example for such a network is the Bitcoin network.
Before a new blockchain node can join an existing blockchain service, a bootstrap mechanism is required to select the initial peers that are used to establish the connection. The bootstrap mechanism is considered as a trust bottleneck in decentralised networks. The ALTO server can provide an information about which peers to select based on a number of available peers that are provided to the ALTO client by a respective Resource Directory. Each blockchain node is further defined by its role that might have different requirements on the communication preferences, which is reflected by the chosen metric. Besides for selecting nodes during the bootstrap process, ALTO can propose the best alternative nodes in case a node has lost its connection(s) to other nodes due to network failures, or because a node has left the network.
The mechanism of using ALTO for private or consortium blockchain networks is shown in Figure 1. A node that is connecting to a blockchain network sends a request to the Resource Directory, and specifies in dependence of its role the metric that should be applied for the peer ranking. The Resource Directory contains trackers, which store a list of available peers per role that is sorted based on a respective metric. The ALTO client is further connected to the trackers in order to provide the ranking of peers by communicating with the ALTO server. The Resource Directory is responding to the requesting node with a ranking of available peers.
+-------------------------------------------+
| Resource Directory (RD) |
| |
| +-------------+ |
| | Tracker | |
| | (Role A) |***** |
| | Metric X | * +-------------+ | +-------------+
| +-------------+ * | ALTO Client | | | ALTO Server |
| ****| | <======> | |
| +-------------+ * | | | | |
| | Tracker | * +-------------+ | +-------------+
| | (Role B) |***** |
| | Metric Y | |
| +-------------+ |
| |
+-------------------------------------------+
*
*
*
+-----------------+
| Blockchain Node |
| (Role A) |
+-----------------+
Legend:
=== ALTO protocol
*** Application protocol
Figure 1: Application scenario with an ALTO Client integrated into the Ressource Directory.
In this kind of scenario, the ALTO client is implemented in the Resource Directory which has the advantage of a reduced communication to the ALTO server when compared to an architecture that has an ALTO client integrated into each blockchain node. Since each blockchain node needs to trust the operator of the Resource Directory and ALTO client, the access might be additionally secured by a respective Public-Key-Infrastructure (PKI).
In order to reduce the information exposure about the topology of the participating blockchain nodes, it is recommended that the ALTO client is requesting a cost map for the endpoints. Another advantage is that no topology information (e.g. number of nodes) is revealed to the operator of the ALTO server, which reduces the risk that attackers exploit this information for an attack.
The mechanism of using ALTO for public blockchain networks is shown in Figure 2. A node that is connecting to a blockchain network sends a request to a tracker to retrieve a list of available peers. In the next step, the ALTO client sends the list of available peers (e.i. endpoints) together with the required metric, which depends of the role of the blockchain node, to the ALTO server. Afterwards, the ALTO client receives a ranking of the peers that allows the node to establish a connection to the peers of the blockchain network.
+-------------+
| Tracker | +------------------+
| (Role A) |*** | Blockchain |
| | * | Node (Role A) |
+-------------+ ***| Metric X |
| +-------------+ +-------------+
+-------------+ | | ALTO Client | | ALTO Server |
| Tracker | | | | <======> | |
| (Role B) | | | | | |
| | +----+-------------+ +-------------+
+-------------+
Legend:
=== ALTO protocol
*** Application protocol
Figure 2: Application scenario with an ALTO Client per blockchain node.
For a public blockchain network, the usage of ALTO for peer selection should be optionally and not mandatory. The reason for this is that the operator of ALTO otherwise becomes a central authority in a decentralised network. For instance, the initial peers might be obtained by a trusted source, and each node can optionally contact an ALTO server to receive a ranking based on a certain metric. When compared to the architecture of Figure 1, the amount of traffic is increased due to the fact that each blockchain node contains an ALTO client that is communicating with the ALTO server. Nevertheless, it simplifies the implementation of ALTO since it requires no common agreement of all participants on using such a service.
Due to the large number of peers that might participate in a public blockchain network, the prefered ALTO implementation should be using the Endpoint Cost Service (ECS) instead of a cost map, which might be very large in size and more difficult to process for the blockchain node.
The peer selection process of a blockchain node can be enhanced using ALTO, and is based on using different kind of metrics for the ranking (e.g. routing costs). Nevertheless, while some ranking might reflect the best peers to connect to based from the view of a single peer, it might lead to the creation of clusters. The latter occur when a subset of peers at one location are well connected, but having only a few connections to remote peers. As a result, it decreases the resilience of nodes against interruptions, and might lead to bottlenecks in case that some peers provide the only connection to reach other peers in the network.
In order to avoid the creation of clusters, each node should therefore apply some randomness in its peer selection process, or by using a metric on the ALTO server that is already avoiding the creation of clusters by adapting the ranking accordingly.
The communication in blockchain network aims on the propagation of transaction and blocks in order to keep each blockchain node synchronised at all times. Reducing the message propagation time is therefore an important goal, which is especially interesting for public networks, where a large number of peers are distributed over multiple Autonomous Systems (AS).
In a typical network, the availability of new transactions and blocks are send via broadcast to all neighbouring nodes. The drawback of this approach is that many nodes receive a similar message from multiple nodes, which increases the total amount of traffic in the network. Moreover, a node cannot determine which is the best route to reach a neighbour node in order to retrieve the transaction or block. ALTO can further be used to identify which route to the neighbour nodes has the lowest costs in order to decreases the message propagation time.
The Bitcoin network is currently the largest public blockchain network, which consists of a decentralised network architecture with no single authority. It is important to emphasize that ALTO is considered as an optional service that can be used to give guidance to peers about the peer selection process. Bitcoin is currently using a hard-coded list of DNS seeds to obtain a list of available peers. ALTO can further be used to provide a ranking of those peers in order to improve the propagation time of transactions and blocks.
The peer selection can further be separated by the respective role of the node, which are either wallet, miner and relay nodes. While a wallet node is interested to have as many connection as possible with other wallet nodes, a miner is usually aiming to reduce the propagation delay for transmitting new blocks. An ALTO server can take this into account by applying different metrics for the ranking. The current status of ALTO supports such an application scenario by selecting the metric for the ranking accordingly.
When a user has executed a transaction by sending bitcoins from his account/wallet to the recipient, the transaction is broadcasted as described in section 1. The Bitcoin network can benefit from ALTO by making a better decision on what peers to connect to in order to request transactions and blocks, and to optimise the number of broadcast messages in order to decrease the total amount of traffic in the network.
The usage of ALTO might reduce the occurrence of forks by decreasing the propagation time of blocks to reach other peers in the network. The process of finding a new block in the Bitcoin network is called mining, and approximately every ten minutes a new block is added to the blockchain. The mining of new bitcoins requires to solve a well-defined cryptographic problem, the so called proof-of-work that requires a significant amount of computational power. As soon as a new block has been mined, this block is propagated by the network and becomes a potential candidate of a block that is further added to the blockchain as the next block. In case that multiple valid blocks have been found by multiple miners at the same time, a so called fork is generated, resulting in a split of the blockchain into multiple chains that develop independently from each other. As soon as the nodes of a fork are aware of the existence of other forks, the situation is resolved and only a single chain is chosen as valid, meaning that all other forks become invalid including the mined blocks. In order to minimise the occurrence of forks, which provides no reward for the miners that are part of a fork that has been discarded, ALTO can optimise the communication between miners to increase the propagation speed of new blocks.
The Bitcoin network has an additional "relay network", which is a system of high-speed relay nodes that are used as a fall back network for the public Bitcoin network, and to decrease propagation time between miners. ALTO can help nodes to determine which is the best relay node to connect to based on their current location.
From a security perspective, the usage of ALTO in blockchain networks might lead to new kind of attacks. We consider this risk of less importance for a private and consortium network, where all participants are known to the operator and authentication mechanisms are used to restrict access to the network.
For the public blockchain networks, the usage of ALTO might lead to new kind of attacks. For instance, an attacker might be able to get insights about the topology of peers by using ALTO, and can exploit this knowledge in order perform a double spending attack more easily. The scope of such attacks and security violations needs to be investigated and is not part of this draft.
-
Please remove this section in its entirety before publication as an RFC.
Please replace any instances of RFCxxxx with the RFC number assigned to this memo.
| [RFC7286] | Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M. and H. Song, "Application-Layer Traffic Optimization (ALTO) Server Discovery", RFC 7286, DOI 10.17487/RFC7286, November 2014. |
| [RFC7285] | Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., Roome, W., Shalunov, S. and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014. |