From Blockchain to Hashgraph: Distributed Ledger Technologies in the Wild

With the introduction of the term blockchain in 2008, its interest has been increasing in the community since the idea was coined. The reason for this interest is because it provides anonymity, security and integrity without any central third party organisation in control of data and transaction. It has attracted huge interest in research areas due to its advances in various platforms, limitations and challenges. There are various Distributed Ledger Technologies that demonstrates their special features which overcome limitations of other platforms. However, implementations of various distributed ledger technologies differ substantially based on their data structures, consensus protocol and fault tolerant among others. Due to these variations, they have a quite different cost, performance, latency and security. In this paper, working and in-depth comparison of major distributed ledger technologies including their special features, strengths and weaknesses is presented and discussed by identifying various criteria

Lessons from HotStuff

This article will take you on a journey to the core of blockchains, their Byzantine consensus engine, where HotStuff emerged as a new algorithmic foundation for the classical Byzantine generals consensus problem. The first part of the article underscores the theoretical advances HotStuff enabled, including several models in which HotStuff-based solutions closed problems which were opened for decades. The second part focuses on HotStuff performance in real life setting, where its simplicity drove adoption of HotStuff as the golden standard for blockchain design, and many variants and improvements built on top of it. Both parts of this document are meant to describe lessons drawn from HotStuff as well as dispel certain myths

Brief announcement: Malicious security comes for free in consensus with leaders

We consider consensus protocols in the model that is most commonly considered for use in state machine replication, as initiated by Dwork-Lynch-Stockmeyer, then by Castro-Liskov in 1999 with "PBFT."Such protocols guarantee, assuming n players out of which t < n/3 are maliciously corrupted, that the honest players output the same valid value within a finite number of messages, after the (unknown) point in time where both: the network becomes synchronous, and a designated player (the leader) is honest. The state of the art (Hotstuff, PODC'19), achieves linear communication complexity, but at the cost of additional latency, due to one more round-trip with the leader. Furthermore, it relies on constant-size threshold signatures schemes (TSS), for which all prior-known constructions require a costly interactive (or trusted) setup. We remove all of these limitations. The communication bottleneck of PBFT lies in the subprotocol, denoted as "view change,"in which the leader forwards 2t+1 signed messages to each player. Then, each player checks that these 2t+1 messages satisfy some predicate, which we denote "non-supermajority''. We replace this with a responsive subprotocol, with linear communication complexity, that enables players to check this predicate. Its construction is elementary, since it requires only black box use of any TSS. In the full version of our paper \citemalicious2 we achieve three things. Firstly, we further optimize this subprotocol from succinct arguments of many signed messages, which we instantiate from Attema-Cramer-Rambaud \cite[2021-3-9 version]ACR20. As an introduction to these methods, we discuss here the simplest case, which is the construction in \citeACR20 of the first logarithmic-sized TSS with transparent setup. Second, we also address another complexity challenge pointed in Hotstuff, namely, that protocols with fast termination in favorable runs, have so far quadratic complexity, due to an even more complex view change. Third, we enable halting in finite time with (amortized) linear complexity, which was an unsolved question so far when external validity is required