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]