Internet DRAFT - draft-hommes-alto-blockchain
draft-hommes-alto-blockchain
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
Abstract
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 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.
Hommes, et al. Expires July 9, 2017 [Page 1]
Internet-Draft ALTO-blockchain January 2017
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Blockchain Networks . . . . . . . . . . . . . . . . . . . . . 3
2.1. Private Blockchains . . . . . . . . . . . . . . . . . . . 3
2.2. Consortium Blockchains . . . . . . . . . . . . . . . . . 4
2.3. Public Blockchains . . . . . . . . . . . . . . . . . . . 4
3. Peer Selection using ALTO . . . . . . . . . . . . . . . . . . 4
3.1. Deployment of Private and Consortium Blockchains . . . . 5
3.2. Deployment of Public Blockchains . . . . . . . . . . . . 6
3.3. Clustering . . . . . . . . . . . . . . . . . . . . . . . 7
4. Information-Propagation . . . . . . . . . . . . . . . . . . . 7
5. The Bitcoin Network . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. Instructions to the RFC Editor . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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
Hommes, et al. Expires July 9, 2017 [Page 2]
Internet-Draft ALTO-blockchain January 2017
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].
2. Blockchain Networks
There exist different kind of blockchain networks and we separated
them in private, consortium and public.
2.1. 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.
Hommes, et al. Expires July 9, 2017 [Page 3]
Internet-Draft ALTO-blockchain January 2017
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.
2.2. 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 consortium could also provide topology information or run
measurements that are further provided to the ALTO server.
2.3. 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.
3. Peer Selection using ALTO
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.
Hommes, et al. Expires July 9, 2017 [Page 4]
Internet-Draft ALTO-blockchain January 2017
3.1. Deployment of Private and Consortium Blockchains
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
Hommes, et al. Expires July 9, 2017 [Page 5]
Internet-Draft ALTO-blockchain January 2017
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.
3.2. Deployment of Public Blockchains
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
Hommes, et al. Expires July 9, 2017 [Page 6]
Internet-Draft ALTO-blockchain January 2017
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.
3.3. Clustering
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.
4. Information-Propagation
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.
Hommes, et al. Expires July 9, 2017 [Page 7]
Internet-Draft ALTO-blockchain January 2017
5. The Bitcoin Network
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.
Hommes, et al. Expires July 9, 2017 [Page 8]
Internet-Draft ALTO-blockchain January 2017
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.
6. 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 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.
7. Acknowledgments
-
8. 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.
9. 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, <http://www.rfc-editor.org/info/rfc7286>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., 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,
<http://www.rfc-editor.org/info/rfc7285>.
Hommes, et al. Expires July 9, 2017 [Page 9]
Internet-Draft ALTO-blockchain January 2017
Authors' Addresses
Stefan Hommes
University of Luxembourg
Email: stefan.hommes@uni.lu
Beltran Fiz
University of Luxembourg
Email: beltran.fiz@uni.lu
Radu State
University of Luxembourg
Email: radu.state@uni.lu
Anton Zuenko
Stratumn
Email: anton@stratumn.com
Richard Caetano
Stratumn
Email: richard@stratumn.com
Vijay Gurbani
Bell Laboratories
Email: vkg@bell-labs.com
Hommes, et al. Expires July 9, 2017 [Page 10]
