=Paper=
{{Paper
|id=Vol-2749/short1
|storemode=property
|title=FabNet: an Automatic Hyperledger Fabric Network Wizard (short paper)
|pdfUrl=https://ceur-ws.org/Vol-2749/short1.pdf
|volume=Vol-2749
|authors=Alessandro Marcelletti,Barbara Re
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/Marcelletti020
}}
==FabNet: an Automatic Hyperledger Fabric Network Wizard (short paper)==
https://ceur-ws.org/Vol-2749/short1.pdf
FabNet: an Automatic Hyperledger Fabric
Network Wizard
Alessandro Marcelletti1 and Barbara Re1
University of Camerino, Via Madonna delle Carceri 7, Italy
{alessand.marcelletti,barbara.re}@unicam.it
Abstract. Hyperledger Fabric is continually evolving technology, thanks
to its active community providing new features and functionalities. How-
ever, it still lacks a user-friendly interface that makes its adoption im-
mediate and straightforward. In particular, one of the main barriers for
non-expert users is the comprehension and creation of a network. In this
paper, we present FabNet, a user-friendly wizard reducing the effort for
the configuration and deployment of the Fabric blockchain network.
Key words: Blockchain, Hyperledger Fabric, Network, Configuration
1 Introduction
The rapidly growing of interest in blockchain technologies made IT specialists
(es. developers and system administrators) approach this new topic. However,
also due to its novelty, they often find this technology hard to learn and master
[1]. The scenario is slightly different considering different blockchain platforms.
Indeed, in cases of consolidated permissionless blockchains such as Bitcoin [2]
and Ethereum [3], the community has been working for many years. This has
led to the creation of documentation and also of tools for automatic generation
of developing environments. Differently, the permissioned Hyperledger Fabric
blockchain is continuously changing with new versions that sometimes modify
the core of the technology significantly. Also, for this reason, high-level inter-
faces still miss, creating an initial obstacle for new people approaching Fabric.
Although Fabric has a deep documentation with theory and tutorials, sometimes
it is hard to understand concepts without a significant effort from the user. In
particular, one of the most challenging technological approaches is the one con-
cerning Fabric network. Indeed the complexity and the amount of files required
to create a customised network is very complicated to understand in the first
moment. Hyperledger itself provides a configured test network with preconfig-
ured commands; however, it is not easy to customise, and it aims to be only an
initial example for developers.
Copyright c 2020 for this paper by its authors. Use permitted under Creative Com-
mons License Attribution 4.0 International (CC BY 4.0).
59
Fabric Composer1 instead, was born with the idea of providing a high-level
environment abstracting from all the low-level details to focus, for example, only
on smart contracts implementation. However, the way used in Composer to write
chaincodes and to interact with the network through the Software Development
Kit (SDK) changed with the new Fabric versions, making the application dep-
recated since 2019. With our work, we focus only on the network file system,
without involving chaincode or APIs, that could make obsolete the entire system
with the first change.
Our objective is to address technological difficulties for developers and system
administrators. The firsts are end-users that want to create a network for various
purposes, without entering in low-level operations, like the creation and the
execution of scripts and files. The seconds are developers that instead need to
learn how to build a network, in this case, we provide an easy way to accelerate
this process, saving a lot of time in the initial approach that, otherwise, can
result very complicated.
Already existing payable solutions, such as Blockchain-as-a-Service (BaaS)
provided by companies like Oracle2 , Microsoft3 or Amazon4 not always provide
a Fabric solution, in addition, the network is deployed directly in their cloud.
What we want, is to abstract the configuration and the deployment phase giving
also the possibility for developers to enter directly inside the system, modifying
files or moving the infrastructure on another space, without remaining close to
the bought service.
For these reasons, we present FabNet, a free tool useful to configure all the
network components just using a high-level interface. This makes the creation of
a customised network easy also for those developers and system administrators
that does not have experiences in this topic. An easy network configuration is
useful especially for starting a project without losing time in undesired configu-
rations. Indeed, sometimes they are not even needed when the main objective is
to work on other components like smart contracts and applications. Moreover,
having under a unique interface the required parameters can help new developers
to understand better the theory and the correlations between the configurations
and the generated files. What we provide is a tool capable of deploying both a
test and a production network, that automatically creates all the configuration
files and the scripts needed to deploy the final network.
The rest of the paper is organised as follows. Section 2 gives an overview
of blockchain technology and in particular of Hyperledger Fabric. Section 3 de-
scribes the project structure while section 4 shows a short demo of FabNet tool.
Finally, Section 5 concludes recapping the motivation.
1
https://hyperledger.github.io/composer/latest/
2
https://www.oracle.com/it/application-development/cloud-services/
blockchain-platform/
3
https://azure.microsoft.com/it-it/services/blockchain-service/
4
https://aws.amazon.com/it/blockchain/
60
2 Background on Hyperledger Blockchain
Blockchain technology was born in the first years with the concept of coop-
eration between dislocated entities, ensuring a high level of trust between the
parties, and provides an immutable way of storing data. With the first per-
missionless blockchains (Bitcoin, Ethereum) it is possible to make exchanges of
assets between its network members. These interactions take place by means of
transactions, stored in the form of blocks in a chain along with a timestamp.
Each block contains a limited number of transactions and, among other infor-
mation, the hash of the current block and the hash of the previous block. Data
are maintained within a distributed network of mutually untrusted peers, that
will be in sync with data changes request, thanks to the consensus mechanism.
In the last years, blockchains have adapted to other contexts, with the support
of features provided by the so-called smart contracts. These can be considered
special programs equipped on each node of the blockchain, which define a trans-
action protocol that applies the terms of an agreement, between one or more
parties involved, enabling auditability between parties [4]. Finally, the execu-
tion of smart contracts produces the transactions whose effects are stored in the
blockchain. In particular, these kind of systems use an order-execute archi-
tecture and requires all peers to execute every transaction and all transactions
to be deterministic.
Hyperledger Fabric [5] differs from the previous described blockchains, due
to its permissioned nature. It is a modular system more versatile for enterprise
applications, providing features such as consensus management, private channels
and contracts, full-featured programming languages in smart contracts and ac-
cess control policies. It introduces the execute-order-validate architecture, that
allows distributed execution of untrusted code in an untrusted environment. In-
deed, Fabric executes transactions before reaching final agreement on their order,
then all peers validate transactions in the same order with a deterministic valida-
tion. Execute-order-validate paradigm, represents the main innovation in Fabric
architecture, making Fabric a scalable system for permissioned blockchains sup-
porting flexible trust assumption.
This kind of system allows to provide flexibility, scalability and privacy in
contexts that require these features. The absence of a mining mechanism enables
a fast validation and confirmation of transactions. This is achieved thanks to the
consensus management system, that allows configuring an arbitrary consensus
algorithm, taking into account the requirements of the system intended to im-
plement. Indeed, the arbitrary consensus and the permissioned nature of Fabric
guarantee a faster protocol respecting to the Ethereum Proof of Work.
The privacy aspect concerns the confidentiality of transaction and data. This
is achieved in Fabric by using its channel architecture and membership service
to restrict the distribution of confidential information exclusively to authorised
nodes. This is achieved defining channels inside the network in which only a set
of chosen nodes can participate. Nodes and channels are also regulated through
policies. Consequently, channel’s ledger is only accessible to its members and
the channel’s organisations must approve each peer’s membership to the chan-
61
nel. Authentication and identity management are guaranteed through a flexible
infrastructure based on the PKI cryptographic scheme and Certificate Author-
ity, which facilitates the joining of a new organisation in the private network.
Also, Transport Layer Security cryptographic protocol is used to provide com-
munications security over the network nodes.
The Fabric network is made by different components5 , reported in Fig. 1 and
described below.
Fig. 1. Example of 2 organisations network components
Peers are the nodes grouped into organisations, defined as trust domain in
which a peer trusts all peers only within its organisation. Peers execute and/or
validate transactions, and maintain the ledger. The group of defined organisa-
tions participating in a channel is called consortium. The ordering service,
composed by a set of Ordering Service Nodes (OSNs), establishes consensus
and atomically broadcast state updates. The ordering is stateless and decoupled
from the peers, it does not take part in the transaction execution and validation
process. The Membership Service Provider (MSP), maintains the identities
5
https://hyperledger-fabric.readthedocs.io/en/release-2.2/key_concepts.
html
62
of all the nodes (clients, peers, OSNs) inside an organisation. It comprises mecha-
nisms for authenticate transactions, verify the integrity of transactions, sign and
validate endorsements, key management and registration of nodes. Smart con-
tracts with system chaincodes define the transaction logic and the blockchain
settings. They are defined in the channel and stored in each organisation peer.
The ledger maintains the transactions history, there is one ledger for channel
which copies are stored in the organisations peers. In addition, a snapshot of the
most recent state is stored in a key-value world state. Finally, the administra-
tors have permissions for different operations, like creating and assigning peers,
creating network configurations files and modifying policies through system files.
3 FabNet settings
In this section we present the FabNet tool focusing on its architecture and inter-
face. The tool is composed by a SpringBoot back-end in Kotlin and an Angular
front-end, available to everyone at http://pros.unicam.it/FabNet/. The main
task of the interface is to take inputs from the user and to pass them to the
server. These inputs are described in Tab. 3, that contains all the parameters
that the user has to fill in order to generate a configuration. From these pa-
rameters, the server automatically creates the files needed to create a network.
In particular, these files are 51, counting files, scripts and sub-folders; they are
related to:
1. Certifications and keys;
2. Peers and orderers containers;
3. Channel profile, defined by different sections:
a) orderer;
b) consortium, defining the one creating the network;
c) consortiums, defining all the consortiums in the network;
d) application;
e) capabilities and policies.
These files are filled up with the information passed through different param-
eters in the interface, listed in Tab. 3.
Once the configuration has been defined, the client will send it as a JSON
file to the server, which will generate the related files, returning a zip folder
containing them. The sequence flow in Fig. 2 recaps the steps regarding network
creation.
It is important to notice that with our approach the user does not have to
create manually all the described infrastructure. However, once downloaded, the
user is free to modify all the desired parts without any restriction.
3.1 Netowrk deployment
Once the system folder is generated, to deploy the network is necessary to launch
the autorun file. This file contains and automatically executes all the commands
63
Network name
First name First name
Domain Type
From 2 to N organisations, for each:
Certificate Authority IP address and port
N members, for each: Status in the certificate
First name
From 1 to N consortiums, for each:
Organisations inside
First name
From 1 N channels, for each: Consortium administrator
Organisations inside
Table 1. Interface inputs fillable by the user.
Fig. 2. Sequence diagram of the network configuration and generation
required to deploy the final network, lifting the user from other operations.
In particular, the automatised operations for a total of 14 commands can be
synthesised in:
1. Download required binaries
2. Start CAs and creates artefacts for each organisation;
3. Create genesis block and channels txs;
4. Start Docker containers for each org;
5. Link the started containers so that they can communicate;
6. Create the channel;
7. Join peers to the channel.
Notably, the single file is used to deploy a local network, for remote peers,
some additional steps are required. Indeed, in a distributed context, each organ-
isation should extract, from the generated file system, the folder regarding its
org. After this, it is also necessary to run the CA script generating the artefacts.
However, we are currently working on a FabNet extension to provide the GUI
also for the creation of a distributed network.
64
4 FabNet in practice
In this section we show a demo of FabNet using a basic testing configuration,
describing the flow and the tool functionalities linked with some screens. All the
steps described in the following subsection can be replicated using the links at
http://pros.unicam.it/FabNet.
4.1 Network scenario
The tool is composed by 4 main panels, the first one, reported in Fig. 3, allows
to specify the network name and the organisations involved (name, domain);
it is also possible to add other organisations and to import/export JSON con-
figuration. We introduce a brief scenario involving two organisations, org1 and
org2, that want to collaborate in their network. The configuration used in this
example is available at http://pros.unicam.it/test-network.
In the tool there is also a panel related to organisations, where for each of
them the user has to insert certification authority information and can handle
members. In particular, it is possible to add or remove peers, clients, admins and
orderers. Depending on the member type, different information is required, like
host IP and ports. As soon organisations and network are defined, the consortium
must be created. It is possible to create 1 or more consortiums, defining the
participating organisations. Finally, it is possible to specify the channel in the
network, requiring a consortium and, optionally, external organisations.
If the network configuration is made with local peers, to deploy the entire
network is necessary to run only the start.sh file (download at
http://pros.unicam.it/start/). Instead, if the organisation’s members are dislo-
cated at remote addresses, each user has to take his related folder and run the
inside scripts. The main focus of our future extension aims at removing also
these steps, automatically generating one folder and one start script for each
organisation. Fig. 4 shows the network participants once deployed, in particular,
Fabric network uses Docker containers to run organisation members. In Fig. 5
instead, the status, addresses and names of members are displayed.
4.2 FabNet applications
The previous network scenario showed a simple scenario with two collaborating
organisations but, more in general, FabNet can be used in more contexts. Firstly,
it can be used by different type of users with different purposes, like developers
that want to approach this new technology or for users that want only to create
already usable artefacts.
Also in inter-organisational environments, like the ones analysed in [6], Fab-
Net can be a core element. It helps to have a fast generation of networks with
different configurations, very useful for performance and scalability analysis. In-
deed, the easy configuration allows to increment the peers and organisations
number having more and more networks to test.
65
Fig. 3. Network and organisations declaration page
Fig. 4. Docker containers of the deployed network
Fig. 5. Status of the running peers in the network
66
Think about companies that decide to work together, creating also a blockchain
infrastructure, in this case FabNet suits also the need of prototyping networks.
Indeed, in the first phases, designers have to collaborate, modelling the organ-
isations communication and thinking about structuring the network, handling
peers and all the other components. In that moment, a tool allowing the creation
of more networks for testing different configurations could be very useful.
In this context, developers can work together in a sandbox environment,
changing configurations if needed without effort only by creating and running
new networks.
5 Conclusions
In this work, we presented FabNet, a tool that aims to help IT specialists to
automatise the configuration and the deployment of an Hyperledger Fabric net-
work, thanks to the user-friendly interface that allow configuring files without
manually entering into each of them. Our contribution mainly targets novices in
the blockchain technology, in particular when they have to deal with the creation
of a Fabric network. Indeed, FabNet doesn’t require any effort for configurations,
delegating the creation and the filling of files to the interface, and automating
the generation of artefacts. We also contribute, providing a tool capable of cre-
ating and deploying advanced production-ready networks without involving the
user with additional tasks. FabNet supports a large scale of usages, starting from
benchmarking applications until development ones.
References
1. Liu, X.: A small java application for learning blockchain. In: 2018 IEEE 9th An-
nual Information Technology, Electronics and Mobile Communication Conference
(IEMCON), IEEE (2018) 1271–1275
2. Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system. Technical report,
Manubot (2019)
3. Wood, G., et al.: Ethereum: A secure decentralised generalised transaction ledger.
Ethereum project yellow paper 151(2014) (2014) 1–32
4. Corradini, F., Marcantoni, F., Morichetta, A., Polini, A., Re, B., Sampaolo, M.:
Enabling auditing of smart contracts through process mining. In: From Software
Engineering to Formal Methods and Tools, and Back. Springer (2019) 467–480
5. Androulaki, E., Barger, A., Bortnikov, V., Cachin, C., Christidis, K., De Caro, A.,
Enyeart, D., Ferris, C., Laventman, G., Manevich, Y., et al.: Hyperledger fabric: a
distributed operating system for permissioned blockchains. In: Proceedings of the
thirteenth EuroSys conference. (2018) 1–15
6. Corradini, F., Marcelletti, A., Morichetta, A., Polini, A., Re, B., Tiezzi, F.: Engi-
neering trustable choreography-based systems using blockchain. In: Proceedings of
the 35th Annual ACM Symposium on Applied Computing. (2020) 1470–1479
67