Byzantine-Tolerant Set-Constrained Delivery Broadcast

Authors Alex Auvolat, Michel Raynal, François Taïani

Thumbnail PDF


  • Filesize: 0.61 MB
  • 23 pages

Document Identifiers

Author Details

Alex Auvolat
  • École Normale Supérieure, Paris, France
  • Univ Rennes, Inria, CNRS, IRISA, Rennes, France
Michel Raynal
  • Univ Rennes, Inria, CNRS, IRISA, Rennes, France
  • Department of Computing, Polytechnic University, Hong Kong
François Taïani
  • Univ Rennes, Inria, CNRS, IRISA, Rennes, France


This work has been partially supported by the French ANR projects DESCARTES n. ANR-16-CE40-0023, and PAMELA n. ANR-16-CE23-0016.

Cite AsGet BibTex

Alex Auvolat, Michel Raynal, and François Taïani. Byzantine-Tolerant Set-Constrained Delivery Broadcast. In 23rd International Conference on Principles of Distributed Systems (OPODIS 2019). Leibniz International Proceedings in Informatics (LIPIcs), Volume 153, pp. 6:1-6:23, Schloss Dagstuhl – Leibniz-Zentrum für Informatik (2020)


Set-Constrained Delivery Broadcast (SCD-broadcast), recently introduced at ICDCN 2018, is a high-level communication abstraction that captures ordering properties not between individual messages but between sets of messages. More precisely, it allows processes to broadcast messages and deliver sets of messages, under the constraint that if a process delivers a set containing a message m before a set containing a message m', then no other process delivers first a set containing m' and later a set containing m. It has been shown that SCD-broadcast and read/write registers are computationally equivalent, and an algorithm implementing SCD-broadcast is known in the context of asynchronous message passing systems prone to crash failures. This paper introduces a Byzantine-tolerant SCD-broadcast algorithm, which we call BSCD-broadcast. Our proposed algorithm assumes an underlying basic Byzantine-tolerant reliable broadcast abstraction. We first introduce an intermediary communication primitive, Byzantine FIFO broadcast (BFIFO-broadcast), which we then use as a primitive in our final BSCD-broadcast algorithm. Unlike the original SCD-broadcast algorithm that is tolerant to up to t<n/2 crashing processes, and unlike the underlying Byzantine reliable broadcast primitive that is tolerant to up to t<n/3 Byzantine processes, our BSCD-broadcast algorithm is tolerant to up to t<n/4 Byzantine processes. As an illustration of the high abstraction power provided by the BSCD-broadcast primitive, we show that it can be used to implement a Byzantine-tolerant read/write snapshot object in an extremely simple way.

Subject Classification

ACM Subject Classification
  • Theory of computation → Distributed algorithms
  • Software and its engineering → Abstraction, modeling and modularity
  • Algorithm
  • Asynchronous system
  • Byzantine process
  • Communication abstraction
  • Distributed computing
  • Distributed software engineering
  • Fault-tolerance
  • Message-passing
  • Modularity
  • Read/write snapshot object
  • Reliable broadcast
  • Set-constrained message delivery


  • Access Statistics
  • Total Accesses (updated on a weekly basis)
    PDF Downloads


  1. Yehuda Afek, Hagit Attiya, Danny Dolev, Eli Gafni, Michael Merritt, and Nir Shavit. Atomic Snapshots of Shared Memory. J. ACM, 40(4):873-890, 1993. URL:
  2. James H. Anderson. Multi-Writer Composite Registers. Distributed Computing, 7(4):175-195, 1994. URL:
  3. Gabriel Bracha. Asynchronous Byzantine Agreement Protocols. Inf. Comput., 75(2):130-143, 1987. URL:
  4. Thomas D. Dickerson, Paul Gazzillo, Maurice Herlihy, and Eric Koskinen. Adding Concurrency to Smart Contracts. In Elad Michael Schiller and Alexander A. Schwarzmann, editors, Proceedings of the ACM Symposium on Principles of Distributed Computing, PODC 2017, Washington, DC, USA, July 25-27, 2017, pages 303-312. ACM, 2017. URL:
  5. Rachid Guerraoui, Petr Kuznetsov, Matteo Monti, Matej Pavlovic, and Dragos-Adrian Seredinschi. The Consensus Number of a Cryptocurrency. In Peter Robinson and Faith Ellen, editors, Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing, PODC 2019, Toronto, ON, Canada, July 29 - August 2, 2019., pages 307-316. ACM, 2019. URL:
  6. Vassos Hadzilacos and Sam Toueg. A modular approach to fault-tolerant broadcasts and related problems. Technical report, Cornell University, 1994. Google Scholar
  7. Maurice Herlihy and Jeannette M. Wing. Linearizability: A Correctness Condition for Concurrent Objects. ACM Trans. Program. Lang. Syst., 12(3):463-492, 1990. URL:
  8. Damien Imbs, Achour Mostéfaoui, Matthieu Perrin, and Michel Raynal. Set-Constrained Delivery Broadcast: Definition, Abstraction Power, and Computability Limits. In Paolo Bellavista and Vijay K. Garg, editors, Proceedings of the 19th International Conference on Distributed Computing and Networking, ICDCN 2018, Varanasi, India, January 4-7, 2018, pages 7:1-7:10. ACM, 2018. URL:
  9. Damien Imbs and Michel Raynal. Trading off t-Resilience for Efficiency in Asynchronous Byzantine Reliable Broadcast. Parallel Processing Letters, 26(4):1-8, 2016. URL:
  10. Leslie Lamport, Robert E. Shostak, and Marshall C. Pease. The Byzantine Generals Problem. ACM Trans. Program. Lang. Syst., 4(3):382-401, 1982. URL:
  11. Satoshi Nakamoto et al. Bitcoin: A peer-to-peer electronic cash system, 2008. Google Scholar
  12. Marshall C. Pease, Robert E. Shostak, and Leslie Lamport. Reaching Agreement in the Presence of Faults. J. ACM, 27(2):228-234, 1980. URL:
  13. Michel Raynal. Fault-Tolerant Message-Passing Distributed Systems - An Algorithmic Approach. Springer, 2018. URL:
  14. Marc Shapiro, Nuno M. Preguiça, Carlos Baquero, and Marek Zawirski. Conflict-Free Replicated Data Types. In Xavier Défago, Franck Petit, and Vincent Villain, editors, Stabilization, Safety, and Security of Distributed Systems - 13th International Symposium, SSS 2011, Grenoble, France, October 10-12, 2011. Proceedings, volume 6976 of Lecture Notes in Computer Science, pages 386-400. Springer, 2011. URL:
Questions / Remarks / Feedback

Feedback for Dagstuhl Publishing

Thanks for your feedback!

Feedback submitted

Could not send message

Please try again later or send an E-mail