Skip to main content

ALTO for the blockchain
draft-hommes-alto-blockchain-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Stefan Hommes , Beltran Fiz , R State , Anton Zuenko , Richard Caetano , Vijay K. Gurbani
Last updated 2016-07-06
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-hommes-alto-blockchain-00
Network Working Group                                          S. Hommes
Internet-Draft                                                    B. Fiz
Intended status: Standards Track                                R. State
Expires: January 7, 2017                        University of Luxembourg
                                                               A. Zuenko
                                                              R. Caetano
                                                                Stratumn
                                                              V. Gurbani
                                                       Bell Laboratories
                                                            July 6, 2016

                        ALTO for the blockchain
                    draft-hommes-alto-blockchain-00

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

Hommes, et al.           Expires January 7, 2017                [Page 1]
Internet-Draft               ALTO-blockchain                   July 2016

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
   (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.  Private Blockchains . . . . . . . . . . . . . . . . . . . . .   3
   3.  Consortium Blockchains  . . . . . . . . . . . . . . . . . . .   3
   4.  Public Blockchains  . . . . . . . . . . . . . . . . . . . . .   4
   5.  The Bitcoin Network . . . . . . . . . . . . . . . . . . . . .   4
   6.  Role-based Blockchains  . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  Instructions to the RFC Editor  . . . . . . . . . . . . . . .   6
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   With the inception of the Bitcoin cryptocurrency, the underlying
   concept of the blockchain has now attracted a large number of
   application scenarios.  In the Bitcoin network, the blockchain is a
   distributed ledger of all transactions that have been occurred since
   the very beginning.  Transactions are further collected into blocks.
   The process of finding a new block is called mining, and
   approximately every 10 seconds a new block is added to the
   blockchain.  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.  The following

Hommes, et al.           Expires January 7, 2017                [Page 2]
Internet-Draft               ALTO-blockchain                   July 2016

   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.

   Based on the topology information that is available to the ALTO
   server and is provided to its peers, the communication between the
   nodes in a blockchain network is improved 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 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 operator 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.

Hommes, et al.           Expires January 7, 2017                [Page 3]
Internet-Draft               ALTO-blockchain                   July 2016

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.

   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.

   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.

5.  The Bitcoin Network

   An ALTO server can increase the resilience against interrupts of
   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.

   The usage of ALTO might reduce the occurrence of forks by reducing
   the latency of peers in the network.  Each peer is further considered
   as a single node, where some of them are used to mine new bitcoins.

Hommes, et al.           Expires January 7, 2017                [Page 4]
Internet-Draft               ALTO-blockchain                   July 2016

   This 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 ALTO 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.

Hommes, et al.           Expires January 7, 2017                [Page 5]
Internet-Draft               ALTO-blockchain                   July 2016

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

Authors' Addresses

   Stefan Hommes
   University of Luxembourg

   Email: stefan.hommes@uni.lu

Hommes, et al.           Expires January 7, 2017                [Page 6]
Internet-Draft               ALTO-blockchain                   July 2016

   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 January 7, 2017                [Page 7]