@inproceedings{21042, abstract = {Many blockchains such as Ethereum execute all incoming transactions sequentially significantly limiting the potential throughput. A common approach to scale execution is parallel execution engines that fully utilize modern multi-core architectures. Parallel execution is then either done optimistically, by executing transactions in parallel and detecting conflicts on the fly, or guided, by requiring exhaustive client transaction hints and scheduling transactions accordingly. However, recent studies have shown that the performance of parallel execution engines depends on the nature of the underlying workload. In fact, in some cases, only a 60% speed-up compared to sequential execution could be obtained. This is the case, as transactions that access the same resources must be executed sequentially. For example, if 10% of the transactions in a block access the same resource, the execution cannot meaningfully scale beyond 10 cores. Therefore, a single popular application can bottleneck the execution and limit the potential throughput. In this paper, we introduce Anthemius, a block construction algorithm that optimizes parallel transaction execution throughput. We evaluate Anthemius exhaustively under a range of workloads, and show that Anthemius enables the underlying parallel execution engine to process over twice as many transactions.}, author = {Neiheiser, Ray and Kokoris Kogias, Eleftherios}, booktitle = {29th International Conference on Financial Cryptography and Data Security}, isbn = {9783032070234}, issn = {1611-3349}, location = {Miyakojima, Japan}, pages = {307--323}, publisher = {Springer Nature}, title = {{Anthemius: Efficient and modular block assembly for concurrent execution}}, doi = {10.1007/978-3-032-07024-1_18}, volume = {15751}, year = {2026}, } @article{21017, abstract = {With the growing interest in blockchains, permissioned approaches to consensus have received increasing attention. Unfortunately, the BFT consensus algorithms that are the backbone of most of these blockchains scale poorly and offer limited throughput. In fact, many state-of-the-art BFT consensus algorithms require a single leader process to receive and validate votes from a quorum of processes and then broadcast the result, which is inherently non-scalable. Recent approaches avoid this bottleneck by using dissemination/aggregation trees to propagate values and collect and validate votes. However, the use of trees increases the round latency, which limits the throughput for deeper trees. In this paper we propose Kauri, a BFT communication abstraction that sustains high throughput as the system size grows by leveraging a novel pipelining technique to perform scalable dissemination and aggregation on trees. Furthermore, when the number of faults is moderate (arguably the most common case in practice), our construction is able to recover from faults in an optimal number of reconfiguration steps. We implemented and experimentally evaluated Kauri with up to 800 processes. Our results show that Kauri outperforms the throughput of state-of-the-art permissioned blockchain protocols, by up to 58x without compromising latency. Interestingly, in some cases, the parallelization provided by Kauri can also decrease the latency.}, author = {Neiheiser, Ray and Matos, Miguel and Rodrigues, Luis}, issn = {1557-7333}, journal = {ACM Transactions on Computer Systems}, keywords = {Distributed systems, byzantine fault tolerance, blockchain, vote aggregation, pipelining}, number = {2}, publisher = {Association for Computing Machinery}, title = {{Kauri: BFT consensus with pipelined tree-based dissemination and aggregation}}, doi = {10.1145/3769423}, volume = {44}, year = {2026}, } @article{13988, abstract = {Most permissionless blockchains inherently suffer from throughput limitations. Layer-2 systems, such as side-chains or Rollups, have been proposed as a possible strategy to overcome this limitation. Layer-2 systems interact with the main-chain in two ways. First, users can move funds from/to the main-chain to/from the layer-2. Second, layer-2 systems periodically synchronize with the main-chain to keep some form of log of their activity on the main-chain - this log is key for security. Due to this interaction with the main-chain, which is necessary and recurrent, layer-2 systems impose some load on the main-chain. The impact of such load on the main-chain has been, so far, poorly understood. In addition to that, layer-2 approaches typically sacrifice decentralization and security in favor of higher throughput. This paper presents an experimental study that analyzes the current state of Ethereum layer-2 projects. Our goal is to assess the load they impose on Ethereum and to understand their scalability potential in the long-run. Our analysis shows that the impact of any given layer-2 on the main-chain is the result of both technical aspects (how state is logged on the main-chain) and user behavior (how often users decide to transfer funds between the layer-2 and the main-chain). Based on our observations, we infer that without efficient mechanisms that allow users to transfer funds in a secure and fast manner directly from one layer-2 project to another, current layer-2 systems will not be able to scale Ethereum effectively, regardless of their technical solutions. Furthermore, from our results, we conclude that the layer-2 systems that offer similar security guarantees as Ethereum have limited scalability potential, while approaches that offer better performance, sacrifice security and lead to an increase in centralization which runs against the end-goals of permissionless blockchains.}, author = {Neiheiser, Ray and Inacio, Gustavo and Rech, Luciana and Montez, Carlos and Matos, Miguel and Rodrigues, Luis}, issn = {2169-3536}, journal = {IEEE Access}, keywords = {General Engineering, General Materials Science, General Computer Science, Electrical and Electronic Engineering}, pages = {8651--8662}, publisher = {IEEE}, title = {{Practical limitations of Ethereum’s layer-2}}, doi = {10.1109/access.2023.3237897}, volume = {11}, year = {2023}, }