Byzantine-Consistent Broadcast- A Promising Yet Challenging Frontier in Digital Asset Transfers
Published:
Digital asset transfer systems are at a crossroads. An idea that first captured attention between 2020 and 2022—Byzantine Consistent Broadcast (BCB)—is now experiencing a revival with projects like Pod and Delta. In this post, we to show that while BCB can unlock incredible performance through parallel state execution, it also introduces important challenges, especially around expressivity and the scalability of reads. The goal is to explain why this approach is both exciting and demanding.
The Rise and Revival of Byzantine Consistent Broadcast
BCB is not just a technical detail—it is rooted in powerful distributed systems theory. The CALM Conjecture (Consistency As Logical Monotonicity) was introduced by Hellerstein in 2010 and later formalized by Ameloot et al. in 2011 (paper). CALM tells us that distributed systems can be consistent without coordination, provided that decisions (or state changes) are never retracted. This insight was reignited in 2019 by Peter Alvaro’s work (paper), sparking a wave of interest among blockchain researchers.
Between 2020 and 2022, projects like FastPay, Linera, and Sui embraced these ideas, showing that BCB protocols can enable systems where each transaction works on its own independent piece of state. Today, with the emergence of Pod and Delta, the approach is back and demands our attention.
Unlocking Parallelism with Independent State
The core strength of BCB-based protocols lies in their ability to execute transactions in parallel. By forcing digital asset systems to adopt a model where each account or piece of state is fully independently owned, these systems remove the need for global coordination. This design has two major implications:
No Shared State: Every transaction operates on its own shard of data. Validators check that the “debits” (the existing state) are valid without the need to sequence every “credit” (new state addition) immediately. This results in linear communication complexity versus the quadratic worst-case overhead seen in traditional Byzantine consensus algorithms.
Parallel Execution: Crucially, BCB protocols don’t inherently eliminate state contention—their semantics require designers to adopt a state model that avoids contention altogether. Thus, the real source of parallelism and speed is the explicit design choice of independently-owned, minimally-contended state. But by encouraging this choice, these protocols push in an important direction, that could finally melt the execution bottleneck that has long plagued blockchain systems.
The performance potential here is enormous. With fewer delays and more parallelism, blockchains can process many transactions at once—making systems like Sui Lutris and Linera prime examples of how to harness this power.
The Challenges: Expressivity, Atomicity, and Read Scalability
However, with great promise come significant challenges:
Limited Expressivity and Complex Atomicity
BCB-based blockchains have realized that state contention is inevitable, so they must offer a programming model that addresses it. There are two main strategies. One strategy uses built-in concurrency primitives—like the CRDTs employed by Delta or the actor model powered by asynchronous explicit cross-chain messaging in Linera. These models assume that most operations occur concurrently, allowing the system to operate on sharded, independently owned state without heavy coordination.
The alternative strategy abandons the sharded, parallel model for a more centralized approach to handling state contention by relying on a consensus algorithm. This is the method adopted by Sui since its Sui-Lutris design.
The choice between these approaches is not straightforward. Research, including the Oliva et al. (2020), indicates that blockchains frequently encounter state contention. If most use cases demand robust management of state contention, then designing a system solely for parallel execution might be less beneficial than one that effectively leverages consensus.
Ultimately, this is less about raw technical capability and more about product design: we must align our blockchain architectures with how users actually interact with state, ensuring that the chosen model meets real-world demands.
The Read Path Bottleneck
One of the most critical challenges for BCB is ensuring reliable and scalable reads:
Complexity of Reads: In consensus-based blockchains, clients can verify state using simple cryptographic proofs, such as Merkle proofs. In contrast, BCB-based systems require clients to query multiple validators. This is because the state is managed in an eventually consistent manner, and eventually consistent protocols by nature do not address censorship: they can’t see daylight between a censoring node and one that’s simply late in receiving data —validators guarantee “nothing but the truth,” but not “the whole truth.” In order to get “the whole truth”, the client must query a large fraction of the validators, relying on Byzantine Fault Tolerance assumptions of a honest super-majority — they cannot request that data from any other actor.
Scalability Issues: This multi-node querying increases latency and puts a heavy burden on every validator to handle a large fraction of global read requests. Unlike consensus systems where full nodes can easily serve delegated read responsibilities, BCB systems force every validator to directly serve client queries, creating a bottleneck that hampers scalability.
Hybrid Approaches: Striking the Right Balance
The challenges of expressivity and read scalability do not spell doom for BCB protocols. In fact, many projects are exploring hybrid models that combine the best of both worlds:
- Periodic Consensus Checkpoints: Systems like Sui and Linera integrate periodic consensus steps or asynchronous messaging to handle shared-state operations.
- Timestamping and Cross-Validation: Pod uses timestamp-based ordering to help align state across validators, offering a path toward more scalable reads, along with an optimistic approach and a read-oriented fraud proof mechanism. This is certainly interesting, though the jury’s still out on whether this will be enough to solve the verifier’s dilemma inherent in this setup.
These hybrid approaches suggest that it is possible to make progress on enjoying the benefits of BCB-driven parallelism while mitigating the downsides. They encourage us to think creatively about blending broadcast protocols with consensus mechanisms to build systems that are both fast and robust.
Why This Matters: A Call to Action
Embracing Byzantine-Consistent Broadcast protocols is not just a technical choice—it is a call for a new way of thinking about digital asset transfers. The BCB approach challenges us to break free from the limitations of traditional blockchains by designing systems that maximize parallelism and performance. However, it also reminds us that every gain comes with trade-offs in expressivity and read scalability.
Byzantine-Consistent Broadcast protocols offer a vision rooted in a more parallel, efficient blockchain world. Yet, they bring significant challenges in expressivity, and especially in the scalability of reads. Both early projects from 2020–2022 and the new wave from 2024–2025 teach us that while the performance potential is enticing, careful system design is crucial. The balance between innovation and practicality will define the next generation of digital asset transfer systems.