VLDB 2026 Research / reviewers in the wild / expert
Kai Bleeke
dblp:252/6320
· DBLP profile ↗
5ranked-venue papers
0as first author
4since 2021 · last 2023
0000-0001-6262-305XORCID · corroborated
Domains — the database's venue-derived domains; a paper can count in several
Security and privacy · 3 · 2 since 2021Software engineering, systems software and programming languages · 2 · 2 since 2021Systems, architecture and hardware · 1 · 1 since 2021Computer networks · 1 · 1 since 2021
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2023 | SoK: Scalability Techniques for BFT ConsensusabstractWith the advancement of blockchain systems, many recent research works have proposed distributed ledger technology (DLT) that employs Byzantine fault-tolerant (BFT) consensus protocols to decide which block to append next to the ledger. Notably, BFT consensus can offer high performance, energy efficiency, and provable correctness properties, and it is thus considered a promising building block for creating highly resilient and performant blockchain infrastructures. Yet, a major ongoing challenge is to make BFT consensus applicable to large-scale environments. A large body of recent work addresses this challenge by developing novel ideas to improve the scalability of BFT consensus, thus opening the path for a new generation of BFT protocols tailored to the needs of blockchain. In this survey, we create a systematization of knowledge about the novel scalability-enhancing techniques that state-of-the-art BFT consensus protocols use. For our comparison, we closely analyze the efforts, assumptions, and trade-offs these protocols make. Christian Berger 0006, Signe Rüsch, Arne Vogel, Kai Bleeke, Leander Jehl, Hans P. Reiser, Rüdiger Kapitza |
ICBC | 4 |
| 2023 | ContractBox: Realizing accountable data sharing on the edge using a small scale blockchainabstractThe utilization of IoT devices is becoming omnipresent in industrial settings. However, adoption in more rural areas still poses challenges. Especially when processing data on the edge, privacy, data integrity, accountability and data ownership pose challenges since the devices may be easily accessed and manipulated. We present ContractBox, a system that provides accountable and trusted data sharing based on a publisher–subscriber system, as well as trusted computing on the edge. ContractBox uses a Trusted Execution Environment to guarantee the confidentiality and integrity of clients’ data and code. Furthermore, it provides security by using WebAssembly to execute the smart contracts in their own sandboxed environment. This design protects the host as well as co-located smart contracts from misbehaving executions. Lastly, it ensures the immutability and accountability of the published data by storing it in a blockchain. We show that ContractBox can process several thousand publications per second with various payloads and host multiple smart contract runtimes on a single edge device. ContractBox also achieves up to 35 times higher throughput than a comparable deployment of Hyperledger Fabric. Lennart Almstedt, Kai Bleeke, Mohammad Mahhouk, Leander Jehl, Rüdiger Kapitza, Lars C. Wolf |
Comput. Networks | 2 |
| 2022 | ZugChain: Blockchain-Based Juridical Data Recording in Railway SystemsabstractIn modern trains, a juridical recording unit logs events that occur during operation. This data is used to reconstruct the exact chain of events in case of failures and crashes. To ensure data recovery after an accident, the recorder is hardened against physical damage and secured against tampering; however, it is a single proprietary device and by no means indestructible.This paper presents ZugChain, a distributed, blockchain-based juridical recording unit that opportunistically utilizes on-train hardware. ZugChain offers high reliability via replication and tamper-resistance due to the nature of blockchains. It implements a permissioned blockchain based on a Byzantine fault-tolerant agreement protocol suitable for diverse communication systems. To utilize the logged data for advanced services, e. g., predictive maintenance, ZugChain securely and continuously exports traces to private data centers. We demonstrate ZugChain's feasibility with an implementation running on real train hardware, where we show that ZugChain orders data within 14 ms using at maximum 15 % of the total available shared CPU resources, thus fulfilling requirements of juridical recorders. Signe Rüsch, Kai Bleeke, Ines Messadi, Andreas Krampf, Katharina Olze, Susanne Stahnke, Robert Schmid, Lukas Pirl, Roland Kittel, Andreas Polze, Marquart Franz, Leander Jehl, Rüdiger Kapitza |
DSN | 2 |
| 2022 | SplitBFT: Improving Byzantine Fault Tolerance Safety Using Trusted CompartmentsabstractByzantine fault-tolerant agreement (BFT) in a partially synchronous system usually requires 3f + 1 nodes to tolerate f faulty replicas. Due to their high throughput and finality property, BFT algorithms build the core of recent permissioned blockchains. As a complex and resource-demanding infrastructure, multiple cloud providers have started offering Blockchain-as-a-Service. This eases the deployment of permissioned blockchains but places the cloud provider in a central controlling position, thereby questioning blockchains' fault tolerance and decentralization properties and their underlying BFT algorithm. This paper presents SplitBFT, a new way to utilize trusted execution technology (TEEs), such as Intel SGX, to harden the safety and confidentiality guarantees of BFT systems, thereby strengthening the trust in could-based deployments of permissioned blockchains. Deviating from standard assumptions, SplitBFT acknowledges that code protected by trusted execution may fail. We address this by splitting and isolating the core logic of BFT protocols into multiple compartments resulting in a more resilient architecture. We apply SplitBFT to the traditional practical byzantine fault tolerance algorithm (PBFT) and evaluate it using SGX. Our results show that SplitBFT adds only a reasonable overhead compared to the non-compartmentalized variant. Ines Messadi, Markus Horst Becker, Kai Bleeke, Leander Jehl, Sonia Ben Mokhtar, Rüdiger Kapitza |
Middleware | 3 |
| 2019 | Bloxy: Providing Transparent and Generic BFT-Based Ordering Services for BlockchainsabstractWith the wide-spread use of blockchain technology, Byzantine fault-tolerant (BFT) protocols are explored as a means to achieve consensus on which transactions should be processed next. BFT protocols are not a one-size-fits-all solution: they should be chosen according to the blockchain's use case, which can range from supply chain management to decentralised storage, requiring specialisation e.g. regarding throughput, latency, or level of decentralisation. Previously, consensus protocols were usually hardcoded into the blockchain infrastructure and could not be exchanged, therefore inhibiting flexible use of an otherwise generic blockchain infrastructure. Hyperledger Fabric claims to provide modular consensus and support for crash-fault and Byzantine fault tolerant protocols. However, integrating a BFT protocol has shown that Fabric's architecture is currently not well-suited for this fault model as it requires substantial changes and thereby breaks Fabric's modularity. This also has to be repeated for each integrated BFT protocol. In this paper, we present Bloxy, a blockchain-aware trusted proxy running on the replica that encapsulates all BFT client functionality. Bloxy enables transparent access to generic BFT frameworks and preserves Fabric's modularity even for the Byzantine fault model. It runs inside a trusted execution environment based on Intel's Software Guard Extensions. Bloxy offers blockchain-specific communication mechanisms as well as short-term block storage to handle crashes or disconnects to ensure that all nodes receive block updates. We implemented two Bloxy-based ordering services based on PBFT and the hybrid BFT protocol Hybster. Our evaluation shows that our approach increases throughput by up to 71% compared to directly integrated BFT protocols. Signe Rüsch, Kai Bleeke, Rüdiger Kapitza |
SRDS | 2 |