Explore the full ebook collection and download it now at textbookfull.

com

Blockchains: A Handbook on Fundamentals, Platforms

and Applications 2024th Edition Sushmita Ruj

https://textbookfull.com/product/blockchains-a-handbook-on-
fundamentals-platforms-and-applications-2024th-edition-
sushmita-ruj/

OR CLICK HERE

DOWLOAD EBOOK

Browse and Get More Ebook Downloads Instantly at https://textbookfull.com

Click here to visit textbookfull.com and download textbook now
 Your digital treasures (PDF, ePub, MOBI) await
Download instantly and pick your perfect format...

Read anywhere, anytime, on any device!

Biota Grow 2C gather 2C cook Loucas

https://textbookfull.com/product/biota-grow-2c-gather-2c-cook-loucas/

textbookfull.com

Handbook on 3D3C Platforms: Applications and Tools for

Three Dimensional Systems for Community, Creation and
Commerce 1st Edition Yesha Sivan (Eds.)
https://textbookfull.com/product/handbook-on-3d3c-platforms-
applications-and-tools-for-three-dimensional-systems-for-community-
creation-and-commerce-1st-edition-yesha-sivan-eds/
textbookfull.com

McEvoy's Handbook of Photovoltaics, Third Edition:

Fundamentals and Applications Soteris Kalogirou

https://textbookfull.com/product/mcevoys-handbook-of-photovoltaics-
third-edition-fundamentals-and-applications-soteris-kalogirou/

textbookfull.com

Security Strategies in Windows Platforms and Applications

Fourth Edition Shimonski

https://textbookfull.com/product/security-strategies-in-windows-
platforms-and-applications-fourth-edition-shimonski/

textbookfull.com
Security Strategies In Linux Platforms And Applications
Michael Jang

https://textbookfull.com/product/security-strategies-in-linux-
platforms-and-applications-michael-jang/

textbookfull.com

Whole-Body Cryostimulation: Clinical Applications 2024th

Edition Paolo Capodaglio

https://textbookfull.com/product/whole-body-cryostimulation-clinical-
applications-2024th-edition-paolo-capodaglio/

textbookfull.com

Beginning PostgreSQL on the Cloud: Simplifying Database as

a Service on Cloud Platforms Baji Shaik

https://textbookfull.com/product/beginning-postgresql-on-the-cloud-
simplifying-database-as-a-service-on-cloud-platforms-baji-shaik/

textbookfull.com

Fundamentals of Surface Thermodynamics: Phase Behavior and

Its Related Properties 2024th Edition Ronaldo Gonçalves
Dos Santos
https://textbookfull.com/product/fundamentals-of-surface-
thermodynamics-phase-behavior-and-its-related-properties-2024th-
edition-ronaldo-goncalves-dos-santos/
textbookfull.com

Handbook of Self Cleaning Surfaces and Materials From

Fundamentals to Applications 1st Edition Akira Fujishima
(Edt)
https://textbookfull.com/product/handbook-of-self-cleaning-surfaces-
and-materials-from-fundamentals-to-applications-1st-edition-akira-
fujishima-edt/
textbookfull.com
Advances in Information Security 105

Sushmita Ruj
Salil S. Kanhere
Mauro Conti Editors

Blockchains
A Handbook on Fundamentals,
Platforms and Applications
Advances in Information Security

Volume 105

Series Editors
Sushil Jajodia, George Mason University, Fairfax, VA, USA
Pierangela Samarati, Milano, Italy
Javier Lopez, Malaga, Spain
Jaideep Vaidya, East Brunswick, NJ, USA
The purpose of the Advances in Information Security book series is to establish
the state of the art and set the course for future research in information security.
The scope of this series includes not only all aspects of computer, network security,
and cryptography, but related areas, such as fault tolerance and software assurance.
The series serves as a central source of reference for information security research
and developments. The series aims to publish thorough and cohesive overviews on
specific topics in Information Security, as well as works that are larger in scope
than survey articles and that will contain more detailed background information.
The series also provides a single point of coverage of advanced and timely topics
and a forum for topics that may not have reached a level of maturity to warrant a
comprehensive textbook.
Sushmita Ruj • Salil S. Kanhere • Mauro Conti
Editors

Blockchains
A Handbook on Fundamentals,
Platforms and Applications
Editors
Sushmita Ruj Salil S. Kanhere
School of Computer Science and School of Computer Science and
Engineering Engineering
University of New South Wales University of New South Wales
Sydney Kensington, NSW, Australia Sydney Kensington, NSW, Australia

Mauro Conti
Department of Mathematics
University of Padova
Padova, Italy

ISSN 1568-2633 ISSN 2512-2193 (electronic)

Advances in Information Security
ISBN 978-3-031-32145-0 ISBN 978-3-031-32146-7 (eBook)
https://doi.org/10.1007/978-3-031-32146-7

© The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Switzerland
AG 2024
This work is subject to copyright. All rights are solely and exclusively licensed by the Publisher, whether
the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse
of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and
transmission or information storage and retrieval, electronic adaptation, computer software, or by similar
or dissimilar methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
The publisher, the authors, and the editors are safe to assume that the advice and information in this book
are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or
the editors give a warranty, expressed or implied, with respect to the material contained herein or for any
errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional
claims in published maps and institutional affiliations.

This Springer imprint is published by the registered company Springer Nature Switzerland AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland

Paper in this product is recyclable.

Contents

Part I Building Blocks

Ten Myths About Blockchain Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
David Hyland, João Sousa, Gauthier Voron, Alysson Bessani,
and Vincent Gramoli
Cryptographic Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Mayank Raikwar and Shuang Wu

Part II Popular Blockchains

Bitcoin Blockchain System: An Overview of Security and Privacy
Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Mauro Conti, Ankit Gangwal, Chhagan Lal, and Sushmita Ruj
The Ethereum Blockchain: Implementation and Security Aspects . . . . . . . . 109
Alessandro Brighente, Mauro Conti, and Andrea De Salve
The Future Ring Confidential Transaction Protocols for
Privacy-Preserving Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Muhammed F. Esgin, Joseph K. Liu, Shi-Feng Sun,
and Dimaz Ankaa Wijaya
Algorand Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Arash Mirzaei, Amin Sakzad, Ron Steinfeld, and Jiangshan Yu
Tendermint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Yackolley Amoussou-Guenou, Antonella Del Pozzo,
and Sara Tucci-Piergiovanni

Part III Security and Scalability

The Security of Delegated Proof-of-Stake Wallet and Stake Pools . . . . . . . . . 225
Mario Larangeira and Dimitris Karakostas

v
vi Contents

Layer 2 Scaling Solutions for Blockchains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Subhra Mazumdar and Sushmita Ruj
Illicit Blockchain Content: Its Different Shapes, Consequences,
and Remedies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Roman Matzutt, Martin Henze, Dirk Müllmann, and Klaus Wehrle
Blockchain-Based Distributed and Secure Digital Forensic
Investigation Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Mauro Conti, Gulshan Kumar, Chhagan Lal, and Rahul Saha

Part IV Applications
Supply Chain Management Using Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Christopher Klinkmueller, H. M. N. Dilum Bandara, Xiwei Xu,
and Qinghua Lu
Blockchain Technology for E-Governance Applications . . . . . . . . . . . . . . . . . . . . . 399
Ras Dwivedi, Nilesh Vasita, Mukul Verma, Tanmay Yadav,
and Sandeep Shukla
When Blockchain meets Smart Cities: Opportunities, Security
and Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Roben C. Lunardi, Regio A. Michelin, Maher Alharby, Volkan Dedeoglu,
Henry C. Nunes, Eduardo Arruda, Avelino F. Zorzo, and Aad van Moorsel
Decentralized Identity Management and Blockchains: Design
Patterns and Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Hye-young Paik, Yue Liu, Qinghua Lu, and Salil S. Kanhere
From Centralized to Decentralized Remote Electronic Voting . . . . . . . . . . . . . 493
Christian Killer, Bruno Rodrigues, Eder John Scheid,
Muriel Figueredo Franco, and Burkhard Stiller
Blockchain Technology Accelerating Industry 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Jan Pennekamp, Lennart Bader, Eric Wagner, Jens Hiller, Roman Matzutt,
and Klaus Wehrle
Blockchain for Health Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
Dinh C. Nguyen, Pubudu N. Pathirana, Ming Ding, and Aruna Seneviratne
Supporting Secure Trusted Manufacturing via Blockchain . . . . . . . . . . . . . . . . . 587
Ali Dorri, Sabah Suhail, Zahra Jadidi, Rasheed Hussain, Colin Fidge,
and Raja Jurdak
Blockchain for Data Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Gowri Sankar Ramachandran and Bhaskar Krishnamachari
About the Editors

Sushmita Ruj is Faculty of Engineering Lead of UNSW Institute for Cybersecurity,

IFCYBER and Senior Lecturer in the School of Computer Science and Engineering
at UNSW, Sydney. Her research interests are in applied cryptography, post-quantum
cryptography, blockchains and privacy enhancing technologies. She designs prac-
tical, efficient, and provably secure protocols that can be deployed in real-world
applications. She has published over 110 peer-reviewed articles and delivered over
100 technical lectures around the world. She has won several competitive grants like
Samsung GRO Award, NetApp Faculty Fellowship and Cisco Academic Grant. She
is an Associate Editor of the Transactions on Information Forensics and Security.
Before joining UNSW, she was a Senior Research Scientist at CSIRO’s Data61,
an Associate Professor at Indian Statistical Institute and an Assistant Professor at
Indian Institute of Technology, IIT, Indore. She was a visiting researcher/faculty
at NTU, Singapore; KDDI R&D Labs, Japan; INRIA, France; Kyushu University,
Japan; and Microsoft Research Labs, India. She was a member of the “Blockchain
for Cybersecurity” working group of the National Blockchain Roadmap of Australia
and the Blockchain working group founded by the Reserve Bank of India. Sushmita
is a senior member of both ACM and IEEE.

Salil S. Kanhere is a Professor of Computer Science and Engineering at UNSW

Sydney. He is also affiliated with the Cybersecurity Cooperative Research Centre
(CSCRC) and the UNSW Institute for Cyber Security (IFCYBER). His research
interests span the Internet of Things, cyberphysical systems, cybersecurity,
blockchain and applied machine learning. He has published over 350 peer-reviewed
articles and is leading several government and industry-funded research projects
on these topics. He received the Friedrich Wilhelm Bessel Research Award (2020)
and the Humboldt Research Fellowship (2014), from the Alexander von Humboldt
Foundation in Germany. He is an ACM Distinguished Member and served as
an ACM Distinguished Speaker from 2019 to 2021. He is an IEEE Computer
Society Distinguished Visitor and a Senior Member of the IEEE. He has held
visiting positions at I2R Singapore, Technical University Darmstadt, University
of Zurich, RWTH Aachen and Graz University of Technology. He serves as the

vii
viii About the Editors

Editor in Chief of the Ad Hoc Networks journal and as an Associate Editor of IEEE
Transactions on Network and Service Management, Computer Communications and
Pervasive and Mobile Computing. He regularly serves on the organising committee
of IEEE/ACM international conferences. Salil co-authored a book titled Blockchain
for Cyberphysical Systems published by Artech House in 2020.

Mauro Conti is Full Professor at the University of Padova, Italy. He is also

affiliated with TU Delft and University of Washington, Seattle. He obtained his
Ph.D. from Sapienza University of Rome, Italy, in 2009. After his Ph.D., he was
a Post-Doc Researcher at Vrije Universiteit Amsterdam, the Netherlands. In 2011
he joined as Assistant Professor at the University of Padova, where he became
Associate Professor in 2015 and Full Professor in 2018. He has been Visiting
Researcher at GMU, UCLA, UCI, TU Darmstadt, UF and FIU. He has been
awarded with a Marie Curie Fellowship (2012) by the European Commission, and
with a Fellowship by the German DAAD (2013). His research is also funded by
companies including Cisco, Intel and Huawei. His main research interest is in the
area of security and privacy. In this area, he has published more than 550 papers in
topmost international peer-reviewed journals and conferences. He is Editor-in-Chief
for IEEE Transactions on Information Forensics and Security, Area Editor-in-
Chief for IEEE Communications Surveys and Tutorials and has been Associate
Editor for several journals, including IEEE Communications Surveys and Tutorials,
IEEE Transactions on Dependable and Secure Computing, IEEE Transactions on
Information Forensics and Security and IEEE Transactions on Network and Service
Management. He was Program Chair for TRUST 2015, ICISS 2016, WiSec 2017,
ACNS 2020, CANS 2021, CSS 2021, WiMob 2023 and ESORICS 2023, and
General Chair for SecureComm 2012, SACMAT 2013, NSS 2021 and ACNS 2022.
He is Fellow of the IEEE, Fellow of the AAIA, Senior Member of the ACM and
Fellow of the Young Academy of Europe.
 Part I
Building Blocks
Ten Myths About Blockchain Consensus

David Hyland, João Sousa, Gauthier Voron, Alysson Bessani,

and Vincent Gramoli

1 Introduction

Over the last decade, blockchain experienced an important momentum leading

to a plethora of new consensus protocol proposals (e.g., Ripple’s consensus
algorithm [55], Democratic Byzantine Fault Tolerance (DBFT) [24], Aura [41],
Casper [16], HotStuff [65], IBFT [46], Tendermint [43]). A consensus protocol is a
key element of the blockchain system as it helps a distributed set of machines agree
on a unique block at each given index of a chain. In contrast with the problem
of consensus that has been known by the distributed computing community for
the past four decades [52], a significant part of these proposals is often unclear.
Most of these new consensus protocols are described in white papers, wikis, and
online documentations, rather than in more traditional academic publications, and it
is unclear whether they satisfy the application requirements [19].
As a result, there are several misconceptions about what is blockchain consensus,
the guarantees it should offer, and how it could be made secure and fast. For
example, efforts to standardize blockchain technologies have revealed ambiguous
terminologies [36], and, when consensus protocols are stated informally, one can

D. Hyland · G. Voron
University of Sydney, Camperdown, NSW, Australia
e-mail: [email protected]; [email protected]
J. Sousa · A. Bessani
Faculdade de Ciências, Universidade de Lisboa, Lisboa, Portugal
e-mail: [email protected]; [email protected]
V. Gramoli (O)
University of Sydney, Camperdown, NSW, Australia
EPFL, Lausanne, Switzerland
e-mail: [email protected]

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2024 3

S. Ruj et al. (eds.), Blockchains, Advances in Information Security 105,
https://doi.org/10.1007/978-3-031-32146-7_1
4 D. Hyland et al.

easily find scenarios in which these protocols fail [6, 19, 33, 60]. As blockchains are
becoming important components to guarantee the security of critical applications,
these myths can have devastating effects, whose latest example is probably the
vulnerability of some of the mostly deployed blockchain software (e.g., parity
and geth) [31], used to handle high-value digital assets. Other examples include
the recent efforts devoted to develop quantum-resilient cryptographic software on
top of blockchain systems that are already vulnerable to the misbehavior of a single
participant [20]. While cryptography and fault tolerance address problems that may
seem orthogonal, a blockchain cannot provide the security level required by such
applications without both cryptography and fault tolerance (cf. Myth #7).
As blockchains are now being offered as a service by most cloud providers and
have become the cornerstone of various applications, it is crucial to clarify some of
the misconceptions that will have, sooner or later, dramatic consequences. Some of
these misconceptions could be attributed to the lack of knowledge of the distributed
computing and database literatures. First, there are various failure models in which
an algorithm can solve consensus. In fact, a consensus algorithm typically allows n
nodes (or processes) reach an agreement despite f of them failing. These failures are
generally classified in two types: crash, where a node simply stops, and Byzantine,
where a node behaves arbitrarily, misbehaving either accidentally or with malicious
intent. This is why we distinguish crash fault-tolerant (CFT) from Byzantine
(or arbitrary) fault-tolerant (BFT) protocols (cf. Myths #6 and #8). Second, the
three properties of the classic consensus problem [44] are often misinterpreted:
(i) validity requires that the value decided by a non-faulty (or correct) node has to
be valid, (ii) agreement requires that two non-faulty nodes cannot decide differently,
and (iii) termination requires that eventually the non-faulty nodes decide. Also,
the factors affecting the performance of a blockchain are often misunderstood
(Myths #4 and #5) as they typically embed, in addition to the consensus protocol,
other components like cryptography (Myth #11). This may distract engineers
from other challenging problems (Myths #9 and #10). One of the most common
misinterpretations is illustrated by the large family [49] of so-called proof-of-∗
consensus (sic) that cannot ensure agreement upon a unique block and may lead
the blockchain to counterintuitively fork into multiple branches (cf. Myth #3).
The aim of this chapter is to bust ten myths about blockchain consensus,
summarized in Table 1. These myths correspond typically to misinformation that
professionals and students commonly learn by reading posts and blogs online before
attending a blockchain course. We proceed by listing each myth and explaining
why it is incorrect by offering a counterexample, sometimes using a blockchain
(Hyperledger Fabric, Red Belly Blockchain, or R3 Corda) or a consensus algorithm
(BFT-SMaRt, DBFT, or HotStuff). Our aim is not to survey existing approaches
for blockchain consensus, as there is an extensive literature on the subject (e.g.,
[19, 49]), neither to provide a formal treatment of these myths but rather to state
them in a pedagogical language to reach the blockchain community at large. As
some of these clarifications already helped improving the scalability of blockchains
(Myth #12), we hope that they will help build secure and efficient blockchain
applications in the future.
Ten Myths About Blockchain Consensus 5

Table 1 A summary of common blockchain consensus myths

# Myth Clarification At risks
1. Po* solves consensus Po* selects blocks without Users
guaranteeing uniqueness
2. Consensus bottlenecks blockchain in BFT-SMaRt runs faster outside Designers
LANs Hyperledger
3. Consensus bottlenecks distributed DBFT and BFT-SMaRt scale better Designers
ledgers in WANs outside Corda
4. CFT consensus tolerates Byzantine BFT quorums are larger than CFT ones Users
faults
5. Signatures and hashes make They do not cope with disagreement Users
blockchain secure and double spending
6. A CFT blockchain with a BFT The whole communication pattern Users .+
consensus becomes BFT needs to be changed Designers
7. BFT consensus needs linear message Some quadratic complexity algorithms Designers
complexity perform better
8. Reconfiguring consensus It is difficult to make it non-disuptive Designers
participants is easy
9. Blockchain performance is not CPU demand can surpass the network Designers
limited by cryptography demand of consensus
10. Blockchain needs to solve the Deciding .o(n) proposals help scale Designers
classic consensus problem

2 Background on Consensus and Proof-of-∗

Before listing each myth, we present various interpretation of the term “consensus”
in the blockchain context. A blockchain is easily understood as a chain of blocks
abstraction where new blocks get regularly appended; however, the system that
replicates this abstraction on multiple machines or nodes of the network does not
always maintain the sequence structure of the chained blocks.
Instead a more precise description of this abstraction is a directed acyclic graph
or—to put it simply—a tree structure whose nodes are blocks and whose edges are
directed upward in the tree, from children blocks to their parent block [35]. Each
of these edges is implemented as a hash of the content of the parent block stored as
a field of the child block. A parent block has multiple children in the tree as soon
as the blockchain forks, which means that two nodes disagree about the block that
should be inserted at the next available index of the chain. The consensus abstraction
is employed to guarantee that there is no such disagreement among all nodes about
the unique block to be appended next.
The consensus problem was defined more than half a century ago [52] and
requires to guarantee that if replicas propose their block, then no two replicas
should decide differently (agreement), the block that is decided is one of the
proposed block (validity), and the non-faulty replicas should eventually decide
(termination). While this definition presents some inherent limitations for scalability
that will be discussed in Myth #11, it paved the way for research on consensus
6 D. Hyland et al.

algorithms in small settings and influenced newer definitions of the consensus

problem considering cryptography [18] and scalability [24, 25].
Interestingly, the term “consensus” has been extensively used on blog posts
and websites about blockchain to denote proof-of-∗ methods of selecting a subset
of blocks proposed to a particular index of the blockchain. As surveyed in [49],
these proof-of-∗ (Po*) methods include proof-of-work, proof-of-reputation, proof-
of-lock, proof-of-activity, proof-of-stake, proof-of-burn, proof-of-authority, and
proof-of-location, each choosing a different local attribute in order to decide whether
a block is selectable to a particular index. These attributes include the computational
power of the node, stake owned by the node in the considered blockchain system,
its activity, location, etc. The diversity of existing proof-of-∗ makes it difficult to list
them all here and is not part of the scope of this paper.

3 Myth #1: Proof-of-∗ Solves Consensus

A proof-of-work [29] is a mechanism to limit the power of the adversary that

can control the Byzantine participants. By requesting each participant to solve a
moderately complex crypto-puzzle and produce a proof of this effort, called proof-
of-work, before producing a block [48], the ability for the adversary to overwhelm
the system with new valid blocks becomes limited by its computational power. Many
alternatives to this proof-of-work mechanism have been proposed, like proof-of-
stake that limits the power of the adversary to its stake, hence leading to the large
family of proof-of-∗ mechanisms. For a list of more than a dozen of these proof-of-∗
proposals, we refer the interested reader to a survey on the topic [49].
As it is widely believed that proof-of-∗ protocols solve consensus,1 many proto-
cols have been called “proof-of-∗ consensus (sic).” As an example, Cointelegraph
explains how proof-of-work can be seen as the “original consensus algorithm in a
blockchain network” by using a “complicated mathematical puzzle and a possibility
to easily prove the solution.”2 It may seem as if “proof-of-work consensus”
was a metonymy aimed at being pedagogical and referring to proof-of-work as
the component of a more complex consensus procedure. However, the frequent
forks [64] in proof-of-work blockchains indicate the possibility of disagreements,
which contradict the scientific notion of consensus [52]. This metonymy, albeit
simple, hides more complex intricacies. Such simplifications put the users at
risk, because, strictly speaking, consensus prevents double spending that could be
induced by forks whereas proof-of-∗ actually tolerates forks and may lead to double
spending.

1 Wikipedia makes use of the term “proof-of-work consensus (sic)” at https://en.wikipedia.org/

wiki/Proof_of_work.
2 https://cointelegraph.com/explained/proof-of-work-explained.
Ten Myths About Blockchain Consensus 7

Fig. 1 Proof-of-∗ mechanisms do not solve the consensus problem. Instead, they select a subset,
say, .{b1, b3}, of proposed blocks, say, .{b1, b2, b3}, as legitimate based on some attribute (com-
putational power, coins owned, etc.) of the nodes that generated them, but a separate consensus
algorithm is necessary to guarantee that the block, like b3, decided for a given index of the chain
is unique

In fact, the proof-of-∗ mechanism cannot solve consensus but is instead a mech-
anism to enforce some of the consensus prerequisites so that a proper consensus
algorithm can be executed. Typically, a proof-of-∗ mechanism selects a small subset
of nodes to participate in the consensus by proposing a block for the same index of
the chain as depicted in Fig. 1, where .{b1, b3} are proposed. As this mechanism
cannot guarantee that a unique block is proposed, it is insufficient to decide a single
block and does not solve the consensus problem. Recently, researchers have tried to
clarify the terminology to address this confusion [36], but it remains well spread on
the Internet.

3.1 Example: Bitcoin

Bitcoin [48] uses proof-of-work to limit the number of nodes that can create a
new block for a given index of the chain. Once these blocks are created, Bitcoin
solves consensus by deciding among multiple candidate blocks (that all contain a
valid proof-of-work) the unique block that is part of the longest branch. This is
the reason why Bitcoin [48] uses an extra mechanism, Nakamoto’s consensus, to
try to solve the problem: it selects the blocks of the longest branch by assuming
that the delay to create and propagate every block to all miners in the network is
upper-bounded such that every miner can safely choose the candidate block at index
i once they have waited long enough [34]. The proof-of-work mechanism helps
limit the block creation speed by requiring that a node first solves a computationally
hard crypto-puzzle before propagating a new block. This proof-of-work mechanism
alone does not ensure the uniqueness of the block at each index—this is precisely
why a separate consensus protocol based on identifying the block of the longest
branch is required in Bitcoin.
8 D. Hyland et al.

4 Myth #2: Consensus Is the Bottleneck of Blockchains in

LANs

Distributed consensus performance (expressed, e.g., in decisions per unit of time)

generally degrades with the number of participants. This led to the folklore belief
that the performance of consensus is the key limiting factor of the performance of
the blockchain in normal executions as was described by NEC.3 Typically, BFT
consensus algorithms involve a quadratic number of messages [13, 21, 24] that
are believed to rapidly consume the limited bandwidth resource. For example, the
classic PBFT consensus algorithm [21] employs a distinguished participant, the
leader, proposing a value and having participants exchanging sufficiently many
prevotes to make sure that no other value will be accepted and then having
participants exchanging sufficiently many votes to make sure the value is accepted
by other participants before deciding this value.
For this reason, it has long been thought that a blockchain performance is limited
by the performance of its consensus, and recent solutions, like HotStuff [65],
attempted to boost blockchain performance by reducing the message complexity
of the consensus algorithm using threshold signatures (as discussed in Myth #9).
HotStuff follows the classic leader-based pattern but reduces the quadratic message
complexity, induced by the participants sending prevotes and votes to each other, to
the linear complexity, induced by the participants sending their prevotes and votes
only to the leader that retransmits them.
It turns out that there are other scalability limitations in blockchain systems,
especially in local area networks (LANs)—one example is the verification of
transaction signatures [12, 62]. Traditional blockchain would require every node
to verify the signatures of every transaction. Although there are some blockchains
that employ verification sharding [25] for each signature to be verified by only
.f + 1 nodes, in general, even this optimization is not sufficient to make the

verification finish significantly earlier. We present the cost of verification sharding in

Myth #11. Additionally, previous works [66] point the execution of smart contracts
as a significant scalability limitation, specifically the frequent disk operations they
cause as well as their computational cost.

4.1 Example: Hyperledger Fabric

In order to test our hypothesis on the existence of other performance limitations,

we selected the Hyperledger Fabric blockchain [3] that aims at being modular and
offering privacy. Even though Hyperledger Fabric v1.x is crash fault tolerant and
does not aim at tolerating malicious behaviors, there exists a prototype version [57]
that makes use of a BFT orderer (cf. Myth #8 for more details) based on BFT-

3 https://www.nec.com/en/global/insights/article/2020022520/index.html.
Ten Myths About Blockchain Consensus 9

SMaRt. BFT-SMaRt [13] is a modular BFT consensus protocol in which a stable

leader sends a proposal to all nodes that confirm its consistency in two all-to-all
communication steps, similar to PBFT [21]. The goal of the test is to observe
whether Hyperledger Fabric could offer similar performance as its consensus or
orderer component alone, when run in the same environmental settings.
We ran the Hyperledger Fabric blockchain system and a BFT-SMaRt baseline
on four machines, each with Ubuntu Linux 14.04.1 LTS, hosted in Dell PowerEdge
R410 servers. Each machine has 32 GB of memory and two quad-core 2.27 GHz
Intel Xeon E5520 processors with hyper-threading. These machines communicate
through an isolated gigabit Ethernet LAN. The results were obtained with Hyper-
ledger Caliper [17] and are averaged over five runs with error bars showing the
standard deviation. Figure 2 depicts throughput for HLF-BFT for blocks of 10
(HLF-BFT10) and 100 (HLF-BFT100) transactions of payload 4 KiB and envelopes
of 900 bytes, HLF-Solo for blocks of 100 transactions (Caliper benchmarks could
not complete with blocks of 10) and a BFT-Only benchmark with blocks of 10
transactions. We can clearly observe that the Byzantine fault-tolerant orderer based
on BFT-SMaRt [57] performs .2× better than Hyperledger Fabric with the same
version of this orderer. Furthermore, the BFT-SMaRt replication library alone,
without the required Fabric machinery, can order .5× more 4 KiB transactions per
second than what was obtained in the orderer [13].

Fig. 2 In a LAN, Hyperledger Fabric running with an experimental BFT orderer based on BFT-
SMaRt is slightly slower than without consensus (HLF-Solo) but significantly slower than the BFT
orderer alone (BFT-Only). This indicates that the bottleneck of blockchains is not necessarily their
consensus component
10 D. Hyland et al.

5 Myth #3: Consensus Is the Bottleneck of Distributed

Ledgers in WANs

Myth #4 showed that consensus is not necessarily the bottleneck of a blockchain

in a LAN. This result could be attributed to the blockchain prototype in use, and it
is interesting to explore whether the same observation would apply to a distributed
ledger like Corda [15] that aims at enabling businesses to transact in privacy using
smart contracts without necessarily chaining blocks. Additionally, Myth #4 did
not contradict the belief that the consensus protocol could be the bottleneck of
a distributed ledger deployed on the Internet. A LAN typically offers bandwidth
resources that are not comparable to the resources one could obtain in a wide area
network (WAN) subject to congestions, long distances, etc.
Here we push the study one step further by selecting a recent BFT consensus
protocol designed especially for distributed ledgers, DBFT [24], and two versions of
Corda, its public version and its enterprise edition, and running experiments across
four regions, in Australia, Brazil, Europe, and the USA. The goal of these new sets of
experiments is to pinpoint what overhead comes from the consensus itself and what
overhead comes from other parts of the distributed ledger. If consensus was truly the
bottleneck of the distributed ledger, the performance of the distributed ledger would
be comparable to the performance of its bottleneck when running in isolation.

5.1 Example: Corda

Corda is crash fault tolerant as it uses the Raft consensus algorithm and cannot
tolerate Byzantine failures. In fact, some of us tried deploying a BFT prototype of
Corda running on BFT-SMaRt in the past, however, we were not able to make it run,
and the Corda developers recommended that we use the crash fault-tolerant version
instead [38]. We thus modified Corda to use BFT-SMaRt and DBFT as consensus
algorithms. DBFT is a formally verified consensus protocol [24, 60] that differs from
the previously mentioned leader-based protocols as each of its n participants reliably
broadcasts its proposal to other nodes and spawns n binary consensus instances that
define a bitmask in order to output a decision. We measure both the throughput of the
Corda distributed ledger, its public and enterprise version Corda 4.0-SNAPSHOT,
and the throughput of the BFT-SMaRt and DBFT consensus algorithms, as the
average observed over four runs on Amazon Web Services (AWS) EC2 instances.
As in Corda, each transaction has a serialized size of 8 KiB bytes (that is much larger
than the original size); we use the same transaction size for running the consensus
algorithms alone.
Figure 3a compares the throughput of DBFT and Corda with DBFT on four
c5.large instances, each with one hyperthreaded Intel Xeon 8124M core. We also
add the throughput of Corda enterprise with DBFT on 4 c5.9xlarge instances, each
with 18 hyperthreaded Intel Xeon 8124M cores. We execute DBFT in two setups. In
Ten Myths About Blockchain Consensus 11

(a) (b)

Fig. 3 The bottleneck of distributed ledger is not necessarily the consensus protocol. (a) When
running with the DBFT consensus, the public and the enterprise versions of the Corda distributed
ledger are significantly slower than DBFT alone. (b) When running with the BFT-SMaRt
consensus, the enterprise version of Corda runs slower than BFT-SMaRt alone. (a) Corda w/ DBFT
vs. DBFT alone. (b) Corda w/ BFT-SMaRt vs. BFT-SMaRt alone

the “DBFT-Local” setup, the four instances are in a single datacenter. In the “DBFT-
World” setup, each instance is in a separate datacenter located in Ohio, Frankfurt,
Sydney, and São Paulo. We execute Corda in a local setup only as we did not manage
to deploy it on a geo-distributed setup. The result indicates that with comparable
setups the throughput of DBFT is .156× higher than the throughput we could obtain
from any version of Corda running DBFT with the same number of cores. Moreover,
DBFT executed on a georeplicated setup on a 2-core machine still has a throughput
.1.8× higher than Corda on a local setup with a 36-core machine and .6.4× higher

than Corda on a local setup with a 2-core machine. We were not able to locate
precisely the cause of the Corda performance drop; however, we observe that Corda
enterprise performance increases with the number of cores. This seems to indicate
that the throughput of Corda is limited by computation.
In Fig. 3b we compare the throughput of BFT-SMaRt and Corda enterprise with
BFT-SMaRt on 16 and 20 c5.4xlarge instances, each with 8 hyperthreaded Intel
Xeon Platinum 8275CL cores. Similar to DBFT, deploy BFT-SMaRt in two setups.
In the “Local” setup, all instances are in the same datacenter. In the “World” setup,
instances are spread among four datacenters in Ohio, Frankfurt, Sydney, and São
Paulo. We execute Corda in a local setup only as we did not manage to deploy it on
a geo-distributed setup. We observe that, on a local setup, the throughput of BFT-
SMaRt is consistently more than .6× larger than the throughput of Corda. Moreover,
even when executed in a geo-distributed setup, the throughput of BFT-SMaRt is
still more than .2× larger than Corda executing in a single datacenter. Since the
only difference between BFT-SMaRt and Corda is the set of operations outside the
consensus, this performance gap indicates that these additional operations are the
bottleneck of the Corda distributed ledger.
12 D. Hyland et al.

6 Myth #4: CFT Consensus Algorithms Are Safe Under

Byzantine Faults

There is a misconception that CFT protocols are enough for implementing a

safe blockchain consensus. In particular, the possibility that Byzantine nodes can
affect the safety of these protocols is often overlooked: two recent consensus
algorithms, called Clique and Aura [41], have been integrated in two of the mostly
deployed blockchain software, called geth and parity, in order to cope with
.[n/2] − 1 Byzantine failures, a problem that is known to be unsolvable [14]. As

a result, the Attack of the Clones led to double spending in two testnets running
these software [31], hence demonstrating, in practice, this safety violation. More
generally, consider a system with n nodes in which up to f can fail. In a practical
system, where there are no strict time bounds for communication, a node can wait
for responses from at most .n−f nodes (a quorum) since up to f nodes can be faulty
and never answer. In such systems, quorums must intersect in at least one correct
process to ensure actions observed from a quorum (i.e., a subset of .n − f nodes) are
observable from any quorum. In the crash failure model, all .n − f responding nodes
are correct, and thus .n > 2f (the number of nodes in any two quorums must be
greater than the total number of nodes in the system, i.e., .(n − f ) + (n − f ) > n) is
enough to ensure intersection. In the Byzantine model, there might be faulty nodes
in an accessed quorum sending wrong values; therefore .n > 3f (the number of
nodes in any two quorums must be greater than the total number of nodes in the
system plus the maximum number of “liars,” i.e., .(n − f ) + (n − f ) > n + f ) and
quorums intersecting in at least .f + 1 nodes.

6.1 Example: Raft

In Fig. 4, one can see that two quorums of three nodes intersecting at one node could
be sufficient to ensure safety if nodes can only crash but would violate safety if the
intersecting node misbehaves by responding that no new transaction .tx has been
written. Raft [51] is a CFT protocol currently employed in popular blockchains
such as Corda [15] and Hyperledger Fabric [3]. In Raft, a leader coordinates the
replicated execution by writing the next transaction to be processed onto a write
quorum and then informs the client that its transaction is committed as depicted
in the distributed execution of Fig. 4 where time increases from left to right. If,
after this, the leader fails before committing this transaction in all servers and a
new leader takes over, this new leader will read the pending transactions to ensure
the same safety requirement of the algorithm: that if some server committed this
transaction, all servers will commit it in the same position on the transaction log.
If this new leader accesses a read quorum that intersects with the write quorum in a
single server (as in the figure), and if this server is Byzantine and misbehaves, then
it can lie about what happened (ignoring or replacing the transaction) and make the
Ten Myths About Blockchain Consensus 13

time write(tx) ack read() tx

client
quorum quorum

leader
write

node1 fault

Byzantine node
read

node2
new leader
tx

Fig. 4 A possible execution of a replicated write-then-read with a quorum size of .[n/2] + 1. We

assume the quorum leaders are correct for simplicity. The execution would be correct in a CFT
model but is incorrect in a BFT model. The intersection of BFT quorums should be larger than
the intersection of CFT quorums for the consensus protocol to guarantee safety. If the intersection
contains only Byzantine nodes, then the response obtained after reading from a quorum can violate
safety, which can be exploited to double-spend in cryptocurrency applications

new leader commit a corrupted state, hence violating safety. This is precisely why, in
contrast with Raft, BFT systems typically use quorums whose intersections contain
at least .f + 1 nodes.

7 Myth #5: A Blockchain with Signatures and Hashes Is

Secure

An important misconception is that cryptography could solve the same problem

as fault tolerance as illustrated by quantum-resilient efforts devoted on top of
fundamentally insecure blockchains [20]. In particular, public-key cryptosystems
are typically used in blockchains to ensure authentication: if a transaction is not
signed by the owner of the account from which it tries to withdraw, then it is
rejected—meaning that the signature is incorrect. Combined with hashes these
signatures guarantee tamper evidence in that a non-authorized change will be easily
detected as the hash of the signed transaction will not correspond to the observed
signatures. These guarantees are not sufficient for security to ensure, for example,
that a client is observing the right blockchain version. A malicious node could
convince a client who acts as a merchant that a transaction buying its product is
committed while it is not. To do so, the malicious node presents a fake version of
the blockchain where it appends correctly signed transactions that it created without
ever sending them to the actual blockchain.
This misconception is illustrated by some recent efforts devoted to develop
quantum-resilient cryptographic software [20] on top of blockchain systems because
these blockchains cannot tolerate the misbehavior of a single participant. In fact,
quantum resilience aims at coping with the misbehavior of a quantum computer
node to avoid asset theft, yet the misbehavior of a single node participating in the
underlying CFT blockchain is sufficient to produce this theft, hence defeating the
purpose of the quantum resilience.
14 D. Hyland et al.

7.1 Example: Raft

To guarantee that a client can truly identify whether its transaction is committed, it
must make sure that .f + 1 nodes say so. If not, it risks to be a victim of a double
spending where the coins used in the supposedly committed transaction of the fake
version are actually reused in a truly committed transaction of the blockchain.
Notice that the use of signatures cannot help in the Raft scenario described in
Myth #6. If the write operation of the leader is signed in Fig. 4, the Byzantine node
on the intersection cannot create a different proposal (with .tx ' ) for the leader, but
it can still hide it, stating it has not received any transaction at all. In this way,
the transaction, despite being confirmed to the client, will be “undone” from the
system history, opening up the possibility of double spending attacks that may be
devastating for financial applications. More generally, there exist various attacks
against blockchains that rely on delaying messages (e.g., selfish mining [32], eclipse
attacks [39], BGP hijacking [5], and more generally man-in-the-middle attack [30])
that an attacker can exploit to double spend without violating authentication or
forging private keys.

8 Myth #6: Adding a BFT Consensus to a CFT Blockchain

Makes It BFT

Modularity is important for enabling project collaboration at the heart of open-

source communities. Due to this, several blockchain platforms have been built with
modular or replaceable components [3, 8]. Hyperledger Fabric separates the orderer
service in charge of ordering transactions from the endorser service in charge of
validating transactions to offer modularity [3]. In particular, Fabric offers several
interchangeable orderers, a centralized service, a CFT one, and an experimental
BFT one [57], hence illustrating this modularity.
A common mistake stems from extrapolating the guarantees offered by a module
of a blockchain system to the whole blockchain system, for example, when using
Corda in applications where a consortium of competitors do not trust each other4 or
when using a BFT orderer within Hyperledger Fabric, which tolerates only crashes.
To illustrate this issue, let us consider a distributed ledger that tolerates only crash
failures, like Corda or Hyperledger Fabric—this type of distributed ledgers can
thus only run in a trustworthy environment as its guarantees would be violated if
a participant misbehaves. A developer who want to make the blockchain service
more robust may identify the consensus module as a module that is limited by its
crash fault tolerance and be tempted to replace it by a more robust module offering
Byzantine fault tolerance. If the blockchain system is modular enough, then the

4 https://www.corda.net/samples/.
Ten Myths About Blockchain Consensus 15

Fig. 5 A client contacting a single Byzantine front-end server makes the BFT consensus useless.
This is why replacing one component of the software architecture is rarely sufficient to make a
blockchain originally tolerant to crash failures, a blockchain that also tolerates Byzantine failures

developer expects the BFT consensus module to have the same interface as the
CFT module. However, typical BFT services do not have the same interface as
CFT services, precisely because the acknowledgment of a Byzantine server does
not convey the same guarantee as the acknowledgment of a correct server. Figure 5
depicts the problem that might happen when the interface remains unchanged while
the model changes from CFT to BFT: the client might be fooled by a flawed
acknowledgment coming from a Byzantine front end while it could only receive
correct servers in a CFT model.

8.1 Example: Hyperledger Fabric and BFT-SMaRt

Hyperledger Fabric [3] defines a modular architecture for supporting permissioned

blockchains, which is used in production since version 1.0.5 An important com-
ponent of this architecture is the orderer service, a group of nodes responsible
for ordering and packing transactions into blocks. At the time of writing, Fabric
supports only CFT orderers: one based on Apache Kafka and another based on
CoreOS’ Raft implementation. In both cases, a single front end/server receives
the transaction to be ordered and produces and signs the block (with ordered
transactions) in the end. This design still tolerates crashes because there are
redundant front ends in the system, and in case of failures, a backup front end takes
over the role. However, in this model, even if we replace Raft by PBFT [21], the
front end of the ordering service will still be receiving and signing the block. An
experimental BFT orderer available for Fabric [57] changes this design to make the
server create a block and sign it; however, it impacts modularity. In the end, the
final generated block is signed by at least .f + 1 servers. Yet, this change requires
additional changes in other modules, say, to verify these .f + 1 signatures. This
shows that replacing a module was insufficient.

5 https://www.fintechfutures.com/2017/03/ibm-cloud-launches-enterprise-ready-blockchain-for-

hyperledger-fabric/.
16 D. Hyland et al.

9 Myth #7: BFT Consensus Needs a Linear Message

Complexity

It is often the case that bad consensus performance at large scale is attributed to the
all-to-all communication pattern of state-of-the-art consensus protocols [23, 63, 65].
In fact n servers sending messages to all other servers necessarily lead to a quadratic
message complexity [13, 21, 22]. As a result, lots of efforts have been devoted to
replacing all-to-all message exchanges by one-to-all exchanges [1, 7, 8, 42, 65].
The consensus protocol at the heart of Facebook’s blockchain [65] is a typical case
which uses threshold signatures to replace all-to-all by one-to-all communications.
This result in a linear message complexity for the steady-state case. It appears that
improving this message complexity does not necessarily lead to better performance.
Several factors may limit the throughput of a replicated state machine before the
message complexity becomes an issue. Some of these factors are the computational
cost of cryptography (cf. Myth #11), the latency of writing new blocks to stable
storage [12], the unique value decided per consensus instance (cf. Myth #12), and
the use of a slow leader [4, 10].

9.1 Example: HotStuff vs. Democratic BFT (DBFT)

In Fig. 6, we compare the throughput of two systems, HotStuff [65] and DBFT [25],
when the number of server increases on two different setups. On the “Europe” setup,
a total of 64 or 128 servers run in 4 different AWS datacenters in Ireland, London,
Paris, and Frankfurt. On the “World” setup, a total of 80 servers run in 4 different
AWS datacenters in Ohio, Frankfurt, Sydney, and São Paulo. Each server is an
AWS EC2 c5.xlarge instance with two hyperthreaded Intel Xeon 8124M cores for
a total of four hardware threads. HotStuff has a linear message complexity, while
DBFT has a quadratic message complexity. The DBFT replicated state machine
does not use any specific optimization and is written in Java. HotStuff replicated
state machine uses pipelining to reduce communication delays and is written in
C++. We use transactions of 400 bytes, which is a typical Bitcoin transaction size.
We observe that DBFT has a throughput up to .11× larger than HotStuff in the
“Europe” setup and .16× larger in the “World” setup despite the fact that HotStuff
has a better message complexity. We explain this difference by the fact that the
HotStuff consensus is leader based and uses expensive threshold signatures while
DBFT consensus is leaderless and its most expensive operation is a cryptographic
hash. While we do not deny the impact of message complexity, we stress that other
bottlenecks limit a consensus performance before message complexity becomes an
issue.
Ten Myths About Blockchain Consensus 17

Fig. 6 Linear message complexity does not always bring good performance. The throughput of
DBFT, which has a quadratic message complexity, is always higher than HotStuff, which has a
linear message complexity in the steady state. This is because DBFT balances the network load on
more links

10 Myth #8: Reconfiguring Consensus Participants Is Easy

Consortium blockchains rely on a globally known set of participants. This set of

participants does not change while the consensus decides a new block. However, it
is necessary or even desirable to change this set regularly between the consensus
executions (e.g., to prevent bribery attacks). This operation, called reconfiguration
or membership change, seems to be a built-in feature of some blockchains. For
example, Tendermint design mentions validator set changes [58], but unfortunately
this requires to shut down the blockchain. One of the challenges is purely related to
software design as it is generally hard for a complex system to handle component
hotplug [40, 47]. A more subtle issue is the possibility of blockchain forks when
reconfiguration is employed, since participants already removed from the group can
be compromised and cope with the ledger [12]. More generally, the challenge is for
the system client to know where to send requests as the participant set changes over
time. This last challenge is especially hard since a malicious front end could always
present fake participant set in a scenario similar to Myth #8.
18 D. Hyland et al.

10.1 Examples: Hyperledger Fabric and Tendermint

Hyperledger Fabric aims at supporting membership changes without compromis-

ing the network; however, it still “requires that the peer or orderer process is
restarted.”6 Tendermint mentions validator set changes [58]; however, this requires
an external application that handles those reconfigurations.7 BFT replication sys-
tems like BFT-SMaRt also require a trusted external application to manage such
reconfigurations [13]. New implementations to reconfigure the Byzantine consensus
participants rely on consensus protocol themselves and need a trusted domain name
system to catch up with the latest configuration [61] and a forgetting protocol
to ensure removed participants are unable to validate blocks from an invalid
fork [12]. These new implementations make it possible for alive participants (i.e.,
participants being notified of configuration changes when they happen) to keep
track of the system configuration. However, participants joining the system for the
first time or catching up after being offline still have to rely on a permissioned
trusted infrastructure that cannot be reconfigured, hence falling back on the initial
challenge.

11 Myth #9: Blockchain Performance Is Not Limited by the

Cryptography

Blockchain is believed to be bottlenecked by the large bandwidth consumed by

its Byzantine consensus component. This is the reason why substantial efforts
were devoted to reduce communication complexity at the price of increasing CPU
overhead through the use of threshold signatures [65] (cf. Myth #9). There is,
however, a CPU bottleneck induced by the cryptographic verification of transaction
signatures inherent to blockchain systems [25, 59] that is often neglected. In
particular, this CPU-intensive verification is necessary to ensure that a Byzantine
node does not withdraw an amount of assets from the account of someone else.
Each transaction has thus an associated signature that needs to be cryptographically
verified. This verification limits the speed at which the blockchain can commit
transactions.

11.1 Example: Red Belly Blockchain

Red Belly Blockchain [25] relies on verification sharding to minimize the number
of verifications needed per transaction and to maximize its performance. The idea

6 https://hyperledger-fabric.readthedocs.io/en/latest/msp.html.
7 SeeSection 7.1, second paragraph, of https://atrium.lib.uoguelph.ca/xmlui/bitstream/handle/
10214/9769/Buchman_Ethan_201606_MAsc.pdf?sequence=7&isAllowed=y.
Ten Myths About Blockchain Consensus 19

Fig. 7 The performance of Red Belly Blockchain decreases with the number of verifications of
transaction signatures that is linear in the fault tolerance

is to have each transaction being verified by between .f + 1 and .2f + 1 nodes

instead of all nodes in order to minimize CPU consumption. Figure 7 depicts the
throughput (expressed in 400-byte transactions per second) of Red Belly when
increasing the number of failures f on 140 c4.8xlarge AWS VMs geo-distributed
on 4 continents (see details in [25]). The performance decreases linearly with the
system fault tolerance f precisely because the number of verifications per node
increases, illustrating the negative impact of verifications on the throughput of Red
Belly Blockchain. Note that similar observations have been made in the context of
Hyperledger Fabric [59] where the caching of verified endorsement certificates led
to significant performance improvements.

12 Myth #10: Blockchain Needs to Solve the Classic

Consensus Problem

A blockchain system needs a consensus protocol to totally order a series of

blocks in order to guarantee that the blockchain it implements remains a chain.
If disagreement happens, then the blockchain forks, making the system vulnerable
to double spending. As participants can be incentivized to steal assets from others,
most systems resort to traditional Byzantine consensus protocols [52], which ensure
(1) agreement in that correct nodes cannot decide different values, (2) termination
in that a correct node eventually decides, and (3) validity in that the decided value
is one of the proposals. This is what is done in most blockchain systems that
rely on a BFT consensus: Tendermint consensus [43] uses a variant of DSL [28],
Facebook’s Libra [8] uses HotStuff [65], and an orderer of Hyperledger Fabric uses
BFT-SMaRt [13].
20 D. Hyland et al.

These protocols share the same goal of guaranteeing that only one proposal
among all the proposals of the system gets decided. This means that if each server
proposes .O(1) transactions to the consensus service, then the number of transactions
decided by the consensus is .O(1), regardless of the number of servers participating
in the protocol. This happens because they ensure this classic notion of consensus
validity where the value decided is one of the proposed values. There is a variant
of consensus for the Byzantine model that replaces this property. For instance,
in interactive consistency [44], which is well suited for synchronous system but
cannot be solved in a partially synchronous environment, the proposed values of all
correct nodes are obtained in the end. Another definition is vector consensus [27, 50]
that requires servers to decide the same vector containing at least .f + 1 values
proposed by different servers, where f is the maximum number of Byzantine
failures. Unfortunately, in blockchain systems one cannot guarantee that .f +1 values
are valid, and thus, we would need to select the union of the valid transactions in
each vector position. In particular, proposers (or miners) typically group transaction
requests from client and cannot guarantee that all the received transactions are
valid. An alternative to this problem is thus to relax the validity further to only
accept values as long as they are deemed valid by the application (e.g., are correctly
signed [13, 18]) but without any restrictions on their numbers [24, 25].

12.1 Example: Validity Predicate-Based Byzantine Consensus

Problem

With this new consensus definition called validity predicate-based consensus [24],
one can thus have distinct servers collecting transaction requests from the clients and
then propose a batch of these transactions to a common consensus instance. If each
of n servers proposes disjoint batches of .o(1) transactions, and provided that the
transactions are correctly signed, then the number of transactions that can be decided
at the end of the consensus is .o(n). This approach is currently implemented in the
pipelined Byzantine state machine replication, called Dispel [62], and in Red Belly
Blockchain [25] in the form of a Set Byzantine Consensus solution. As depicted in
Fig. 8, the number of committed transactions per consensus instance is linear in the
number of servers participating, and the throughput of the blockchain system grows
with the number of servers (until exhaustion of some resources). This Byzantine
consensus variant is especially designed for the geo-distributed environment of
blockchains.
Ten Myths About Blockchain Consensus 21

Fig. 8 A protocol solving the classic consensus definition would commit less transactions than
one solving predicate-based validity consensus

13 Final Remarks

Related Work Although we are not aware of any work focusing on debunking
blockchain myths, there are several research papers presenting evidence contra-
dicting previous claims about blockchain consensus. Armknecht et al. [6] show
that some assumptions listed in the Ripple consensus protocol white paper are not
sufficient to ensure its safety. Cachin and Vukolić [19] explain that proof-of-work
blockchains do not offer finality. Amoussou-Guenou et al. give counterexamples
where Tendermint core does not solve consensus [2]. Saltini and Hyland-Wood [54]
explain that the consensus at the heart of the Quorum blockchain does not
terminate. Tholoniat and Gramoli [60] explain that the consensus at the heart of
HoneyBadgerBFT does not terminate and argue in favor of formal verification. We
ourselves rely on the correctness of consensus protocols to debunk these myths, but
we have chosen the BFT-SMaRt library that has been publicly available for more
than a decade [13] and Democratic BFT [24] that has recently been formally verified
using parameterized model checking [11].
Prior to this work, various efforts were dedicated to evaluating the performance
of distributed ledgers. BFT-Bench [37] predates blockchains and evaluates multiple
BFT consensus algorithms. Blockbench [26] and [53] compare the performance
of proof-of-work blockchains against private blockchains. Han et al. measures the
number of participants at which the performance of blockchain drops [38]. Some
evaluate proof-of-authority blockchains [45] that rely on a set of n authoritative val-
idators among which at most f can be Byzantine to run the consensus. An evaluation
focuses on comparing the performance of Byzantine fault-tolerant blockchains [56],
whereas the recent DIABLO benchmark allows to measure blockchain performance
under realistic workloads [9].
Random documents with unrelated
content Scribd suggests to you:
5. After a new stay in the Soissons region (August and September) the whole division was again
engaged in the Somme between Rancourt and the St. Pierre-Vaast wood. It suffered very heavy
losses near Bouchavesnes (Oct. 1–10).
6. At rest from October 14 to 21 in Woevre.

Côtes de Meuse.

7. At the end of October, the 113th Division took over the Bonzee-Ronvaux sector (Côtes de
Meuse).

1917.

1. The 113th Division stayed around the Côtes de Meuse until the end of January, 1917.

Alsace.

2. At the beginning of February it went into Alsace and occupied a sector between the Thur and
the Rhone-Rhine canal (March).

Chemin des Dames.

3. On April 21 it was hastily entrained at Mulhouse and transferred to the Aisne. It went into line
on the 26th at Chemin des Dames and met the second French offensive in the Courtecon-Malval
farm region (May 5).

St. Gobain Forest.

4. Relieved in the middle of May, it stayed at rest for six days in the vicinity of Assis sur Serre and
thereafter in a sector in the St. Gobain forest (Deuillet-Fresnes).
5. On August 10 it was put at rest behind Laon.

Craonne.

6. It went back into line at the end of September in the Craonne sector. As a result of the French
offensive it fell back to the east of Hurtebise where it was relieved about November 10.
7. It rested in the Laon region from the middle of November to January 20.

RECRUITING.

In 1917 the division took on a distinctly provincial aspect, its regiments receiving replacements
from Prussian Saxony (the 36th Fusileers and the 66th Infantry) and in Thuringe (the 32d
Reserve Regiment).
 VALUE—1917 ESTIMATE.

The 113th Division was a good unit. It put up an energetic resistance on the Chemin des Dames
on May 5, 1917. From that time up to the offensive of March, 1918, it had not been seriously
engaged.

1918.

1. Having finished its training in the Sissonne region, the 113th Division relieved the 235th
Division about the middle of January in the Juvincourt sector (east of Craonne), and was itself
relieved by the 5th Reserve Division on the 21st of February. It trained for a week at Vervins, and
then moved to Wassigny, where it underwent more training until the 16th of March, when it
marched via Bohain and Fonsommes to Bellicourt.

St. Quentin.

2. On the 21st it attacked in the first line near Maissemy (northwest of St. Quentin). Although
suffering very heavy losses, the division had succeeded in pushing on as far as St. Christ-Briost
and Pargny (on the Somme) on the 24th. It was withdrawn shortly after (probably on the 26th).

Aisne.

3. On the 27th of May the division reenforced the Aisne front near Craonne and attacked in the
first line. It was withdrawn about the 14th of June and went to rest near Conde sur Aisne (east
of Soissons).
4. The division reenforced the front near Troissy (east of Dormans) on the 15th of July. It was
caught in the confusion caused by the Allied counteroffensive, and was forced to retire. It was
not identified after the 22d, and so it seems as though it was not in line after that date until
prisoners were again taken on the 29th near Villers-Agron (southeast of Fere en Tardenois),
which is in a line almost due north of where it had previously been engaged. Here it took over
the part of the line previously held by the 2d Guard Division. It was withdrawn early in August
and went to rest in the region southeast of Maubeuge.

Cambrai.

5. On the 10th of September the division reenforced the front near Metz en Couture (southwest
of Cambrai). It was withdrawn from line near Villers-Plouich (southwest of Cambrai) after having
lost over 1,600 prisoners about the 2d of October, and went to rest east of Denain.
6. On the 22d it came back into line near Douchy (south of Denain). Two days later it side-
slipped toward the south. It was identified in line to the north of Le Quesnoy in November, but
was withdrawn a day or two later. It did not return to line.

VALUE—1918 ESTIMATE.
The 113th was rated as a second-class division. Although the division commander received Pour
le Merite and the commander of the 36th Regiment was also decorated after the battle of the
Somme, the division does not appear to have particularly distinguished itself there. On the
whole, however, its conduct though not brilliant was dependable.
115th Division.
 COMPOSITION.
1915 1916 1917 1918
Brigade. Regiment. Brigade. Regiment. Brigade. Regiment. Brigade. Regiment.
Infantry. 229. 136. 229. 136. 229. 136. 229. 136.
171. 171. 171. 171.
40 Res. 40 Res. 40 Res. 173.
Cavalry. 1 and 2 Sqn. 22 1 and 2 Sqn. 22 2 Sqn. 22 Dragoon 2 Sqn. 22 Dragoon
Dragoon Rgt. (one- Dragoon Rgt. Rgt. Rgt.
half picked troops).
Artillery. 229 F. A. Rgt. (7 229 F. A. Rgt. (?) Art. Command: 115 Art. Command:
Btries.).
229 F. A. Rgt. 229 Field Art. Rgt.
94 Foot Art. Btn.
1074, 1077, and 1078
Light Mun. Col.
Engineers 229 Pion. Co. 229 Pion. Co. (115) Pion. Btn. 43 Pion. Btn.
and
Liaisons.
115 T. M. Co. 229 Pion. Co. 229 Pion. Co.
115 Pont. Engs. 2 Co. 33 Res. Pion. 2 Co. Res. Pion. Btn.
No. 33.
115 Tel. Detch. 115 T. M. Co. 115 T. M. Co.
229 Searchlight 74 Searchlight Section.
Section.
115 Tel. Detch. 115 Div. Signal
Command.
115 Tel. Detch.
89 Div. Wireless Detch.
Medical and 115 Ambulance Co. 115 Ambulance Co.
Veterinary.
350 Field Hospital. 376 and 377 Field
Hospitals.
376 Field Hospital. 167 Vet. Hospital.
377 Field Hospital.
Vet. Hospital.
Transport. M. T. Col. 598 M. T. Col.
 HISTORY.
(136th and 171st Regiments: 15th Corps District—Alsace. 40th Reserve Regiment: 14th Corps
District—Grand Duchy of Baden.)

1915.

Formed in April, 1915, near Tournai, the 115th Division received the 136th and 171st from the
30th and 39th Divisions (15th Corps), respectively, and the 40th Reserve Regiment from the 28th
Reserve Division (14th Reserve Corps).
1. In April, 1915, the 115th Division was in reserve in the Tournai-Courtrai region.

Artois.

2. In May it was sent as a reenforcement to the north of Arras and fought at Notre Dame de
Lorette and Neuville St. Vaast and was sorely tried. The infantry losses amounted to 128 officers
and 5,208 men out of action (Casualty List), of which 47 officers and 2,258 men belonged to the
171st Regiment.

Aisne.

3. Relieved about June 15, the 115th Division took over the Missy sur Aisne sector (east of
Soissons), which it occupied until the last days of July.

Russia.

4. At the end of July it was transferred to the Eastern Front, and for a time in August operated
on the Narew.
5. It took part in the summer offensive. It was before Kovno on August 19, in the region of Vileiki
at the end of September, and near Narotch Lake at the beginning of October.

1916.

Postavy-Narotch Lake.

1. The 115th Division occupied the Postavy-Narotch Lake sector until the beginning of August,
1916.

Galicia.
2. About August 2 the division was transferred to Galicia. It was engaged to the west of Zalosce
(south of Brody), August to September.

Volhynia.

3. In October it was in line in Volhynia to the west of Loutsk (Sviniouki). The 171st was kept to
the southwest of Brody with the Melior detachment.

Roumania.

4. In the middle of December the 115th Division was transferred from Volhynia to Roumania,
where, together with the 109th Division, it made up the 54th Corps, which operated between
Buzeu and the Danube.

1917.

Roumania.

1. In January, 1917, the 115th Division took a position on the Roumanian front to the south of
Namoloasa and stayed in this sector until the middle of August.
2. It was then in line to the north of Focsani, in the Panciu-Marasesti region (August-December).

RECRUITING.

The Grand Duchy of Baden and the Rhenish countries supplied the greater part of the recruits.

1918.

1. The division was relieved on the Roumanian front on February 1 by an Austrian division and
rested in the Braila area during February and March. On April 8 it entrained and traveled via
Budapest-Vienna-Prague-Dresden-Coblenz-Cologne-Aachen-Liege-Brussels to Lille, when it
detrained about April 18. About the 21st the division reentrained and was railed to Antwerp,
where it went through a course of intensive training.

Battle of the Marne.

The division left Antwerp on May 21 and traveled via Brussels-Mons-Maubeuge-Le Cateau-
Bohain, detraining north of St. Quentin on May 22. Four days later it continued its journey by rail
to Versigny, southeast of La Fere, and was billeted in the Crepy area until May 29. On the
following day it left and marched via Chaillevoois-Vailly (May 31)-Ambrief (June 1)-Villers-Helon
(2d) and relieved the 37th Division near Longpont on the Aisne battle front on the night of June
2–3. It withstood the Allied counterthrust at Corcy in July, suffering heavy losses. It was relieved
on the night of July 19–20.
Verdun.

2. The division was moved to Brieulles and in the first days of August relieved the 22d Reserve
Division in the sector Malancourt-Forges. In this vicinity it remained until September 19, when it
was relieved by the 7th Reserve Division.

Meuse-Argonne.

3. On the second day of the American attack the division returned to bolster up the line in the
Gesnes area. The division now included the 173d Regiment, which came from the 223d Division
(dissolved) to supplant the 40th Reserve Regiment (disbanded). The division took part in the
several captures and recaptures of Gesnes. It fought hard and suffered heavy losses before its
relief on October 12 by the 3d Guard Division. Two days later it came back to support the 3d
Guard Division and was engaged in the fighting around Romagne until October 18. On November
1 the division again came into line near Remonville and fought until the armistice.

VALUE—1918 ESTIMATE.

The division was rated as third class. It was badly hit on July 18 by the French attack and later in
the Argonne. It showed good qualities in the Meuse fighting and was mentioned in the official
German communiqué.
117th Division.
 COMPOSITION.
1915 1916 1917 1918
Brigade. Regiment. Brigade. Regiment. Brigade. Regiment. Brigade. Regiment.
Infantry. 233. 157. 233. 157. 233. 157. 233. 11.
11 Res. 11 Res. 11 Res. 157.
22 Res. 22 Res. 22 Res. 450.
Cavalry. (?) 1 and 2 Sqn. 8 1 Sqn. 8 Cuirassier Rgt. 1 Sqn. 8 Cuirassier Rgt.
Cuirassier Rgt.
Artillery. 233 F. A. Rgt. (7 233 F. A. Rgt. (?) Art. Command: 233 F. A. Rgt.
Btries.).
233 F. A. Rgt. 88 Foot Art. Btn.
1068, 1069, and 1070
Light Mun. Col.
Engineers 233 Pion. Co. 233 Pion. Co. (117) Pion. Btn.: 117 Pion. Btn.:
and
Liaisons.
117 T. M. Co. 233 Pion. Co. 233 Pion. Co.
117 Pont. Engs. 263 Pion. Co. 263 Pion. Co.
117 Tel. Detch. 117 T. M. Co. 117 T. M. Co.
233 Searchlight 147 Searchlight
Section. Section.
117 Tel. Detch. 117 Div. Signal
Command:
117 Tel. Detch.
187 Div. Wireless
Detch.
Medical and 117 Ambulance Co. 117 Ambulance Co.
Veterinary.
379 Field Hospital. 378 and 379 Field
Hospitals.
380 Field Hospital. 117 Vet. Hospital.
Vet. Hospital.
Transport. M. T. Col.
Attached. 6 Mountain Art. Btry.
 HISTORY.
(6th Corps District—Silesia.)

1915.

The 117th Division was created by the 7th Army near Liart about April 7, 1915. Its three
regiments were obtained from the 6th Corps and the 6th Reserve Corps—the 157th Infantry from
the 12th Division, the 11th Reserve Regiment from the 11th Reserve Division, and the 22d
Reserve Regiment from the 12th Reserve Division.
1. In April, 1915, the 117th Division was in Champagne (region of Châtelet).

Artois-Notre Dame de Lorette.

2. Transferred to Artois, it was engaged to the north of Souchez and at Notre Dame de Lorette
(May and June). In this fighting it was hard hit, 107 officers and 5,255 men out of action, of
whom 44 officers and 2,161 men belong to the 11th Infantry. (Casualty List.)
3. The division was re-formed at the end of June in the region of Lille.

Lens.

4. Toward the middle of July it went back into line to the northwest of Lens (from Vermelles to
the Grenay-Lens railway). It suffered very heavy losses in the attacks occurring at the end of
September and the beginning of October (Loos)—109 officers and 6,463 men out of action.
(Casualty List.)
5. Taken away from the Artois front in the middle of October, it was put at rest in the vicinity of
Roubaix-Tourcoing.

Flanders.

6. At the end of October it took over the Messines sector.

1916.

1. The 117th Division occupied the Messines front until the beginning of March, 1916.
2. Rest at Courtrai; instruction and training at the Beverloo Camp (March-April and May).

Ypres.
3. At the beginning of June the division went into line to the east of Ypres (near the road from
Ypres to Menin, and until July 20).

Somme.

4. On July 23 it went to the Somme (Pozieres); it was engaged from the end of July to the
middle of August.
5. On August 17 the division entrained for the Eastern Front.

Bukovina.

6. It was identified in the Carpathian Mountains as part of the 3d Austro-Hungarian Army (region
of Jablonica, October).

1917.

Carpathian Mountains.

1. The 117th Division remained here (Jablonica, Worochta, Koeroesmezoe, Jacobeni sectors) until
the middle of May, 1917.

Roumania.

2. At the end of May it was transferred via Maramaros-Sziget to the Roumanian front (Putna
valley, region of Ocna, June-September). At rest in Transylvania in September and was there
reequipped for mountain warfare.

Italy.

3. Sent to Italy at the beginning of October, it was on the 24th behind Tolmino as an army
reserve. In December it was on the left bank of the Piave.

RECRUITING.

Silesian division, with recruits coming especially from Upper Silesia (mining district and
mountainous districts), it was used on several occasions as mountain troops (Carpathians, Italy).
On the Carpathian, Roumanian, and Italian fronts (August, 1916-March, 1918).

1918.

Lorraine.
1. The division rested in the vicinity of Vahl-Ebersing until April 6, when it entrained at St. Avold
and moved to Lille. It went into billets near there on the 7th and came into line near Neuve
Eglise on April 13.

Battle of the Lys.

2. It was engaged in the Bailleul, Kemmel, and La Clyette area until the 1st of May. After a few
days in support, the division reentered west of Dranoutre on May 4 and held that sector until
mid-May.
3. The division rested near La Madeleine. Its units were very much weakened. The 11th Reserve
Regiment was disbanded about May 16 and transferred its effectives to the other two regiments
of the division. It was replaced by the 11th Grenadier Regiment, which was brought from the
Macedonian front about May 21. The division remained at rest until about June 3, when it was
again reported in line near Voormezeele.

Battle of the Somme.

4. The division held that sector without event until June 25, when it was withdrawn and sent to
rest near Ghent. On August 4 it was moved by rail to Peronne, where it went into the Vrely-
Hangest wood sector until August 18. In the British attack south of the Somme on August 8 the
division lost about 2,700 prisoners.
On August 27 it reenforced the battle front at Maricourt for a couple of days. It was withdrawn
about September 1.

Argonne.

5. The division rested and was reconstituted in rear of the Argonne front in early September. The
22d Reserve Regiment suffered so heavily on the Somme that it was dissolved and its men
divided between the other two regiments. The 450th Regiment from the dissolved 233d Division
replaced the 22d Reserve Regiment in the division.
6. About September 12, the division relieved the 37th Division in line near Avocourt. It was
swamped in the first drive of the American Army on September 26. Elements kept up the fight
until September 29, when they were withdrawn after having been pressed back to about Cierges.
Its defense was not particularly vigorous, but was better than that of the divisions on either side.
Its total losses were estimated at 3,200, including 1,861 prisoners.

Meuse.

7. On November 2 the division returned to line just west of the Meuse. While resting at Juvigny
the division received replacements. In the retreat it crossed to the east bank of the Meuse and
was in line on the day of the armistice.

VALUE—1918 ESTIMATE.
The division was rated as second-class. Up to the middle of June the division seems to have been
a holding rather than an attacking one. After the Somme battle in August its effectives were
feeble and morale low. It had many older men, returned wounded, and convalescents, and a
large number of Poles and Alsatians.
119th Division.
 COMPOSITION.
1915 1916 1917 1918
Brigade. Regiment. Brigade. Regiment. Brigade. Regiment. Brigade. Regiment.
Infantry. 237. 46. 237. 46. 237. 46. 237. 46.
58. 58. 58. 58.
46 Res. 46 Res. 46 Res. 46 Res.
Cavalry. Wedel. Rgt. (1 and 3 4 Sqn. 1 Mounted Jag. 4 Sqn. 1 Jag. z. Pf.
Sqn. 1 Uhlan Rgt. Rgt.
and 4 Sqn. 1
Mounted Jag. Rgt.).
Artillery. 237 F. A. Rgt. (7 237 F. A. Rgt. 119 Art. Command: 119 Artillery
Btries.). Command:
237 F. A. Rgt. (9 237 Field Art. Rgt.
Btries.).
2 Abt. 27 Foot Art.
Rgt. (Btries. 5 to 7).
1274, 1275, and
1338 Light Mun. Col.
Engineers 237 Pion. Co. 237 Pion. Co. 119 Pion. Btn.: 119 Pion. Btn.:
and
Liaisons.
119 T. M. Co. 237 Pion. Co. 273 Pion. Co.
119 Pont. Engs. 273 Pion. Co. 91 Searchlight Section.
119 Tel. Detch. 3 Res. Co. 32 Pion. 119 Div. Signal
Btn. Command.
119 T. M. Co. 119 Tel. Detch.
237 Searchlight 65 Div. Wireless Detch.
Section.
119 Tel. Detch.
Medical and 119 Ambulance Co. 119 Ambulance Co.
Veterinary.
605 Ambulance Co. 382 and 383 Field
Hospitals.
381 Field Hospital. 168 Vet. Hospital.
382 Field Hospital.
383 Field Hospital.
168 Vet. Hospital.
Transport. 600 M. T. Col. 600 M. T. Col.
Attached. 16, 17, 60, and 61 (?)
Light Machine Gun
Sections.
79 M. G. S. S. Detch.
1 Co. 3 T. M. Btn.
352 Pion. Mining Co.
Kortemarck Pion. Park.
Strovendorp Pion. Park.
57 Ft. Art. Btn.
157 Ft. Art. Btn.
5 Btry. 7 Res. Ft. A.
Rgt.
404 Ft. Art. Btn.
5 Btry. 39 Ldw. Ft. A.
Rgt.
6 Btry. 29 Ldw. Ft. A.
Rgt.
8 Quick-firing Mortar
Co.
182 Ft. A. Btry.
187 Ft. A. Btry.
428 Ft. A. Btry.
478 and 642 Mountain
Ft. Art. Btries.
2 and 4 Mountain Ft.
Art. Btries. (18 C.
Dist.)
1,000 Ft. Art. Btry.
9 Art. Survey Section.
819 Tel. Detch.
62 Div. Wireless Detch.
21 Pigeon Loft.
218 Messenger-dog
Detch.
48 Reconnaissance
Sqns.
26 Combat Sqn.
30 Balloon Sqn.
4 Co. 44 Labor Btn.
3 Co. 53 Labor Btn.
4 Co. 122 Labor Btn.
61 Supply Train.
19, 108, 121 Bav. and
835 M. T. Col.
491 Ammunition Train.
682, 711, and 758
Truck Trains.
587 Supply Train.
571 Depot Supply Col.
119 Supply Depot.
(According to a
captured document
dated Sept. 29, 1917.)
 HISTORY.
(5th Corps District—Posen and Lower Silesia.)

1915.

Galicia-Poland.

1. Formed in April, 1915. Its three regiments were obtained from divisions belonging to the 5th
Army—the 46th from the 10th Division, the 58th from the 9th Division, and the 46th Reserve
from the 10th Reserve Division. Assembled in annexed Lorraine, it was sent to Galicia for the
April German offensive. The division took part in the battle of Gorlice at the end of the month.
2. In July it was in Poland, west of the Wieprz, and at the end of October in the region of
Baranovitchi.

1916.

Baranovitchi.

1. In January, 1916, the division held a sector to the east of Baranovitchi (Russia).

Narotch Lake.

2. About March 28 it went to Narotch Lake and opposed the Russian offensive.
3. Sorely tried on March 30, it was relieved on April 7.

Smorgoni.

4. In May it was found at the west of Smorgoni.

Galicia.

5. It was transferred to Galicia at the end of June at the time of the Russian offensive. Engaged
on July 27, it suffered heavy losses. The 1st Battalion of the 58th was almost entirely captured
and the division retired 15 km. (letter). On August 7 new losses at Tlumacz. The division was
placed in reserve behind Stanislau until the beginning of September. On September 6 it
reappeared on the front in the region of Halicz.

1917.
Galicia.

1. The division stayed near Halicz until March 9, 1917. It was then sent to the vicinity of
Brzezany, where it was almost immediately put in reserve.
2. At the beginning of May it was sent to the Western Front. (Itinerary: Brzezany (May 3)-
Lemberg-Breslau-Liegnitz-Dresden-Leipzig-Cassel-Frankfort-Aix la Chapelle-Liége-Brussels-
Roulers (May 8).)

Flanders.

3. Ypres sector; went into line at the beginning of June and was relieved on July 18.
4. Bixschoote sector; went into line at the beginning of August. The division met the attack in
Flanders, in which it suffered serious losses on August 16. The 9th Company of the 58th Infantry
was reduced to 38 men (notebook). On the 9th and 10th of October there were new
engagements.
5. Relieved from the front on October 15 the division rested in the vicinity of Gand.

Cambrai.

6. After a month’s rest the 119th Division went into line on the Cambrai front to participate in the
counterattacks which followed the surprise attack of November 20. It fought here from the 23d
to the 27th, not without some losses.
7. Relieved after December 6, the division was reorganized in the vicinity of Solesmes.

RECRUITING.

This division recruited from the 5th Corps District. A document dated November 23, 1917,
described the division as composed of “regiments of Lower Silesia and Posen.” In order to
overcome the majority of Poles, the division received recruits from the 3d and 6th Corps Districts
(Brandenburg and Silesia), which were fruitful sources of recruiting.
Twenty-one per cent of the prisoners taken from the 119th Division in August, 1917, belonged to
the 1917 class. The 1918 class was meagerly represented. The 46th Reserve Regiment had a
large proportion of Poles. The soldiers from Alsace-Lorraine remained on the Eastern Front when
the division left Galicia (May, 1917).

1918.

1. About the end of January the division was relieved near Pronville by the 20th Division. It
replaced the 3d Guard Division astride the Bapaume-Cambrai road about February 12. The date
of its relief in this sector is not known. A captured diary shows that the division was training in
the Helesmes area (north of Denain) until the middle of March. On the 16th it marched to
Noyelles sur Selle, and on the following day reached Cambrai, where it remained until March 20.
Battle of Picardy.

2. The division came into line near Inchy on the 21st and took part in the initial attack. It was
withdrawn on the 23d and rested two days. It reappeared in line on the 25th and fought
southeast of Hebuterne until relieved by the 5th Bavarian Reserve Division on April 7–8. The
division lost heavily in this fighting.

Battle of the Lys.

3. Withdrawn from the Somme, the division reentered the Lys battle line on April 26 near Locon.
It was engaged there until early in May (6th), when it was withdrawn near Hinges and rested in
the area Lille-Tournai until June 11. On that date it marched to Orchies, was railed to Le Forest,
and from there came into line via Noyelles, relieving the 12th Reserve Division on the night of
June 13–14. While at rest the division received a number of drafts, mostly of the 1919 class.
4. The division held the Mericourt sector until the night of July 12–13, when it was relieved by
the 52d Division and took over the billets of the 52d Division in the Orchies area.
5. The division rested until August 1, when it moved to Ham via Douai-Cambrai-Caudry-Bohain-
St. Quentin. Then it rested until August 8, when it was alarmed and rushed up in busses to the
Le Quesnel sector.

Battle of the Somme.

6. On August 9 the division was engaged south of the Somme. In the fighting it lost about 900
prisoners before its relief on August 17. On August 27–28 it returned to line in the Misery-Licourt
sector and remained in line until September 24, when it was withdrawn from west of Bellenglise.
After a week’s rest the division reentered line at Estrees; was engaged for 17 days in the
Beaurevoir-Le Cateau area. Since August 8 it has lost nearly 3,000 prisoners.
Ypres.
7. The division rested at Ghent until October 27, when it relieved the 3d Landwehr Division south
of Machelen. It retreated via Olsene to Nazareth, in which area it was withdrawn about
November 9.

VALUE—1918 ESTIMATE.

The division was rated as second class. It was used as an attack division in the March and April
offensives. While on the defensive in August and September on the Somme it was decimated.
121st Division.
 COMPOSITION.
1915 1916 1917 1918
Brigade. Regiment. Brigade. Regiment. Brigade. Regiment. Brigade. Regiment.
Infantry. 241. 60. 241. 60. 241. 60. 241. 60.
7 Res. 7 Res. 7 Res. 7 Res.
56 Res. 56 Res. 56 Res. 56 Res.
Cavalry. 2 and 3 Sqns. 12 Horse 12 Horse Jag. Rgt. (? 2 3 Sqn. 12 Horse Jag. 2 Sqn. 12 Jag. z. Pf.
Jag. Rgt. Sqns.). Rgt. (?).
2 Sqn. 12 Horse Jag.
Schutz. Rgt.
Artillery. 241 F.A. Rgt. 241 F.A. Rgt. (?) Art. Command: 121 Art. Command:
241 F. A. Rgt. 241 F.A. Rgt.
85 Foot Art. Btn.
1217, 1219, and 1223
Light Mun. Col.
Engineers 241 Pion. Co. 241 Pion. Co. (121 Pion. Btn.): 121 Pion. Btn.
and
Liaisons.
260 Pion. Co. 241 Pion. Co. 241 Pion. Co.
4 Co. 27 Pions. 260 Pion. Co. 260 Pion. Co.
121 T. M. Co. 121 T. M. Co. 104 Searchlight
Section.
121 Pont. Engs. 241 Searchlight 121 Div. Signal
Section. Command.
121 Tel. Detch. 121 Tel. Detch. 121 Tel. Detch.
59 Div. Wireless Detch.
Medical and 229 Ambulance Co. 229 Ambulance Co.
Veterinary.
384 Field Hospital. 384 and 385 Field
Hospitals.
385 Field Hospital. 206 Vet. Hospital.
Vet. Hospital.
Transport. M. T. Col. 601 M. T. Col.
Attached. Labor Btn. of the 121
Div.
 HISTORY.
(60th Regiment: 21st Corps District—Lower Alsace. 7th Reserve Regiment; 5th Corps District—
Posen. 56 Reserve Regiment; 7th Corps District—Westphalia.)

1915.

The 121st Division was formed in the Falkenhausen Army in Lorraine in April, 1915. Its three
regiments came from divisions which had been in existence for some time. The 60th came from
the 31st Division (21st Corps), the 7th Reserve from the 9th Reserve Division (5th Reserve
Corps), and the 56th Reserve from the 13th Reserve Division (7th Reserve Corps). These
regiments were brought together in the region of St. Avold-Faulquemont at the beginning of April
and on the 9th reached Thiaucourt, Euvezin, and the Mort Mare wood (notebooks).

Haye.

1. The 121st Division next appeared in the Bois de Prêtre sector at the beginning of May, 1915.
2. It stayed there until the end of February, 1916.

1916.

1. The division left the Bois de Prêtre on March 1, 1916, and rested in the vicinity of Metz.

Verdun.

2. On March 15 it came to the Verdun front (north of Vaux). On April 1 it attacked and took the
village of Vaux; it again attacked on April 11 and made progress between Vaux and Douaumont,
paying dearly for the advance.
3. Relieved from the Verdun front on April 20, it was put at rest near St. Avold until May 15. It
had lost 58 per cent of its infantry strength in front of Verdun. From March 18 to May 30 the 6th
Company of the 7th Reserve Regiment received no less than 192 replacements.

Somme.

4. Transferred to Péronne by way of Sedan, Charleville, Hirson, and Bohain, the 121st Division
went into line on the left bank of the Somme on May 18.
5. On July 1, while in this sector, it was surprised by the French offensive and suffered heavy
losses (numerous prisoners).
6. Relieved on July 4, it was put at rest and reorganized.

Russia.
7. On July 18 it entrained for the Eastern Front. (Itinerary: Aix la Chapelle-Cologne-Thorn,
Warsaw, and Brest-Litowsk.)

Kovel.

8. Taking over the Kovel sector on July 26, it launched counterattacks, in which it was sorely
tried.

1917.

Narotch Lake.

1. At the beginning of January, 1917, the 121st Division left the Kovel sector to go into the region
of Narotch Lake and stayed in the latter place until May 17.

France.

2. On May 20 it entrained for France. (Itinerary: Vilna-Insterberg-Allenstein-Bromberg-Landsberg-

Berlin-Stendal-Minden-Duesseldorf-Aix la Chapelle-Verviere-Liége-Brussels-Audenarde.) It
detrained at Elsegem on May 25.

Cambrésis.

3. Transferred to Cambrai on June 10, it took over the Moruvres-Avrincourt sector, which it
occupied from June 12 to the beginning of August.

Flanders.

4. It was thereafter brought to the Ypres front to the south of the railway running from Ypres to
Roulers (Aug. 19). Artillery fire caused it to lose heavily; the British attack of September 20, of
which it bore the brunt, increased its losses. Before the battle of the 20th the 12th Company of
the 56th Reserve Regiment was reduced to 65 men, of whom 40 were men of the class of 1918.
The 9th Company was entirely destroyed or captured.
5. Relieved in the night of the 21st of September the division was sent to rest (region of Mars la
Tour) and reorganized (more than 2,000 men coming from the 605th and 614th Landstrum,
Batallion X 12, and the 109th Landwehr). These replacements were very heterogeneous—
soldiers from Westphalia, Hanover, Baden, Magdeberg (men previously wounded and
convalescents).

Cotes de Meuse.

6. At the beginning of October the 121st Division took over a sector near Cotes de Meuse (les
Éparges, Ravin de Malochis). It stayed there until about April 10, 1918.
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

textbookfull.com