Where can buy Blockchains: a handbook on fundamentals, platforms and applications 2024th edition sus

Page 1


Visit to download the full and correct content document: https://textbookfull.com/product/blockchains-a-handbook-on-fundamentals-platformsand-applications-2024th-edition-sushmita-ruj/

More products digital (pdf, epub, mobi) instant download maybe you interests ...

Biota Grow 2C gather 2C cook Loucas

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

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-platformsapplications-and-tools-for-three-dimensional-systems-forcommunity-creation-and-commerce-1st-edition-yesha-sivan-eds/

McEvoy's Handbook of Photovoltaics, Third Edition: Fundamentals and Applications Soteris Kalogirou

https://textbookfull.com/product/mcevoys-handbook-ofphotovoltaics-third-edition-fundamentals-and-applicationssoteris-kalogirou/

Security Strategies in Windows Platforms and Applications Fourth Edition Shimonski

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

Security Strategies In Linux Platforms And Applications

Michael Jang

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

Whole-Body Cryostimulation: Clinical Applications

2024th Edition Paolo Capodaglio

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

Beginning PostgreSQL on the Cloud: Simplifying Database as a Service on Cloud Platforms Baji Shaik

https://textbookfull.com/product/beginning-postgresql-on-thecloud-simplifying-database-as-a-service-on-cloud-platforms-bajishaik/

Fundamentals of Surface Thermodynamics: Phase Behavior and Its Related Properties 2024th Edition Ronaldo Gonçalves Dos Santos

https://textbookfull.com/product/fundamentals-of-surfacethermodynamics-phase-behavior-and-its-related-properties-2024thedition-ronaldo-goncalves-dos-santos/

Handbook of Self Cleaning Surfaces and Materials From Fundamentals to Applications 1st Edition Akira Fujishima (Edt)

https://textbookfull.com/product/handbook-of-self-cleaningsurfaces-and-materials-from-fundamentals-to-applications-1stedition-akira-fujishima-edt/

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.

Editors

Blockchains

A Handbook on Fundamentals, Platforms and Applications

Editors

School of Computer Science and Engineering

University of New South Wales

Sydney Kensington, NSW, Australia

Mauro Conti

Department of Mathematics

University of Padova Padova, Italy

School of Computer Science and Engineering

University of New South Wales

Sydney Kensington, NSW, Australia

ISSN 1568-2633

Advances in Information Security

ISBN 978-3-031-32145-0

ISSN 2512-2193 (electronic)

ISBN 978-3-031-32146-7 (eBook) https://doi.org/10.1007/978- 3- 031- 32146- 7

©TheEditor(s)(ifapplicable) andTheAuthor(s),underexclusivelicensetoSpringerNatureSwitzerland 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.

Theuseofgeneraldescriptivenames,registerednames,trademarks,servicemarks,etc.inthispublication 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.

Part I Building Blocks

Ten Myths About Blockchain Consensus ...................................... 3

David Hyland, João Sousa, Gauthier Voron, Alysson Bessani, and Vincent Gramoli

Cryptographic Primitives .......................................................

Mayank Raikwar and Shuang Wu

Part II Popular Blockchains

Bitcoin Blockchain System: An Overview of Security and Privacy Aspects ............................................................................

Mauro Conti, Ankit Gangwal, Chhagan Lal, and Sushmita Ruj

The Ethereum Blockchain: Implementation and Security Aspects ........

Alessandro Brighente, Mauro Conti, and Andrea De Salve

25

75

109

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

Mario Larangeira and Dimitris Karakostas

225

Layer 2 Scaling Solutions for Blockchains

Subhra Mazumdar and Sushmita Ruj

Illicit Blockchain Content: Its Different Shapes, Consequences, and Remedies

Roman Matzutt, Martin Henze, Dirk Müllmann, and Klaus Wehrle

Blockchain-Based Distributed and Secure Digital Forensic Investigation Systems

261

301

337 Mauro Conti, Gulshan Kumar, Chhagan Lal, and Rahul Saha

Part IV Applications

Supply Chain Management Using Blockchain

Christopher Klinkmueller, H. M. N. Dilum Bandara, Xiwei Xu, and Qinghua Lu

Blockchain Technology for E-Governance Applications

Ras Dwivedi, Nilesh Vasita, Mukul Verma, Tanmay Yadav, and Sandeep Shukla

When Blockchain meets Smart Cities: Opportunities, Security and Future Research

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

Hye-young Paik, Yue Liu, Qinghua Lu, and Salil S. Kanhere

From Centralized to Decentralized Remote Electronic Voting

Christian Killer, Bruno Rodrigues, Eder John Scheid, Muriel Figueredo Franco, and Burkhard Stiller

Blockchain Technology Accelerating Industry 4.0

Jan Pennekamp, Lennart Bader, Eric Wagner, Jens Hiller, Roman Matzutt, and Klaus Wehrle

Blockchain for Health Data Management

Dinh C. Nguyen, Pubudu N. Pathirana, Ming Ding, and Aruna Seneviratne

365

399

423

465

493

531

565

Supporting Secure Trusted Manufacturing via Blockchain 587

Ali Dorri, Sabah Suhail, Zahra Jadidi, Rasheed Hussain, Colin Fidge, and Raja Jurdak

Blockchain for Data Sharing

Gowri Sankar Ramachandran and Bhaskar Krishnamachari

601

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

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-inChief 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

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: dhyl2836@uni.sydney.edu.au; gauthier.voron@sydney.edu.au

J. Sousa · A. Bessani

Faculdade de Ciências, Universidade de Lisboa, Lisboa, Portugal

e-mail: jcsousa@fc.ul.pt; anbessani@fc.ul.pt

V. Gramoli (O)

University of Sydney, Camperdown, NSW, Australia

EPFL, Lausanne, Switzerland

e-mail: vincent.gramoli@sydney.edu.au

© The Author(s), under exclusive license to Springer Nature Switzerland AG 2024 S. Ruj et al. (eds.), Blockchains, Advances in Information Security 105, https://doi.org/10.1007/978- 3- 031- 32146- 7_1

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.

Table 1 A summary of common blockchain consensus myths

# Myth

Clarification At risks

1. Po* solves consensus Po* selects blocks without guaranteeing uniqueness Users

2. Consensus bottlenecks blockchain in LANs BFT-SMaRt runs faster outside Hyperledger Designers

3. Consensus bottlenecks distributed ledgers in WANs

4. CFT consensus tolerates Byzantine faults

5. Signatures and hashes make blockchain secure

6. A CFT blockchain with a BFT consensus becomes BFT

7. BFT consensus needs linear message complexity

8. Reconfiguring consensus participants is easy

9. Blockchain performance is not limited by cryptography

10. Blockchain needs to solve the classic consensus problem

DBFT and BFT-SMaRt scale better outside Corda Designers

BFT quorums are larger than CFT ones Users

They do not cope with disagreement and double spending Users

The whole communication pattern needs to be changed Users + Designers

Some quadratic complexity algorithms perform better Designers

It is difficult to make it non-disuptive Designers

CPU demand can surpass the network demand of consensus Designers

Deciding o(n) proposals help scale Designers

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

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, proofof-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 proofof-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-ofstake 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 protocols 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

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

In fact, the proof-of-∗ mechanism cannot solve consensus but is instead a mechanism 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 {b 1,b 3} 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.

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

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 32GB of memory and two quad-core 2.27GHz Intel Xeon E5520 processors with hyper-threading. These machines communicate through an isolated gigabit Ethernet LAN. The results were obtained with Hyperledger 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 4KiB 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 4KiB 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 BFTSMaRt 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

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 8KiB 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

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 “DBFTWorld” 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 BFTSMaRt 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.

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

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.

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 opensource 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/

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 component 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- forhyperledger- fabric/

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.

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

10.1 Examples: Hyperledger Fabric and Tendermint

Hyperledger Fabric aims at supporting membership changes without compromising 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 systems 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 See Section 7.1, second paragraph, of https://atrium.lib.uoguelph.ca/xmlui/bitstream/handle/ 10214/9769/Buchman_Ethan_201606_MAsc.pdf?sequence=7&isAllowed=y

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

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.

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 contradicting 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 ´ c[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 validators 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 D IABLO benchmark allows to measure blockchain performance under realistic workloads [9].

Another random document with no related content on Scribd:

Hát ennyi emberben annyi életrevalóság sem volna, hogy mindegyik vágyakoznék legalább a legutolsó lenni, s ha a mohácsi vész után ennyi millió árva van, pityergés helyett vigyen mindenik egy darab követ egy rakásra, s meglátják, hogy annyi anyagból egy új nemzetet lehet megint építeni.

Annyi bánatot és örömet mondtak el e nyelven és ha mi ezt elvesztenők, lenne mit hallani a másvilágon, ha minden elhunyt magyar pirongatásképen csak egy szót szólna is.

Mit siránkozunk annyi századon keresztül? ha összedült az egyik fészek: míg ott ordítozunk, addig ugyanazt a hangyák réges-régen újra építenék.

Egykor az ősök oly kevesen voltak, hogy a legyőzött szomszédok azért nem akarták megszámlálni őket, mert e marok néptől legyőzetni százszoros gyalázat! Százszorosan kellett hát győznie, hogy a világ nemzetnek ösmerje e csodanyelvű népet – és most annyian vagyunk, hogy ha nem teszünk is egyebet, csak a nyelvet beszéljük, – meg vagyunk mentve!

Miért esnénk kétségbe a multért? hisz oly dicső volt apáinknak multja, hogy ha tudnánk, hogy úgy járunk, mint egyszer Lothnak felesége, hogy a mint hátranézett sóbálványnyá meredt, még akkor is vissza kellene néznünk.

S most akarunk temetkezni, mikor annyiak vagyunk már, hogy a szomszéd irgalomból sem vesződik ennyi haldoklóval s végre is fogna rajtunk az a régi átok, hogy egyik magyar a másiknak ásná meg vermét.

Volt egykor olyan pusztulás az ország hosszán, hogy tán számra több volt már a farkas, mint az élő magyar és ez is félve nyitá meg az ajtót, nehogy a bátor ellenség helyett egy kiéhezett vadat leljen a küszöbön.

Ilyen idők voltak, s meghalni még sem tudtunk, most pedig a mennyien vagyunk, ha egy intésre mindannyian megszólamlanánk –életjelnek elegendő volna.

Ha már nemzetnek vallottuk magunkat, birjunk el valamit, hogy saját erőnket megpróbáljuk; és ha megosztjuk az idők terhét, ne feledjük, hogy annyi millió még temérdeket elbir.

Ezt írta ez a néhány ember, s egy pár jólelkű hazafi elhúzódott félre a Balaton sarkához, megelégedtek, hogy egy kis szűk hely befogadta őket, s ha nem adhatott egyebet a lelkesült csoportnak, legalább – becsülést azt adott.

A dunántúli kerületnek közelebb eső részeiből jöttek az egyszerű fogatok, a kocsik oldalain nem volt odapingálva sem a törökfej, sem a zöld mező – hisz most már nem járunk el a törököket verni, s a zöld mező ma már csak annyit jelent, hogy a juhok legelnek ott; inas sem volt a bakon, kinek kabátjára elől-hátul föl lehet varrni a híres czímert – hogy a ki előlről észre nem vette, legalább hátul megláthassa a család dicsőségét; hisz ezek egyszerű írók – minden czímerük egy árva lúdtoll, melynek a pecsenyéjét bizonyosan más ette meg, legalább a kit megdicsőit e toll, az irigység sem foghatja rá, hogy a libapecsenyéért tette.

A keszthelyi szőlőkben, nem messze az országúttól, volt egy pincze, s annak irányában két úr száll le egy csinos fogatról, s egyenesen a pinczének tartanak, melynek belsejében az öt-hat ember üli körül a tüzet, szalonnát pirítván az izzó tűznél, a gazda pedig sorba kinál egy úgynevezett vándorkorsót, mit már harmadszor töltött.

Vigan pattogott a szikra, s midőn a keszthelyi vendégek egyenkint érkezének, a jelül elsütött mozsárnak hangja a szőlőkben is visszhangozék, s a borozók egyike mondja:

– De nagyot szól az az ágyú!

– Ez csak mozsár – mondja Holvagy Pista – sorra eresztvén egy újabb korsót, mit most hozott ki a pinczéből – aztán párbeszédbe keveredve folytatja – hát ha még az igazi ágyút hallanád, öcsém!

– Ugyan, Pista bácsi – mondja a fiatalabb legény – kelmed már látott közelről ágyút?

– Meg is lőttek vele a francziák.

– Pedig azt mondták, hogy a franczia nem akarja bántani a szegény embert, csak az urat meg a papot.

– Már hisz nem tudom akkor, hogy grófnak néztek-e engem vagy püspöknek? de majd láb nélkül jöttem haza.

Vigan pattogott a szikra.

– Pedig azt mondták ám minálunk, hogy a franczia azért jött be, hogy minden ember egyenlő legyen!

– Persze, hogy azért – hagyá helyben Pista – valamennyinkről lehúzták volna a magyar nadrágot, aztán adtak volna ránk egy nagyszájú bugyogót, hogy valamennyien egyenlők legyünk.

– Ejnye, hogy a bűne verje meg – mondja amaz – hiszen akkor az a franczia csakugyan ellenség!

– Bolond ember vagy – tréfálódzék Pista – hisz mit ér a te ruhád? más volna, ha a gróf jajgatna majd az aranyos mentéért.

– Aztán arról is lehúznák?

– Hát hogyan lennénk egyenlők, ha arról le nem húznák?

– De hát a ki nem hagyná?

– Dehogy nem hagyná – okoskodik amaz – te a grófét hagynád, a gróf meg a tiedet.

– Hátha összefognánk, Pista bácsi? mi lenne akkor?

– Akkor kivernők a francziát, öcsém – mondja Pista – hanem megint úgy maradnánk, mint voltunk – egyik lenne paraszt, a másik pedig aranyos mentéjű gróf.

– De nem kellene bugyogóba bújni?

– A hasznáért megtehetnéd, öcsém – okoskodik amaz – aztán milyent nézne anyád, ha fecskefarkú ruhában mennél el a ház előtt, aztán eltagadnád, hogy magyarul is tudtál?

– Tudom megátkozna, szegény édesanyám.

– Ki hallaná meg azt az átkot?

– Meghallaná azt valaki, István bácsi, él még a magyarok istene!

A fiú nem tudott aztán fölvidulni, mert észrevette, hogy a gazda nem ok nélkül gúnyolódott, tehát szivesen hallgatott, hogy több szó ne érje, s midőn az ajtón Dunay és Festetics grófokat látta belépni, azon gondolatban, hogy azok ott künn mindent meghallottak, rettentően megszégyenlé magát.

Levett kalappal állt valamennyi a váratlan vendégek előtt s Dunay megismervén a házi gazdát, barátsággal kéri, hogy néhány szép fiatal berkenyefát láttak meg az országútról, jó pénzért szivesen megveszik.

– Akár valamennyit! méltóságos uram.

– Csak néhány szálat! – felel rá Festetics, ismét kimenvén a szabadba, s a fák felé tartott, hogy a szükséges szálakat kiválogathassa.

Pista hátraintett, hogy az ásókkal jőjjenek utána, hogy a mely ágat kiválasztanak, majd rögtön kivehessék, maga azonban ment a szőlőtőkék között egyenesen a berkenyefáig. Festetics nagyon előre sietett, tehát Pista megszólítja Dunay grófot, kivel régóta bizalmasabb viszonyban állott már

– Ő méltósága nagyon megkivánta talán a berkenyét?

– Ez egészen más okból lesz használva – felel a gróf, mindig lassabban menve, s éppen e miatt a hátulsók is elérték őket és a beszédet egy szóig érthették, midőn a gróf folytatta – holnap ez ágakat mi a nagy kertben fogjuk elültetni, minden ágnak adunk majd egy nevet.

– Valami nagy uraságnak a neve lesz az? – kérdi Pista.

– Nem édes barátom, hanem vannak és voltak hajdanában lelkes hazafiak, kik olyan magasan állnak, hogy bizonyosan magasabbak nálunknál egy fejjel az ő érdemeik után – tehát minden esztendőben másért dugunk le egy ág berkenyét, hogy az élőfa legyen bizonysága, hogy az ő neve nem halt ki közülünk!

– Vedd le a süvegedet! – löki meg egyik paraszt a másikat, nem tudván hirtelenében más tiszteletet adni a beszédnek, s a gróf hamar észrevette, hogy az egyszerű emberek szavainak adnak ily becsületet.

– Mivel tartozunk az ágakért? – mondja Festetics, három szálat kiválasztván kiásás végett, de Pista közelebb lépvén a grófhoz,

tisztelettel mondja:

– Nem pénzért adom, méltóságos uram!

– De ingyen nem fogadhatunk el senkitől is olyant, minek értéke van.

– No hát ne mondjuk meg, hogy mennyit ér ez a három szál fa, méltóságos uram – mondja Pista – legalább mikor leássák, ha nem tudok hozzáadni a tisztelethez, méltóságos uram, legalább nem mondhatja senki, hogy elvettem belőle!

Festetics elgondolta, hogy gróf Dunaytól megtudták, mi okból kéri ő a berkenyefát, tehát nem unszolta tovább az árt, hanem hogy cserében ő is adjon még valamit, azt mondja:

– Jó – elfogadom a szép ajándékot, hanem a mely fa megtetszik az én kertemben, szivesen odaadom.

– Ne igérjen semmit, méltóságos uram – én egyebet kérek.

– Hadd hallom, mit tehetek én is?

– Engedjék meg méltóságos urak, hogy én áshassam le az ágakat a földbe.

– Ezer örömmel! – válaszol Festetics – és ha még akar valakit magával hozni, azt is megengedem.

Pista hátranézett, látta, hogy az előbbeni beszélgető még mindig halavány, rámutatott Pista a fiúra, s aztán a grófhoz fordulva mondja:

– Ezt viszem el, méltóságos uram engedelmével. A gróf nem firtatta a dolgot, hanem megmondván a napot és az órát, mikor okvetetlenül ott kell lenni, nyájassággal vőn búcsút a körülállóktól, s aztán Keszthelyre hajtatott, hol a vendégek nagy csoportja várta.

Pista elkiséré a vendégeket egész a kocsiig, aztán pedig visszament a berkenyeágakhoz, melyeket már szorgalmasan ástak ki a földből, kivált a beszédes fiú, ki legbuzgóbb volt valamennyi között.

– Na fiú – mondja Pista, – cserélnél-e most egy hatökrös gazdával?

– Még a gróffal sem, hallja, Pista bácsi! – mondja szörnyen örvendezve.

– No lásd, édes öcsém, hogyan leszünk legkönnyebben egyenlőkké – nézd ez a két gróf milyen derék magyar ember – aztán magadat is annak tartod!

Vigan folyt a munka, a fának gyökerét jól körülásták és a kirendelt időre a kastélyban voltak, ünnepi ruhában és Pista nem is merte volna hinni, hogy a mai napon kivel találkozik.

Mielőtt azonban idáig érnénk, nézzünk körül, kit látunk az érkezett vendégek közt, nem értvén a szájtátókat, vagy a világlátókat, hanem azt a kis csoportot, mely az akkori irodalom embereiből került ki és a vendéglátó «Keszthelyi gróf» körül összesereglének.

Ruszek apát vezeté karonfogva Kis Jánost, a későbbi szuperintendenst, szemközt pedig Dukai Takács Judit jött, s a két férfi nyájasan üdvözli a hölgyet.

– Épen Kist keresem – modja Takács Judit – valami közlendőm lenne.

– Titok? – kérdi Ruszek, hogy alkalmatlan ne legyen.

– Éppen nem, sőt kérem az apát urat, kisérjen bennünket egyik terembe!

Mindhárman elváltak a nagyobb társaságtól, hogy a bizalmas közlést meghallhassák, s a mint a harmadik ajtót megnyitják, egy ősz földmívelő áll a három vendég előtt.

– Édes apám! – mondja Kis, meglepetve lépvén apjához, ki örömkönyűk közt karolá át fiát, ki, midőn apja karjaiból kibontakozék, a két kisérőnek mondja:

– Ez az öreg férfiú az én édes apám.

– Gondolta-e édes öregem – mondja a hölgy – hogy ma fiát fogja itt meglátni?

– Álmomban sem hittem volna, nagyasszonyom (így ám), hanem mivel berendelt az én méltóságos uraságom, kinek én is egyik jobbágya vagyok…

– Mától fogva nem – mondja a hölgy – fogadja ez írást, kedves öreg… földjét öröktulajdonban birja, s most maga az első jobbágy, kinek földesura nincsen!

Az öreg remegő kézzel nyúlt az írás után, mit a nemeslelkű gróf ily gyöngéd kezek által nyújtott neki, s a négy ember sokáig szótlanúl állt, e nem várt tettet megbámulván, míg utóbb az ajtó lassan megnyilt és a gróf is közöttük állt.

Kis még most sem tudott a meglepetéstől magán uralkodni, s ámbár erőlködött, hogy valami hálát mondjon, utóbb a nagy küzdelemben végtére is ennyit mondott:

– Méltóságos uram, maga az oka, hogy én most azt mondom, hogy semmit sem tudok mondani! – Bármennyire szivesen időzném e képnél, mégis inkább kedves olvasóimra hagyom elképzelni ezt az öt embert, kik a nagy boldogságban oly ügyetlenül álltak, hogy azt le nem merem írni, csak annyit mondok, hogy mégis mind az ötnek vajmi nagyon jól állt ez a kis ügyetlenség, s akár mit mondtak volna, vagy igen nagy dicsekedés, vagy igen alázatos köszöngetés volna. Hagyjuk tehát őket, majd valahogy csak szétválnak, mi meg menjünk odább.

Egy igénytelen külsejű, rövid homlokú, meglehetős komor képű úr válik ki a többi közől, s mindenütt elmaradozik, mintha ki akarna szökni, azonban csak azt veszi észre, hogy valamennyi szemközt fordul neki, s a merre ő előbb visszahúzódott, most minden ember arra tart, s némelyik alig várja, hogy az a kis barna ember mondjon már valamit, mert hiába, akármennyire húzódozik a sok ösmeretlen között, mégis sokan ösmerik, mit ő maga legkevésbé látszik tudni, mert annyira hátrál, hogy már az ajtóhoz ér, hol éppen Kisfaludy

Sándor lép be, hanem a hátráló ember egész csizmasarokkal rálép a lábára.

Egy nagy kiáltás hallik, csakhogy nem az kiáltott, kinek tyúkszemére léptek, hanem a hátráló kiált engedelemért, azt gondolván, hogy hátha valami nagyságos úrnak lábát tiporta le.

– Ne búsuljon Berzsenyi uram, én vagyok! – mondja Kisfaludy meg sem hunyorodván, s ekkép megnyugodott, s minthogy Kisfaludy őt kereste, elment vele a szomszéd szobába, de a mit valaha becsülettudásképen belévertek, az ma mind fölengedett benne, mert akármennyire tuszkolta is Kisfaludy, hogy ő menjen elől, sehogysem bírt vele.

A szobába érkezvén, egy papirt mutatott Berzsenyinek, s leolvasák róla azon adományokat, melyek a heliconi ünnepély napján elosztandók voltak.

1-ször. Kétezer forintot szántam a megcsonkult magyar vitézeknek, hogyan keressenek szegények, hisz ha utána kellene menni, nem vinné a lábuk, mert nincsen, s ha találnak valahol egy fillért, egy kézzel könnyen fölvehetik.

2-or. Házi szegényeimnek szintén kétezer forintot adok, én eltartom a magam szegényeit, meghagyom a többit másnak, hogy legyen nekik kivel jót cselekedni.

3-or. A keszthelyi diákoknak adok ötszáz forintot, – azok legalább nem rakják a láda fenekére, aztán a mit nekik adok, az leghamarább szétmegy a világon, annyi, mintha azoknak is adnám.

4-er. A hazai íróknak kétezer forintot bátorkodom ajánlani; – ők legalább tudják, hogy ez nem ajándék; valamint azt is tudják, hogy mennyivel tartozik egy ember édes hazájának.

Berzsenyit úgy meglepte a dolog, hogy egy pillanatra azt is megbánta, hogy a «Romlásnak indult» kezdetű verset írta s minthogy most már a nyomtatásból ki nem lehetett vakarni, legalább azt gondolta, hogy ez az ember mindenesetre kivétel, csak a többi a nem jó.

Midőn eléggé elteltek a nagy hazafinak sokoldalú figyelmével, saját körülményeiről kezdett beszélni a két jeles ember és Kisfaludy nagy örömét nyilvánítá, hogy Berzsenyit is valahára el lehetett csalni Keszthelyre, hol ő ugyan máskor is megfordult, de sehogysem tudták a grófhoz fölczipelni.

A gróf ezt jól tudta, mert a vendéglősök szerződés szerént tartoztak minden úri vendéget a kastélyba küldeni, mit annál inkább szivesen megtettek, mert a vendégért azért ők is megkapták a tartáspénzt, ha nem evett is a korcsmában; de Berzsenyi annyira tartózkodó volt, hogy inkább nem evett, de még sem ment el a kastélyba.

A vendéglős mindig fölrovogatta Berzsenyiért a tartáspénzt, s utóbb a gróf végignézvén a vendéglős számadását, csodálkozva látja, hogy Berzsenyinek neve háromszor is előfordul, de ő nála egyetlenegyszer sem volt, tehát mi dolog ez?

Elhivatták a korcsmárost.

– Hallja az úr, – mondja a gróf – nem panaszolkodott Berzsenyi úr a kastélybeli szakácsra?

– Egy szót sem hallottam tőle, méltóságos uram – mondja a korcsmáros egész becsülettel.

– De mindig evett valamit, mikor ismét visszament?

– Egy falatot sem, méltóságos uram, – állítja a korcsmáros –hiába is kért volna; mert nem adtam volna neki, mint az megparancsolva van.

– Pedig lássa az úr, – mondja a gróf – én nálam egyszer sem volt Berzsenyi úr sem ebéden, sem vacsorán, akár voltam itthon, akár nem.

– Akkor éhesen is ment haza, vagy abból evett, méltóságos uram, a mit magával hozott.

A gróf nem vallatta tovább a korcsmárost, hanem nagyon érzékenyen vette, hogy a köztiszteletű férfi ennyire kerüli, tehát nincs

más mód, mint hogy ő menjen Niklára, s kiadta a parancsot, hogy minden késedelem nélkül álljon elő a fogat. Még jól fönn volt a nap, mikor a gróf Niklára ért, illetőleg a határba s a tehénpásztor éppen az út mellett legeltetvén, megkérdi a tehenestől, hogy Berzsenyi úr körülbelül melyik házban lakik.

– Éppen ott megy az úton – mondja a tehenes – alig van ide kétszáz lépésnyire, ő maga legkönnyebben elvezet házáig.

Megköszönte a gróf az emberséget, azután pedig leszállván a kocsiról s az országút szélén haladva, a faluvégén már jól megközelíté Berzsenyit, s mindenütt vagy három ölnyire követé; midőn Berzsenyi a kapuig ért, megállt a kapu előtt, hanem úgy, hogy még mindig nem látta a grófot, ki most éppen egy magyar mentés úrral beszélt.

– Ugy-e, ebben a házban lakik Berzsenyi Dániel úr?

– Igen is! – válaszol a megszólított, egyenesen a grófra nézvén, ki elég hangosan beszélt, hogy Berzsenyi is meghallhassa.

– Én, kérem alázatosan, gróf Festetics György vagyok – mondja a gróf sietve, hogy a másiknak ne maradjon ideje hálálkodni –nagyon szépen kérem uraságodat, mondja meg tekintetes Berzsenyi Dániel úrnak, hogy ugyan jól tudom, hol lakik; hanem ha ő elkerülte az én házamat, én sem merek ő hozzá bemenni!

Berzsenyi az utolsó szóig hallott mindent, visszafordult, s odasietett a grófhoz, hogy valami mentséget mondjon, azaz, hogy ne az igazi okot mondja meg, mi nem egyéb volt, mint hogy nem igen vágyakozott nagy urakkal egy tálból cseresznyét enni. A becsületes ember odament; hanem már az arczáról meglátta Festetics azt a gyötrelmet, hogy akar ugyan hazudni kénytelenségből; de bármennyire erőlködik is, nem tud.

– Ne is törje az eszét, Berzsenyi úr, csak mondja ki, hogy nem akart bejönni hozzám.

– Nagyon nagy nekem az a kastély, méltóságos uram!

– Én inkább azt hinném, hogy Berzsenyinek igen kicsiny, –igazítá ki a gróf.

– Nézze a gróf, – mutatja Berzsenyi a niklai kis tanyát – mily kicsiny helyen elférek.

– Azért is bemegyek, – mondja nevetve – higye meg, Berzsenyi, tudom, hogy kicsiny helyt megférek; tehát menjünk! – kezdi a gróf.

– Mivel érdemlem meg ezt a megtiszteltetést, méltóságos uram?

– Kettővel, édes Berzsenyi. Először, ha nem hí engem méltóságos úrnak, mert akkor én még egygyel fölebb kezdem, másodszor pedig, ha Keszthelyre is eljő!

– Nem kerülöm el többé!… (Itt egy nagyot nyögött Berzsenyi; mert már nem merte megméltóságosozni; hanem valahányszor hasonló helyre került, a czímezés helyett egy darabb időig rendesen kitartá a nagy pauzát, s aztán ment még odább.)

Így tudták Berzsenyit elhozni Keszthelyre, hol az ünnepélyen kitünő vendég vala, s mi azon ünnepélyek leírását negyven esztendőnek elmúlta után részben neki köszönhetjük.

Az akkori dunántúli írók nagy részben jelen voltak, valamint az irodalombarátok is, kik közől első helyen gróf Dunayt említhetjük, ki ez ünnepélyre serdülő lányát is elhozta, kinek ez ünnepélyen az a foglalatosság jutott, hogy a költőknek és szavalóknak koszorúkat nyujtson.

Mindenki készült az ünnepélyre, az öreg Baltay legaranyosabb mentéjét öltötte magára, s a mi legföltünőbb, daczára annak, hogy Dunayék is itt valának, nem maradt el a nagy ünnepélyről.

András felöltöztette a nagyságos urat, mi természetesen szó nélkül nem esett meg, tehát halljuk ezt a két öreget, összeférnek-e már?

Egészen felöltözött az öreg, csak az aprólék hiányzott, hogy azt is elrakja valahol a mentezsebekben.

Hol a dohányzacskóm? hadd teszem el.

– Éppen bizony, – dörmög András – még utóbb is az én szégyenemre azt mondanák, hogy én milyen vén szamár vagyok, s az uraságomat úgy kibéllelem, mintha a kaszások után akarnám ereszteni.

Baltay csakugyan észvette, hogy Andrásnak igaza van; reggel óta igen szórakozott, kiállt az ajtóba, Dunaynak leányát látta előtte elmenni, s a kemény ember nem birt elfordulni tőle, s midőn a gyönyörű hölgy elmenvén előtte, s egy szép jóreggelt kivánt, úgy elbámészkodott, hogy majd a leány nyakába dült. Aztán pedig kihúzott oldalzsebéből egy rég megviselt levelet, eltette, elolvasta, megint elolvasta, megint eltette, s tán tovább is ismételné ezt a munkát, ha András meg nem csudálja a dolgot és azt nem mondja szokatlan tréfával:

– Már látom, hogy a nagyságos úr is mond egy verset, nagyon sokáig tanulja!

– Tudom, szeretné kend hallani ezt a verset!

– Ha én tarthatnám azt a papirost, aztán látnám, hogy szórólszóra el tudja mondani.

– Ha azt megérem még, András, a mi ebben van megírva.

– Csak ne búsuljon megint a nagyságos úr, mert aztán én is együtt jajgatok ám!

Baltay eltette az írást, melynek egyik részét mi is jól ismerjük, ez a herczeg levele, melyből Baltay újra meg újra olvassa, a mit még nem tudunk.

– Benn van minden a zsebemben? – kérdi újra a szórakozott ember.

– Ott van minden! – felel András, hogy megnyugtassa, pedig felét sem tette oda a megszokottnak, hanem az öreg körültapogatódzott, nem hiányzik-e valami?

– Hát a Kisfaludym itt van-e? (Értsd a könyvet.)

– De már az ott van, – annyit mondhatok! – mondja András itt-ott igazítván el az öreg úron, s aztán elkisérte a nagy teremig, hol a vendégek helyet foglaltak már.

A későn jövőnek oda kell ülni, a hol helye marad, s az a furcsa véletlenség a kis Dunay Jolán mellett hagyott egy üres helyet, s az öreg a sor elején végigmenvén, kénytelen volt leülni, s a fölolvasásokat a kis leány mellett hallgatni; hanem az öreg úr most már engedelmesebb volt maga iránt, s a kedves gyermeket szüntelenül nézte.

Az intézeti növendékek kardala nyitá meg az ünnepélyt, aztán pedig a pályajutalmazottak nevei olvastatának föl.

Kisfaludy Sándor ült az itélőszéken, s a következő sorokat olvasá, míg Jolán előtt a jutalmak álltak, hogy a nyerteseknek oszsza:

«Mi volt őseink kötelessége a haza iránt a multban, s mi a mienk a jelenben?» szól az első kérdés, melynek megfejtője ezüstkoszorút kap gróf Dunay Jolán ajándékából – olvassa a biró – megfejtőjének jeligéje: Kard és könyv!

A mondott jeligéjű levél a hölgy előtt feküdt, s a gyengéd gyermek halványan ült a kis emelvény előtt, melyről a levelet fölvette és midőn fölbontá a levelet, a benne levő nevet nem merte kimondani.

Baltay közelebb hajolt, s a lány elébe tartá a levélkét, hogy könnyebben olvashassa: de Baltay maga is néma maradt, mi a körülülőket, valamint az egész hallgatóságot nagyon meglepte; de még inkább az, hogy András leghátulról szólamlott meg, s azt mondja:

– Az biz az úrfinak a neve, csak mondja ki nagyságos uram! –mondja a kínlódó szolga, ki alig várta, hogy ifjú uraságának dicsőségét lássa.

A derültség általános lőn, s a biró a meglepett ifjút a jutalomért vezeté; a fiú nem mert bátyjára nézni, valamint a leány is reszketve nyúlt a koszorú után.

A grófné és az öreg asszony már készen valának, hogy a reszkető lányt az összerogyástól megóvják, de az öreg még többet is tett, s öcscsének egyik kezét, s a lánynak nyújtva a másikat, mind a kettőt annyira bátorítá, hogy a leány a koszorút átnyújthatta, s a fiú Jolánra mert nézni.

– Én Baltay Imre vagyok! – mutatja be magát Imre a jutalomosztó hölgynél.

– S én e nevet megkoszorúzom – mondja Jolán, odanyújtva a jutalmat.

– Tehát elvihetem? – kérdi bizalmasabban Imre.

– Ejnye, öcsém – szól bele az öreg úr – talán ráadást is akarsz?

– Jutalomnak csekély! – mondja Jolán, átengedvén a csinos művet, melyet Imre remegő kézzel vőn át.

– Kicsiny érdemnek óriás jutalom! – Béke velünk! – mondja czélzatosan Imre, egész erejét összeszedvén, hogy a leány arczán a búcsúszónak hatását is meglássa, ki neki a legjobbat mondá.

A jutalomosztások után következének a szavallatok, azután pedig az egész társaság kiment a kastély melletti kertbe, hogy a berkenyeültetésnek tanúja lehessen.

Az irodalom emberei kiosztott rendben, utánuk a vendégek menének a kertbe, hova nagy tömeg ember kéredzett, s a virágállványokat mászták meg, hogy a leültetést megláthassák, a kinek pedig szék jutott, azon foglalt helyet.

András addig csinálta a helyet másnak, hogy saját úrfiához közel jutott s a jó öreg ember legelőször életében most süvegelte le magát a fiatal ember előtt, ki szárnyai alatt nőtt fel. A fiú hirtelenében azt gondolta, hogy András valakinek másnak teszen ily nagy tiszteletet, hanem midőn látta, hogy András a karjára fűzött koszorú előtt úgy áll

meg, mintha oltárképet látna, mindenkép akarta, hogy András ne álljon előtte ilyen födetlen fővel.

– Tegye fel édes jó öregem!

– Nem én, nagyságos úrfi, hadd gyönyörködjék bennem az úristen, midőn én azt köszönöm meg, hogy az úrfiban megadta érnem, a mit csak reméltem.

– Megelégszik velem, András bácsi?

– Meg, édes úrfi – mondja az öreg jókedvvel – már most elkisértem idáig, nem kell vezetőnek az öreg András, már most azt mondja a nagyságos úr, hogy nem töri el egykönnyen a csontját, én pedig azt látom, hogy a padlásra felhordjuk a legjava szemet, – isten áldja meg az úrfit.

Nem lehet őszintébb az édes anyának öröme, mint ezé az egyszerű emberé, ki a tarka vendégek közt is meg mert szólalni, midőn tudta, hogy azt éri kitüntetés, kit ő gyermekkorától nagyranőni látott.

Siettek a vendégek, csak az öreg asszonyság ment lassan, hogy a tolongást elkerülje, s ha már éppen nem látja is a további ünnepélyt, majd elbeszéli azt neki a kis unokaleány.

– Csókolom kegyes kezét a nagyságos asszonynak – mondja András, kitörölvén szeméből egy nagy könyűt, mit némileg szégyenlett volna kemény hajdú létére annyi ember előtt elcsöppenteni, hanem addig erőlködött, hogy egy tarka kendőbe nyomhatta szét, s mikor megint kinyitá a szemét, a nagyságos asszony mellett állt már.

– Öreg, öreg! – kezdi az asszonyság, – még csak mindig nem akar megvénülni?

– De bizony már nagyon megpuhulok, nagyságos asszonyom, –felel András kulimászos bajszát jobban oldalra húzva, – hanem azért még nincs mindennek vége.

– Mi jót remél, András gazda? – mondja meg nekem is!

– Nagyságos asszonyom, ezek a gyerekek ma megríkattak, de a mint az ízét éreztem annak a könycseppnek, mintha nem volna olyan keserű, mint véltem.

A két öreg elbeszélgetett még, addig pedig a kertbe ért már az egész társaság, hogy a berkenyefát a halhatatlanok emlékére leássák a földbe, s a megkeresztelésnek tanúja legyen az egész népség.

Rövid beszéd után Kis János elvette a Pistától a berkenyeágak egyikét, s a nyitott gödörbe helyezte, mindaddig tartván, míg a fát a körülrakott földtömeg saját gyökerén megtartotta, ekkor azt mondja Kis:

«Gyöngyösy Istvánnak emléke legyen köztünk áldott!»

A zene megszólalt, s egy kis hézagul szolgált, míg a fa helyén állt már, aztán pedig Kisfaludy Sándor ment a körbe, s a fiatalabbaktól átvette az ágát, hogy a gödörbe ereszsze. Már behelyezé az ágat, s Holvagy Pista rakni kezdé a földet, néhányszor azonban fölnézett munka közben, hogy a fának egyenességét a szomszéd fáéhoz mérje, s midőn így felnézett, Kisfaludy tisztán meglátja az arczot, melyet ugyan sohasem feledt el, de hogy egykor megláthassa, még azután is kételkedett, midőn a nádortól megtudta, hogy még életben van.

– Jó barátom, – mondja Kisfaludy, – soha sem láttuk mi egymást?

– Egyszer, nagyon régen! – mondja Pista, megismervén Kisfaludyt.

– Akkor megigértem, hogyha találkozunk, megszólítom, – úgy-e, hogy így mondám?

– Minden szóra emlékszem, uram! – mondja Pista, egészen megtömvén a fa mellékét, s időt engedett Kisfaludynak, hogy a fát jobb kézzel fogván, az ünnepélyt folytassa.

– Kisnek, a nagynak! – szól ünnepélyes hangon a lelkes férfiú, oldalt fordulván, hol Festetics és Dunay közt állt Kis, nem is gyanítva, hogy az egyik fát az ő tiszteletére szánták, s midőn nevét hallá a tegnapi meglepetés által megzaklatott ember, alig tudott támaszkodás nélkül megállni, s Dunay karjára fogván mutatá a vendégseregnek, mely harsogó éljenekkel üdvözlé az ünnepelt költőt.

Visszament az ünnepi sereg a grófi lakba, s míg a menet beért, Kisfaludynak elég alkalma volt elmaradni a többitől, hogy Pistával beszéljen.

– Legelőször is azt mondja meg barátom, hol lakik?

– Keszthelyen, uram, az alsó városon.

– Nem szenved szükséget valamiben?

– Vitéz őrnagy uram, ilyen erős ember, mint én, csak délig koplal.

– De tán mégis volna valami kérni valója, lássa barátom, én sokban segíthetek.

– Magamért soha sem kérek, őrnagy uram, koldus pedig nincs a környéken, mert a méltóságos gróf minden szegénynek juttat valamit.

– Az érdemet nem lehet jutalmazatlanul hagyni – mondja Kisfaludy.

– Nem tudok én annak mértéket venni, őrnagy uram, meg az árát sem tudom.

– Majd tudja más! – viszonzá Kisfaludy, a kapuig kisérteté magát, hol aztán azt is megmagyaráztatá, hogy Pista merre lakik, adandó alkalommal föl akarván keresni Pistát, midőn Kisfaludy majd Budáról megfordul.

Imre bátyjával van, jól esett az öregnek az a tudat, hogy mellőle hajtott ki az ág; de azért egy szót sem szólt néki, hanem csak lógósnak ereszté, hogy a gyerek ne tudja a bácsi büszkeségét,

mikor az a sok ember között olyanképen vezeti a kitüntetett fiút, mintha mutatóba vinné.

Még mindenki ünnepi köntösben van, s az egyik teremben látunk egy zömök embert keményen kisodrott bajuszszal, nagy szakállal, széles karddal, s az egész ember oly készen áll az ütközetre, mintha már azt várná, hogy mondják neki, hova kell bevágni.

Az elmenők nagy figyelemmel köszöntik, környezete sohasem fogy, hanem inkább szaporodik, s ő nem hagyja unatkozni a körülállókat.

Éppen most bámulja valamennyi, mert azt állította, hogy a magyarnak van csak egyedül istene a keresztény faj között, mert a többi már mind megtagadta.

– Hát az angolnak nincsen? – kérdi valaki.

– Nincs bizony, – mondja oly komoly képpel, mintha meg akarna rá esküdni.

– Hát a francziának sincs? – kérdi megint egy másik.

– Annak sincs, és még rosszabb, mint az angol, mert csak félig tagadta meg, nem úgy, mint az angol vagy olasz.

– De hát miből bizonyítja meg ezt, édes Ádám bácsi? – kérdi egy harmadik fiatal ember, ki a vitatkozóval bizalmasabb lábon áll.

– Az legkönnyebb, – mondja a kérdett egy nagy olajfestményhez fordulva, mely éppen az atya istent ábrázolá, szokott helyzetben ülvén mennyei székében.

– Hasonlít ez a kép valami francziához, angolhoz vagy olaszhoz? – kérdi a körülállókat.

– Hisz a francziának csak bajusza van; de szakála nincs! – szól az egyik.

– Az olasznak pedig csak szakála van; de bajusza nincs! –mondja egy másik.

– Az angolnak sem bajusza sem szakála! – jegyzi meg egy harmadik.

– Nekünk pedig szakálunk is van, meg bajuszunk is! – mondja diadallal Ádám bácsi, magára hagyván a bámuló tömeget, melyből valaki kérdi:

– Ki ez az ember?

– Horváth Ádám – nevezi őt meg a kérdett, s egyszersmind elmondá a sajátságokkal megrakott embernek akkor közszájon forgott furcsaságait, minthogy mindig azon törte a fejét, hogy vigyen föl bennünket Adámig, mit aztán névrokona Horváth István meg is cselekedett.

Még többet is mondott Horváth Ádám a heliconi ünnepélyen, melyeket azonban egyenkint fölhordani körünkön kívül esik, hanem mégis említetlenül nem hagyhatánk őt; mert a heliconi ünnepélyeknek mindenkor feltünő tagja volt, s ezen alkalomra mindig tartogatott valami furcsaságot, mit előkerült alkalommal közreadott, s ha bár különczsége nem is volt szentírás, de mindig megbocsátható egy nemzetnek, ha egyes emberei ez előszeretetben akár a legszélső vonalig mennek is el.

Néhány óranegyedig Horváth Ádámmal foglalkozott az egész társaság, s legalább annyi jutalma volt, hogy mindenki vágyott őt meglátni, s ennyi jutalom neki untig elegendő volt elolthatlan buzgalmáért; s ha már e nagy hitnek nem térített is meg sokat, de hallgatni mindenki szerette.

A nagy ebéd elég nagy volt, ennek leírásához nem is fogok; mert először nem értek hozzá, másodszor pedig azt gondolom, hogy ha jó volt, azoknak volt legjobb, kik részt vehettek benne, kiknek annál jobb ízűen eshetett, mert a vendégszeretet olyan embertől jött, ki tetteit nem méltóságos czímével, hazafiúságával mérte föl.

Midőn a vendégsereg nyugodni ment, Dunay még sokáig beszélgetett nejével, s a házastársak boldog reménységgel beszélgettek gyermekük jövendője fölött, s minthogy az öreg

Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.