Network Working Group S. Hommes
Internet-Draft B. Fiz
Intended status: Standards Track R. State
Expires: January 8, 2017 University of Luxembourg
A. Zuenko
R. Caetano
V. Gurbani
Bell Laboratories
July 7, 2016

ALTO for the blockchain


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.

Status of This Memo

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

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 January 8, 2017.

Copyright Notice

Copyright (c) 2016 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 ( 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.

Table of Contents

1. Introduction

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.

ALTO could reduce the number of ignored and therefore redundant broadcasting messages by optimising the network topology of the decentralised network. This could be realised by reducing the connection between nodes based on the topology information that is available to the ALTO server. Moreover, ALTO can provided guidance by selecting the optimal route in order to optimise the network metrics (e.g. latency, bandwidth). ALTO can also provide an information to peers in order 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].

2. Private Blockchains

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 benefit of using ALTO for deciding on which peer to select is applicable in case of a distributed deployment that is separated over multiple nodes. Privacy issues are of less importance since the blockchain is owned by a single entity that will also provide the ALTO server.

3. Consortium Blockchains

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 usage of ALTO can help to optimise the communication between peers in order to reduce the communication overhead to a minimum, and increases therefore the number of supported nodes.

4. Public Blockchains

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 ALTO server can provide such an information to the nodes before joining the network, or after a node has lost connection and needs to re-connect to the network. Moreover ALTO can advertise peers periodically or in case of an event about alternative routes that would improve the communication.

The bootstrap mechanism is considered as a trust bottleneck in decentralised networks. For private and consortium blockchain networks, the trust is usually given to the operator of the network, and might be additionally secured by a respective Public-Key-Infrastructure (PKI). For such network, the implementation of ALTO is directly related to the trust in the operator and possible without privacy concerns. For a public blockchain network, the use of ALTO should be reduced to a role of guidance on what peers to select. 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 ALTO gives a recommendation based on this set of peers by using different kind of metrics.

The usage of ALTO is further considered to enhance the overall communication of peers and the message propagation time. This is especially interesting for public networks, where a large number of peers communicate with each other that are distributed over multiple Autonomous Systems (AS). Network optimisation with ALTO can be realised due to its global view on the network.

5. The Bitcoin Network

An ALTO server can increase the resilience against interrupts of peers and improve the propagation time of messages between peers that are communicating with each other due to its global view on the network. This can further lead to an advantage when using peers that are part of a Bitcoin network.

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 therefore benefit from ALTO since the number of redundant connections is reduced, which decreases drastically the total amount of traffic in the network.

The usage of ALTO might reduce the occurrence of forks by increasing the propagation time between peers in the network. The process of finding a new block in the Bitcoin network is called mining, and approximately every 10 seconds 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. 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. An ALTO server could improve the bootstrap process for nodes by proposing the best relay node for a connection.

For the Bitcoin network, which consists of a decentralised network architecture with no single authority, it is important to emphasize that ALTO is considered as a service that can be used to give guidance for the peer selection, but is not replacing the underlying peer-to-peer network. For instance, Bitcoin is currently using a hard-coded list of DNS seeds to obtain the list of peers. ALTO could further be used to exchange information with the DNS seeds, or filtering their response of peers by adding other relevant information obtained by its global view on the network.

6. Role-based Blockchains

Blockchain service providers often have a set of different nodes, where each node has a different role in the network. For instance, the Bitcoin network consists of wallet, miner and relay nodes. Each of them having different requirements in terms of communication preferences. 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, and proposes different routes in dependence of the type of node that sent the request. This requires that the ALTO server is aware of the different roles and which metrics need to be applied for each role. The current status of ALTO supports such an application scenario.

7. Security Considerations

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 an ALTO server might lead to new kind of attacks. For instance, an attacker might be able to predict the routes of ALTO and 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.

8. Acknowledgments


9. Instructions to the RFC Editor

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.

10. Normative References

[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.

Authors' Addresses

Stefan Hommes University of Luxembourg EMail:
Beltran Fiz University of Luxembourg EMail:
Radu State University of Luxembourg EMail:
Anton Zuenko Stratumn EMail:
Richard Caetano Stratumn EMail:
Vijay Gurbani Bell Laboratories EMail: