├── .gitignore ├── CONTRIBUTING.md ├── Makefile ├── README.md ├── README.template.md ├── acks.md ├── acm-siggraph.csl ├── bibliography.bib ├── table.html ├── table.md ├── table.pdf └── table.tex /.gitignore: -------------------------------------------------------------------------------- 1 | ## Core latex/pdflatex auxiliary files: 2 | *.aux 3 | *.lof 4 | *.log 5 | *.lot 6 | *.fls 7 | *.out 8 | *.toc 9 | *.fmt 10 | *.fot 11 | *.cb 12 | *.cb2 13 | .*.lb 14 | 15 | ## Intermediate documents: 16 | *.dvi 17 | *.xdv 18 | *-converted-to.* 19 | # these rules might exclude image files for figures etc. 20 | # *.ps 21 | # *.eps 22 | # *.pdf 23 | 24 | # Output 25 | main.pdf 26 | 27 | ## Bibliography auxiliary files (bibtex/biblatex/biber): 28 | *.bbl 29 | *.bcf 30 | *.blg 31 | *-blx.aux 32 | *-blx.bib 33 | *.run.xml 34 | 35 | ## Build tool auxiliary files: 36 | *.fdb_latexmk 37 | *.synctex 38 | *.synctex(busy) 39 | *.synctex.gz 40 | *.synctex.gz(busy) 41 | *.pdfsync 42 | 43 | ## Build tool directories for auxiliary files 44 | # latexrun 45 | latex.out/ 46 | 47 | ## Auxiliary and intermediate files from other packages: 48 | # algorithms 49 | *.alg 50 | *.loa 51 | 52 | # achemso 53 | acs-*.bib 54 | 55 | # amsthm 56 | *.thm 57 | 58 | # beamer 59 | *.nav 60 | *.pre 61 | *.snm 62 | *.vrb 63 | 64 | # changes 65 | *.soc 66 | 67 | # comment 68 | *.cut 69 | 70 | # cprotect 71 | *.cpt 72 | 73 | # elsarticle (documentclass of Elsevier journals) 74 | *.spl 75 | 76 | # endnotes 77 | *.ent 78 | 79 | # fixme 80 | *.lox 81 | 82 | # feynmf/feynmp 83 | *.mf 84 | *.mp 85 | *.t[1-9] 86 | *.t[1-9][0-9] 87 | *.tfm 88 | 89 | #(r)(e)ledmac/(r)(e)ledpar 90 | *.end 91 | *.?end 92 | *.[1-9] 93 | *.[1-9][0-9] 94 | *.[1-9][0-9][0-9] 95 | *.[1-9]R 96 | *.[1-9][0-9]R 97 | *.[1-9][0-9][0-9]R 98 | *.eledsec[1-9] 99 | *.eledsec[1-9]R 100 | *.eledsec[1-9][0-9] 101 | *.eledsec[1-9][0-9]R 102 | *.eledsec[1-9][0-9][0-9] 103 | *.eledsec[1-9][0-9][0-9]R 104 | 105 | # glossaries 106 | *.acn 107 | *.acr 108 | *.glg 109 | *.glo 110 | *.gls 111 | *.glsdefs 112 | *.lzo 113 | *.lzs 114 | 115 | # uncomment this for glossaries-extra (will ignore makeindex's style files!) 116 | # *.ist 117 | 118 | # gnuplottex 119 | *-gnuplottex-* 120 | 121 | # gregoriotex 122 | *.gaux 123 | *.glog 124 | *.gtex 125 | 126 | # htlatex 127 | *.4ct 128 | *.4tc 129 | *.idv 130 | *.lg 131 | *.trc 132 | *.xref 133 | 134 | # hyperref 135 | *.brf 136 | 137 | # knitr 138 | *-concordance.tex 139 | # TODO Uncomment the next line if you use knitr and want to ignore its generated tikz files 140 | # *.tikz 141 | *-tikzDictionary 142 | 143 | # listings 144 | *.lol 145 | 146 | # luatexja-ruby 147 | *.ltjruby 148 | 149 | # makeidx 150 | *.idx 151 | *.ilg 152 | *.ind 153 | 154 | # minitoc 155 | *.maf 156 | *.mlf 157 | *.mlt 158 | *.mtc[0-9]* 159 | *.slf[0-9]* 160 | *.slt[0-9]* 161 | *.stc[0-9]* 162 | 163 | # minted 164 | _minted* 165 | *.pyg 166 | 167 | # morewrites 168 | *.mw 169 | 170 | # newpax 171 | *.newpax 172 | 173 | # nomencl 174 | *.nlg 175 | *.nlo 176 | *.nls 177 | 178 | # pax 179 | *.pax 180 | 181 | # pdfpcnotes 182 | *.pdfpc 183 | 184 | # sagetex 185 | *.sagetex.sage 186 | *.sagetex.py 187 | *.sagetex.scmd 188 | 189 | # scrwfile 190 | *.wrt 191 | 192 | # sympy 193 | *.sout 194 | *.sympy 195 | sympy-plots-for-*.tex/ 196 | 197 | # pdfcomment 198 | *.upa 199 | *.upb 200 | 201 | # pythontex 202 | *.pytxcode 203 | pythontex-files-*/ 204 | 205 | # tcolorbox 206 | *.listing 207 | 208 | # thmtools 209 | *.loe 210 | 211 | # TikZ & PGF 212 | *.dpth 213 | *.md5 214 | *.auxlock 215 | 216 | # todonotes 217 | *.tdo 218 | 219 | # vhistory 220 | *.hst 221 | *.ver 222 | 223 | # easy-todo 224 | *.lod 225 | 226 | # xcolor 227 | *.xcp 228 | 229 | # xmpincl 230 | *.xmpi 231 | 232 | # xindy 233 | *.xdy 234 | 235 | # xypic precompiled matrices and outlines 236 | *.xyc 237 | *.xyd 238 | 239 | # endfloat 240 | *.ttt 241 | *.fff 242 | 243 | # Latexian 244 | TSWLatexianTemp* 245 | 246 | ## Editors: 247 | # WinEdt 248 | *.bak 249 | *.sav 250 | 251 | # Texpad 252 | .texpadtmp 253 | 254 | # LyX 255 | *.lyx~ 256 | 257 | # Kile 258 | *.backup 259 | 260 | # gummi 261 | .*.swp 262 | 263 | # KBibTeX 264 | *~[0-9]* 265 | 266 | # TeXnicCenter 267 | *.tps 268 | 269 | # auto folder when using emacs and auctex 270 | ./auto/* 271 | *.el 272 | 273 | # expex forward references with \gathertags 274 | *-tags.tex 275 | 276 | # standalone packages 277 | *.sta 278 | 279 | # Makeindex log files 280 | *.lpz 281 | 282 | # xwatermark package 283 | *.xwm 284 | 285 | # REVTeX puts footnotes in the bibliography by default, unless the nofootinbib 286 | # option is specified. Footnotes are the stored in a file with suffix Notes.bib. 287 | # Uncomment the next line to have this generated file ignored. 288 | #*Notes.bib -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # How to contribute a bug report 2 | 3 | If you know of a protocol bug that is not listed, please submit a Pull Request 4 | on GitHub and make sure to include the following in the PR description: 5 | 6 | - a link to the authoritative paper(s)/manuscript(s) describing **the 7 | system** in which the bug was found 8 | - a link to a source describing **the bug** and, if applicable, the process by which the bug was found 9 | 10 | ## Build instructions 11 | 12 | ### Pre-requisites 13 | 14 | To build the table in `pdf`, `html`, and `md` format, we use `pdflatex` and 15 | `pandoc` (with `citeproc`, i.e. a recent version), respectively. You need to 16 | have these installed before you can run `make`. 17 | 18 | On Ubuntu 22.04, you can install them as follows: 19 | 20 | ```bash 21 | sudo apt-get install texlive-full 22 | # Download latest pandoc from https://github.com/jgm/pandoc/releases/latest e.g. 23 | wget https://github.com/jgm/pandoc/releases/download/3.1.6.1/pandoc-3.1.6.1-1-amd64.deb 24 | sudo dpkg -i pandoc-3.1.6.1-1-amd64.deb 25 | # pandoc-include to build README.md (https://github.com/DCsunset/pandoc-include) 26 | sudo apt-get install python3-pip 27 | pip install --user pandoc-include 28 | ``` 29 | 30 | ### Manually modify `bibliography.bib` and `table.tex` 31 | 32 | The repository contains the reference list in multiple formats, including 33 | `bib`, `tex`, `html`, and `md`. 34 | 35 | The source-of-truth is the `table.tex` file (which uses the `bibliography.bib` 36 | file to generate the references). When making a commit, you should therefore 37 | _manually_ modify the `.bib` and `.tex` files, and then run `make` to 38 | _automatically_ generate the other files. 39 | 40 | ### Run `make` to build PDF, HTML, and Markdown 41 | 42 | ```bash 43 | make 44 | ``` 45 | 46 | This should produce `table.pdf`, `table.html`, and `table.md`. Inspect these 47 | files manually and see whether they look OK. In particular, check that the 48 | references are rendered correctly. 49 | 50 | This also automatically updates `README.md`. 51 | 52 | ### Commit all files 53 | 54 | ```bash 55 | git add . 56 | git commit 57 | ``` -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | .PHONY: all 2 | all: table.pdf table.html table.md README.md 3 | 4 | table.pdf: table.tex bibliography.bib 5 | pdflatex -interaction=nonstopmode table 6 | biber table 7 | pdflatex -interaction=nonstopmode table 8 | pdflatex -interaction=nonstopmode table 9 | 10 | table.html: table.tex bibliography.bib 11 | pandoc -s table.tex --bibliography bibliography.bib --csl acm-siggraph.csl --citeproc -o table.html 12 | 13 | table.md: table.tex bibliography.bib 14 | pandoc -s table.tex --bibliography bibliography.bib --csl acm-siggraph.csl --citeproc -t gfm-raw_html -o table.md 15 | 16 | README.md: table.tex bibliography.bib table.md README.template.md 17 | pandoc -s README.template.md --filter pandoc-include -t gfm -o README.md 18 | 19 | .PHONY: clean 20 | clean: 21 | rm -f table.pdf table.html table.md *.dvi *.fls *.fdb_latexmk *.bbl *.blg *.aux *.log *.synctex* *.xml *.bcf *.toc *.maf *.mtc* *.glg *.glo *.gls *.idx *.ilg *.ind *.mw *.nlo *.nls *.xdy 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Errors found in distributed protocols 2 | 3 | This page collects bugs (errors) discovered in the description of 4 | distributed *protocols*. We are only interested in bugs in the protocols 5 | themselves, not implementation bugs. 6 | 7 | **Please submit a pull request if you know of an error that is not 8 | listed!** See `CONTRIBUTING.md` for detailed instructions. 9 | 10 | ## Table of errors 11 | 12 | | Protocol | Reference | Violation | Counter-example | 13 | |:--:|:--:|:--:|:--:| 14 | | PBFT[^1] | \[Castro and Liskov 1999\] | liveness | \[Berger et al. 2021\] | 15 | | Chord | \[Stoica et al. 2001; Liben-Nowell et al. 2002\] | liveness[^2] | \[Zave 2012; Zave 2017\] | 16 | | Pastry | \[Rowstron and Druschel 2001\] | safety | \[Azmy et al. 2016; Azmy et al. 2018\] | 17 | | Generalised Paxos | \[Lamport 2005\] | non-triviality[^3] | \[Sutra and Shapiro 2010\] | 18 | | FaB Paxos | \[Martin and Alvisi 2005; Martin and Alvisi 2006\] | liveness | \[Abraham et al. 2017\] | 19 | | Multi-Paxos[^4] | \[Chandra et al. 2007\] | safety | \[Michael et al. 2017\] | 20 | | Zyzzyva | \[Kotla et al. 2007; Kotla et al. 2010\] | safety | \[Abraham et al. 2017\] | 21 | | CRAQ | \[Terrace and Freedman 2009\] | safety[^5] | \[Whittaker 2020\] | 22 | | JPaxos | \[Kończak et al. 2011\] | safety | \[Michael et al. 2017\] | 23 | | VR Revisited | \[Liskov and Cowling 2012\] | safety | \[Michael et al. 2017\] | 24 | | EPaxos | \[Moraru et al. 2013\] | safety | \[Sutra 2020\] | 25 | | EPaxos | \[Moraru et al. 2013\] | safety | \[Whittaker 2021\] | 26 | | Raft | \[Ongaro and Ousterhout 2014\] | liveness[^6] | \[Hoch 2014\] | 27 | | Raft | \[Ongaro 2014\] | safety[^7] | \[Amos and Zhang 2015; Ongaro 2015\] | 28 | | Raft | \[Ongaro and Ousterhout 2014; Ongaro 2014\] | liveness | \[Howard and Abraham 2020; Jensen et al. 2021\] | 29 | | hBFT | \[Duan et al. 2015\] | safety | \[Shrestha et al. 2019\] | 30 | | Tendermint | \[Buchman 2016\] | liveness | \[Cachin and Vukolić 2017\] | 31 | | CAESAR | \[Arun et al. 2017\] | liveness | \[Enes et al. 2021\] | 32 | | DPaxos | \[Nawab et al. 2018\] | safety | \[Whittaker et al. 2021\] | 33 | | Sync HotStuff | \[Abraham et al. 2019\] | safety & liveness | \[Momose and Cruz 2019\] | 34 | | Gasper | \[Buterin et al. 2020\] | safety & liveness | \[Neu et al. 2021\] | 35 | | STM | \[Imbs and Raynal 2010\] | safety & liveness | \[Belyaev 2010\] | 36 | | FutureBus+ | \[1992\] | safety & liveness | \[Clarke et al. 1993\] | 37 | 38 | ## Acknowledgements 39 | 40 | The following people suggested additions to the list: 41 | 42 | - [Dan Ports](https://drkp.net/) 43 | - [Michael Whittaker](https://mwhittaker.github.io/) 44 | - [Heidi Howard](https://www.heidihoward.co.uk/) 45 | - [François Garillot](https://www.garillot.net/) 46 | - [Prateek Saxena](https://www.comp.nus.edu.sg/~prateeks/) 47 | - [Nibesh Shrestha](https://cs.rit.edu/~nxs4564/) 48 | - [Benedict Elliott Smith](https://twitter.com/_belliottsmith) 49 | - [Adi Seredinschi](https://twitter.com/AdiSeredinschi) 50 | - [Sergey Bronnikov](https://bronevichok.ru/) 51 | 52 | ## References 53 | 54 | ABRAHAM, I., GUETA, G., MALKHI, D., ALVISI, L., KOTLA, R., AND MARTIN, 55 | J.-P. 2017. [Revisiting Fast Practical Byzantine Fault 56 | Tolerance](http://arxiv.org/abs/1712.01367). *arXiv:1712.01367 \[cs\]*. 57 | 58 | ABRAHAM, I., MALKHI, D., NAYAK, K., REN, L., AND YIN, M. 2019. *[Sync 59 | HotStuff: Simple and Practical Synchronous State Machine 60 | Replication](http://eprint.iacr.org/2019/270)*. 61 | 62 | AMOS, B. AND ZHANG, H. 2015. *[15-812 Term Paper: Specifying and proving 63 | cluster membership for the Raft distributed consensus 64 | algorithm](https://www.cs.cmu.edu/~aplatzer/course/pls15/projects/bamos.pdf)*. 65 | 66 | ARUN, B., PELUSO, S., PALMIERI, R., LOSA, G., AND RAVINDRAN, B. 2017. 67 | [Speeding up Consensus by Chasing Fast 68 | Decisions](https://doi.org/10.1109/DSN.2017.35). *2017 47th Annual 69 | IEEE/IFIP International Conference on Dependable Systems and Networks 70 | (DSN)*, 49–60. 71 | 72 | AZMY, N., MERZ, S., AND WEIDENBACH, C. 2016. [A Rigorous Correctness 73 | Proof for Pastry](https://doi.org/10.1007/978-3-319-33600-8_5). In: M. 74 | Butler, K.-D. Schewe, A. Mashkoor and M. Biro, eds., *Abstract State 75 | Machines, Alloy, B, TLA, VDM, and Z*. Springer International Publishing, 76 | Cham, 86–101. 77 | 78 | AZMY, N., MERZ, S., AND WEIDENBACH, C. 2018. [A machine-checked 79 | correctness proof for 80 | Pastry](https://doi.org/10.1016/j.scico.2017.08.003). *Science of 81 | Computer Programming* *158*, 64–80. 82 | 83 | BELYAEV, A. 2010. [Верификация алгоритма поддержки транзакционной памяти 84 | \[Verifying an algorithm for transactional memory 85 | support\]](https://cyberleninka.ru/article/n/verifikatsiya-algoritma-podderzhki-tranzaktsionnoy-pamyati). 86 | *Информатика, телекоммуникации и управление \[Informatics, 87 | telecommunications and control\]. 2010. №3 (101)*. 88 | 89 | BERGER, C., REISER, H.P., AND BESSANI, A. 2021. [Making Reads in BFT 90 | State Machine Replication Fast, Linearizable, and 91 | Live](http://arxiv.org/abs/2107.11144). *arXiv:2107.11144 \[cs\]*. 92 | 93 | BUCHMAN, E. 2016. Tendermint: Byzantine Fault Tolerance in the Age of 94 | Blockchains. . 95 | 96 | BUTERIN, V., HERNANDEZ, D., KAMPHEFNER, T., ET AL. 2020. [Combining 97 | GHOST and Casper](http://arxiv.org/abs/2003.03052). *arXiv:2003.03052 98 | \[cs\]*. 99 | 100 | CACHIN, C. AND VUKOLIĆ, M. 2017. [Blockchain Consensus Protocols in the 101 | Wild](http://arxiv.org/abs/1707.01873). *arXiv:1707.01873 \[cs\]*. 102 | 103 | CASTRO, M. AND LISKOV, B. 1999. [Practical byzantine fault 104 | tolerance](https://www.usenix.org/conference/osdi-99/practical-byzantine-fault-tolerance). 105 | *3rd symposium on operating systems design and implementation (OSDI 106 | 99)*, USENIX Association. 107 | 108 | CHANDRA, T.D., GRIESEMER, R., AND REDSTONE, J. 2007. [Paxos made live: 109 | An engineering perspective](https://doi.org/10.1145/1281100.1281103). 110 | *Proceedings of the twenty-sixth annual ACM symposium on Principles of 111 | distributed computing - PODC ’07*, ACM Press, 398–407. 112 | 113 | CLARKE, E.M., GRUMBERG, O., HIRAISHI, H., ET AL. 1993. [Verification of 114 | the futurebus+ cache coherence protocol](https://CHDL93.pdf). *Computer 115 | hardware description languages and their applications, proceedings of 116 | the 11th IFIP WG10.2 international conference on computer hardware 117 | description languages and their applications - CHDL ’93, sponsored by 118 | IFIP WG10.2 and in cooperation with IEEE COMPSOC, ottawa, ontario, 119 | canada, 26-28 april, 1993*, 15–30. 120 | 121 | DUAN, S., PEISERT, S., AND LEVITT, K.N. 2015. [hBFT: Speculative 122 | Byzantine Fault Tolerance with Minimum 123 | Cost](https://doi.org/10.1109/TDSC.2014.2312331). *IEEE Transactions on 124 | Dependable and Secure Computing* *12*, 1, 58–70. 125 | 126 | ENES, V., BAQUERO, C., GOTSMAN, A., AND SUTRA, P. 2021. [Efficient 127 | replication via timestamp 128 | stability](https://doi.org/10.1145/3447786.3456236). *Proceedings of the 129 | Sixteenth European Conference on Computer Systems*, ACM, 178–193. 130 | 131 | HOCH, E. 2014. Configuration changes. 132 | . 133 | 134 | HOWARD, H. AND ABRAHAM, I. 2020. Raft does not Guarantee Liveness in the 135 | face of Network Faults. 136 | . 137 | 138 | [IEEE 896.1-1991 IEEE STANDARD FOR FUTUREBUS+(R) – LOGICAL PROTOCOL 139 | SPECIFICATION](https://standards.ieee.org/ieee/896.1/1269/). 1992. 140 | 141 | IMBS, D. AND RAYNAL, M. 2010. Software transactional memories: 142 | An approach for multicore programming. *The journal of supercomputing*. 143 | 144 | JENSEN, C., HOWARD, H., AND MORTIER, R. 2021. [Examining Raft’s 145 | behaviour during partial network 146 | failures](https://doi.org/10.1145/3447851.3458739). *Proceedings of the 147 | 1st Workshop on High Availability and Observability of Cloud Systems*, 148 | Association for Computing Machinery, 11–17. 149 | 150 | KOŃCZAK, J., SOUSA SANTOS, N.F. DE, ŻURKOWSKI, T., WOJCIECHOWSKI, P.T., 151 | AND SCHIPER, A. 2011. *JPaxos: State machine replication based on the 152 | Paxos protocol*. 153 | 154 | KOTLA, R., ALVISI, L., DAHLIN, M., CLEMENT, A., AND WONG, E. 2007. 155 | [Zyzzyva: Speculative byzantine fault 156 | tolerance](https://doi.org/10.1145/1323293.1294267). *SIGOPS Oper. Syst. 157 | Rev.* *41*, 6, 45–58. 158 | 159 | KOTLA, R., ALVISI, L., DAHLIN, M., CLEMENT, A., AND WONG, E. 2010. 160 | [Zyzzyva: Speculative byzantine fault 161 | tolerance](https://doi.org/10.1145/1658357.1658358). *ACM Trans. Comput. 162 | Syst.* *27*, 4. 163 | 164 | LAMPORT, L. 2005. *[Generalized Consensus and 165 | Paxos](https://www.microsoft.com/en-us/research/publication/generalized-consensus-and-paxos/)*. 166 | Microsoft Research. 167 | 168 | LIBEN-NOWELL, D., BALAKRISHNAN, H., AND KARGER, D. 2002. [Analysis of 169 | the evolution of peer-to-peer 170 | systems](https://doi.org/10.1145/571825.571863). *Proceedings of the 171 | twenty-first annual symposium on principles of distributed computing*, 172 | Association for Computing Machinery, 233–242. 173 | 174 | LISKOV, B. AND COWLING, J. 2012. *Viewstamped Replication Revisited*. 175 | 176 | MARTIN, J.-P. AND ALVISI, L. 2005. [Fast Byzantine 177 | Consensus](https://doi.org/10.1109/DSN.2005.48). *2005 International 178 | Conference on Dependable Systems and Networks (DSN’05)*, 402–411. 179 | 180 | MARTIN, J.-P. AND ALVISI, L. 2006. [Fast Byzantine 181 | Consensus](http://dx.doi.org.libproxy1.nus.edu.sg/10.1109/TDSC.2006.35). 182 | *IEEE Transactions on Dependable and Secure Computing* *3*, 3, 202–215. 183 | 184 | MICHAEL, E., PORTS, D.R.K., SHARMA, N.K., AND SZEKERES, A. 2017. 185 | Recovering Shared Objects Without Stable Storage. 27. 186 | 187 | MOMOSE, A. AND CRUZ, J.P. 2019. *[Force-Locking Attack on Sync 188 | Hotstuff](http://eprint.iacr.org/2019/1484)*. 189 | 190 | MORARU, I., ANDERSEN, D.G., AND KAMINSKY, M. 2013. [There is more 191 | consensus in Egalitarian 192 | parliaments](https://doi.org/10.1145/2517349.2517350). *Proceedings of 193 | the Twenty-Fourth ACM Symposium on Operating Systems Principles*, 194 | Association for Computing Machinery, 358–372. 195 | 196 | NAWAB, F., AGRAWAL, D., AND EL ABBADI, A. 2018. [DPaxos: Managing Data 197 | Closer to Users for Low-Latency and Mobile 198 | Applications](https://doi.org/10.1145/3183713.3196928). *Proceedings of 199 | the 2018 International Conference on Management of Data*, Association 200 | for Computing Machinery, 1221–1236. 201 | 202 | NEU, J., TAS, E.N., AND TSE, D. 2021. [Ebb-and-Flow Protocols: A 203 | Resolution of the Availability-Finality 204 | Dilemma](http://arxiv.org/abs/2009.04987). *arXiv:2009.04987 \[cs\]*. 205 | 206 | ONGARO, D. 2014. Consensus: Bridging theory and practice. 207 | 208 | ONGARO, D. 2015. Bug in single-server membership changes. 209 | . 210 | 211 | ONGARO, D. AND OUSTERHOUT, J. 2014. In search of an understandable 212 | consensus algorithm. *Proceedings of the 2014 USENIX conference on 213 | USENIX annual technical conference*, USENIX Association, 305–320. 214 | 215 | ROWSTRON, A. AND DRUSCHEL, P. 2001. [Pastry: Scalable, Decentralized 216 | Object Location, and Routing for Large-Scale Peer-to-Peer 217 | Systems](https://doi.org/10.1007/3-540-45518-3_18). *Middleware 2001*, 218 | Springer, 329–350. 219 | 220 | SHRESTHA, N., KUMAR, M., AND DUAN, S. 2019. [Revisiting hBFT: 221 | Speculative Byzantine Fault Tolerance with Minimum 222 | Cost](http://arxiv.org/abs/1902.08505). *arXiv:1902.08505 \[cs\]*. 223 | 224 | STOICA, I., MORRIS, R., KARGER, D., KAASHOEK, M.F., AND BALAKRISHNAN, H. 225 | 2001. [Chord: A scalable peer-to-peer lookup service for internet 226 | applications](https://doi.org/10.1145/964723.383071). *SIGCOMM Comput. 227 | Commun. Rev.* *31*, 4, 149–160. 228 | 229 | SUTRA, P. 2020. [On the correctness of Egalitarian 230 | Paxos](https://doi.org/10.1016/j.ipl.2019.105901). *Information 231 | Processing Letters* *156*. 232 | 233 | SUTRA, P. AND SHAPIRO, M. 2010. *[Fast Genuine Generalized 234 | Consensus](https://drive.google.com/open?id=0BwFkGepvBDQoRjNYRGJTdWQ0SzA)*. 235 | 236 | TERRACE, J. AND FREEDMAN, M.J. 2009. [Object Storage on {CRAQ}: 237 | High-Throughput Chain Replication for Read-Mostly 238 | Workloads](https://www.usenix.org/conference/usenix-09/object-storage-craq-high-throughput-chain-replication-read-mostly-workloads). 239 | 240 | WHITTAKER, M. 2020. CRAQ Bug. . 241 | 242 | WHITTAKER, M. 2021. EPaxos Dependency Set Compaction Bug. 243 | . 244 | 245 | WHITTAKER, M., HELLERSTEIN, J.M., GIRIDHARAN, N., SZEKERES, A., HOWARD, 246 | H., AND NAWAB, F. 2021. Matchmaker Paxos: A Reconfigurable Consensus 247 | Protocol. *Journal of Systems Research*, 22. 248 | 249 | ZAVE, P. 2012. [Using lightweight modeling to understand 250 | chord](https://doi.org/10.1145/2185376.2185383). *ACM SIGCOMM Computer 251 | Communication Review* *42*, 2, 49–57. 252 | 253 | ZAVE, P. 2017. [Reasoning About Identifier Spaces: How to Make Chord 254 | Correct](https://doi.org/10.1109/TSE.2017.2655056). *IEEE Transactions 255 | on Software Engineering* *43*, 12, 1144–1156. 256 | 257 | ## Footnotes 258 | 259 | [^1]: With the read-only optimisation. 260 | 261 | [^2]: Eventual reachability is Chord’s key correctness property. 262 | 263 | [^3]: Acceptors might accept commands that have not been proposed. 264 | 265 | [^4]: As described in Paxos Made Live. 266 | 267 | [^5]: Client reads might fail due to incorrect garbage collection. 268 | 269 | [^6]: The joint consensus membership change algorithm described in the 270 | paper version of Raft had a liveness bug, which was fixed in 271 | Ongaro’s PhD thesis. 272 | 273 | [^7]: The bug is in the single-server membership change scheme described 274 | in Ongaro’s thesis. 275 | -------------------------------------------------------------------------------- /README.template.md: -------------------------------------------------------------------------------- 1 | # Errors found in distributed protocols 2 | 3 | This page collects bugs (errors) discovered in the description of distributed 4 | _protocols_. We are only interested in bugs in the protocols themselves, not 5 | implementation bugs. 6 | 7 | **Please submit a pull request if you know of an error that is not listed!** See 8 | `CONTRIBUTING.md` for detailed instructions. 9 | 10 | ## Table of errors 11 | 12 | !include`snippetStart="(begin table)", snippetEnd="(end table)", raw="markdown"` table.md 13 | 14 | ## Acknowledgements 15 | 16 | !include acks.md 17 | 18 | ## References 19 | 20 | !include`snippetStart="(end table)", snippetEnd="[^1]:"` table.md 21 | 22 | ## Footnotes 23 | 24 | !include`snippetStart="[^1]:", includeSnippetDelimiters=True, raw="markdown"` table.md 25 | -------------------------------------------------------------------------------- /acks.md: -------------------------------------------------------------------------------- 1 | The following people suggested additions to the list: 2 | 3 | - [Dan Ports](https://drkp.net/) 4 | - [Michael Whittaker](https://mwhittaker.github.io/) 5 | - [Heidi Howard](https://www.heidihoward.co.uk/) 6 | - [François Garillot](https://www.garillot.net/) 7 | - [Prateek Saxena](https://www.comp.nus.edu.sg/~prateeks/) 8 | - [Nibesh Shrestha](https://cs.rit.edu/~nxs4564/) 9 | - [Benedict Elliott Smith](https://twitter.com/_belliottsmith) 10 | - [Adi Seredinschi](https://twitter.com/AdiSeredinschi) 11 | - [Sergey Bronnikov](https://bronevichok.ru/) 12 | -------------------------------------------------------------------------------- /acm-siggraph.csl: -------------------------------------------------------------------------------- 1 | 2 | 142 | -------------------------------------------------------------------------------- /bibliography.bib: -------------------------------------------------------------------------------- 1 | 2 | @inproceedings{ongaroSearchUnderstandableConsensus2014, 3 | author = {Ongaro, Diego and Ousterhout, John}, 4 | title = {In Search of an Understandable Consensus Algorithm}, 5 | year = {2014}, 6 | isbn = {9781931971102}, 7 | publisher = {USENIX Association}, 8 | address = {USA}, 9 | abstract = {Raft is a consensus algorithm for managing a replicated log. It produces a result 10 | equivalent to (multi-)Paxos, and it is as efficient as Paxos, but its structure is 11 | different from Paxos; this makes Raft more understandable than Paxos and also provides 12 | a better foundation for building practical systems. In order to enhance understandability, 13 | Raft separates the key elements of consensus, such as leader election, log replication, 14 | and safety, and it enforces a stronger degree of coherency to reduce the number of 15 | states that must be considered. Results from a user study demonstrate that Raft is 16 | easier for students to learn than Paxos. Raft also includes a new mechanism for changing 17 | the cluster membership, which uses overlapping majorities to guarantee safety.}, 18 | booktitle = {Proceedings of the 2014 USENIX Conference on USENIX Annual Technical Conference}, 19 | pages = {305–320}, 20 | numpages = {16}, 21 | location = {Philadelphia, PA}, 22 | series = {USENIX ATC'14} 23 | } 24 | 25 | @misc{ongaroBugSingleserverMembership2015, 26 | title = {bug in single-server membership changes}, 27 | url = {https://groups.google.com/g/raft-dev/c/t4xj6dJTP6E/m/d2D9LrWRza8J}, 28 | urldate = {2021-09-01}, 29 | author = {Ongaro, Diego}, 30 | day = 10, 31 | month = jul, 32 | year = {2015}, 33 | } 34 | 35 | @phdthesis{ongaroConsensusBridgingTheory2014, 36 | author = {Ongaro, Diego}, 37 | advisor = {K., Ousterhout, John and David, Mazi\`{e}res, and Mendel, Rosenblum,}, 38 | title = {Consensus: Bridging Theory and Practice}, 39 | year = {2014}, 40 | isbn = {9798662514218}, 41 | publisher = {Stanford University}, 42 | address = {Stanford, CA, USA}, 43 | abstract = {Distributed consensus is fundamental to building fault-tolerant systems. It allows 44 | a collection of machines to work as a coherent group that can survive the failures 45 | of some of its members. Unfortunately, the most common consensus algorithm, , is widely 46 | regarded as difficult to understand and implement correctly. This dissertation presents 47 | a new consensus algorithm called Raft, which was designed for understandability. Raft 48 | first elects a server as leader, then concentrates all decision-making onto the leader. 49 | These two basic steps are relatively independent and form a better structure than 50 | Paxos, whose components are hard to separate. Raft elects a leader using voting and 51 | randomized timeouts. The election guarantees that the leader already stores all the 52 | information it needs, so data only flows outwards from the leader to other servers. 53 | Compared to other leader-based algorithms, this reduces mechanism and simplifies the 54 | behavior. Once a leader is elected, it manages a replicated log. Raft leverages a 55 | simple invariant on how logs grow to reduce the algorithm's state space and accomplish 56 | this task with minimal mechanism. Raft is also more suitable than previous algorithms 57 | for real-world implementations. It performs well enough for practical deployments, 58 | and it addresses all aspects of building a complete system, including how to manage 59 | client interactions, how to change the cluster membership, and how to compact the 60 | log when it grows too large. To change the cluster membership, Raft allows adding 61 | or removing one server at a time (complex changes can be composed from these basic 62 | steps), and the cluster continues servicing requests throughout the change. We believe 63 | that Raft is superior to Paxos and other consensus algorithms, both for educational 64 | purposes and as a foundation for implementation. Results from a user study demonstrate 65 | that Raft is easier for students to learn than Paxos. The algorithm has been formally 66 | specified and proven, its leader election algorithm works well in a variety of environments, 67 | and its performance is equivalent to Multi-Paxos. Many implementations of Raft are 68 | now available, and several companies are deploying Raft.}, 69 | note = {AAI28121474} 70 | } 71 | 72 | @article{stoicaChordScalablePeertopeer2001, 73 | author = {Stoica, Ion and Morris, Robert and Karger, David and Kaashoek, M. Frans and Balakrishnan, Hari}, 74 | title = {Chord: A Scalable Peer-to-Peer Lookup Service for Internet Applications}, 75 | year = {2001}, 76 | issue_date = {October 2001}, 77 | publisher = {Association for Computing Machinery}, 78 | address = {New York, NY, USA}, 79 | volume = {31}, 80 | number = {4}, 81 | issn = {0146-4833}, 82 | url = {https://doi.org/10.1145/964723.383071}, 83 | doi = {10.1145/964723.383071}, 84 | abstract = {A fundamental problem that confronts peer-to-peer applications is to efficiently locate 85 | the node that stores a particular data item. This paper presents Chord, a distributed 86 | lookup protocol that addresses this problem. Chord provides support for just one operation: 87 | given a key, it maps the key onto a node. Data location can be easily implemented 88 | on top of Chord by associating a key with each data item, and storing the key/data 89 | item pair at the node to which the key maps. Chord adapts efficiently as nodes join 90 | and leave the system, and can answer queries even if the system is continuously changing. 91 | Results from theoretical analysis, simulations, and experiments show that Chord is 92 | scalable, with communication cost and the state maintained by each node scaling logarithmically 93 | with the number of Chord nodes.}, 94 | journal = {SIGCOMM Comput. Commun. Rev.}, 95 | month = aug, 96 | pages = {149–160}, 97 | numpages = {12} 98 | } 99 | 100 | @inproceedings{liben-nowellAnalysisEvolutionPeertopeer2002, 101 | author = {Liben-Nowell, David and Balakrishnan, Hari and Karger, David}, 102 | title = {Analysis of the Evolution of Peer-to-Peer Systems}, 103 | year = {2002}, 104 | isbn = {1581134851}, 105 | publisher = {Association for Computing Machinery}, 106 | address = {New York, NY, USA}, 107 | url = {https://doi.org/10.1145/571825.571863}, 108 | doi = {10.1145/571825.571863}, 109 | abstract = {In this paper, we give a theoretical analysis of peer-to-peer (P2P) networks operating 110 | in the face of concurrent joins and unexpected departures. We focus on Chord, a recently 111 | developed P2P system that implements a distributed hash table abstraction, and study 112 | the process by which Chord maintains its distributed state as nodes join and leave 113 | the system. We argue that traditional performance measures based on run-time are uninformative 114 | for a continually running P2P network, and that the rate at which nodes in the network 115 | need to participate to maintain system state is a more useful metric. We give a general 116 | lower bound on this rate for a network to remain connected, and prove that an appropriately 117 | modified version of Chord's maintenance rate is within a logarithmic factor of the 118 | optimum rate.}, 119 | booktitle = {Proceedings of the Twenty-First Annual Symposium on Principles of Distributed Computing}, 120 | pages = {233–242}, 121 | numpages = {10}, 122 | location = {Monterey, California}, 123 | series = {PODC '02} 124 | } 125 | 126 | @inproceedings{rowstronPastryScalableDecentralized2001, 127 | address = {Berlin, Heidelberg}, 128 | series = {Lecture {Notes} in {Computer} {Science}}, 129 | title = {Pastry: {Scalable}, {Decentralized} {Object} {Location}, and {Routing} for {Large}-{Scale} {Peer}-to-{Peer} {Systems}}, 130 | isbn = {978-3-540-45518-9}, 131 | shorttitle = {Pastry}, 132 | doi = {10.1007/3-540-45518-3_18}, 133 | abstract = {This paper presents the design and evaluation of Pastry, a scalable, distributed object location and routing substrate for wide-area peer-to-peer applications. Pastry performs application-level routing and object location in a potentially very large overlay network of nodes connected via the Internet. It can be used to support a variety of peer-to-peer applications, including global data storage, data sharing, group communication and naming.Each node in the Pastry network has a unique identifier (nodeId). When presented with a message and a key, a Pastry node efficiently routes the message to the node with a nodeId that is numerically closest to the key, among all currently live Pastry nodes. Each Pastry node keeps track of its immediate neighbors in the nodeId space, and notifies applications of new node arrivals, node failures and recoveries. Pastry takes into account network locality; it seeks to minimize the distance messages travel, according to a to scalar proximity metric like the number of IP routing hopsPastry is completely decentralized, scalable, and self-organizing; it automatically adapts to the arrival, departure and failure of nodes. Experimental results obtained with a prototype implementation on an emulated network of up to 100,000 nodes confirm Pastry’s scalability and efficiency, its ability to self-organize and adapt to node failures, and its good network locality properties}, 134 | language = {en}, 135 | booktitle = {Middleware 2001}, 136 | publisher = {Springer}, 137 | author = {Rowstron, Antony and Druschel, Peter}, 138 | editor = {Guerraoui, Rachid}, 139 | year = {2001}, 140 | pages = {329--350}, 141 | } 142 | 143 | @article{kotlaZyzzyvaSpeculativeByzantine2009, 144 | author = {Kotla, Ramakrishna and Alvisi, Lorenzo and Dahlin, Mike and Clement, Allen and Wong, Edmund}, 145 | title = {Zyzzyva: Speculative Byzantine Fault Tolerance}, 146 | year = {2010}, 147 | issue_date = {December 2009}, 148 | publisher = {Association for Computing Machinery}, 149 | address = {New York, NY, USA}, 150 | volume = {27}, 151 | number = {4}, 152 | issn = {0734-2071}, 153 | url = {https://doi.org/10.1145/1658357.1658358}, 154 | doi = {10.1145/1658357.1658358}, 155 | abstract = {A longstanding vision in distributed systems is to build reliable systems from unreliable 156 | components. An enticing formulation of this vision is Byzantine Fault-Tolerant (BFT) 157 | state machine replication, in which a group of servers collectively act as a correct 158 | server even if some of the servers misbehave or malfunction in arbitrary (“Byzantine”) 159 | ways. Despite this promise, practitioners hesitate to deploy BFT systems, at least 160 | partly because of the perception that BFT must impose high overheads.In this article, 161 | we present Zyzzyva, a protocol that uses speculation to reduce the cost of BFT replication. 162 | In Zyzzyva, replicas reply to a client's request without first running an expensive 163 | three-phase commit protocol to agree on the order to process requests. Instead, they 164 | optimistically adopt the order proposed by a primary server, process the request, 165 | and reply immediately to the client. If the primary is faulty, replicas can become 166 | temporarily inconsistent with one another, but clients detect inconsistencies, help 167 | correct replicas converge on a single total ordering of requests, and only rely on 168 | responses that are consistent with this total order. This approach allows Zyzzyva 169 | to reduce replication overheads to near their theoretical minima and to achieve throughputs 170 | of tens of thousands of requests per second, making BFT replication practical for 171 | a broad range of demanding services.}, 172 | journal = {ACM Trans. Comput. Syst.}, 173 | month = jan, 174 | articleno = {7}, 175 | numpages = {39}, 176 | keywords = {output commit, speculative execution, replication, Byzantine fault tolerance} 177 | } 178 | 179 | @inproceedings{10.1145/1294261.1294267, 180 | author = {Kotla, Ramakrishna and Alvisi, Lorenzo and Dahlin, Mike and Clement, Allen and Wong, Edmund}, 181 | title = {Zyzzyva: Speculative Byzantine Fault Tolerance}, 182 | year = {2007}, 183 | isbn = {9781595935915}, 184 | publisher = {Association for Computing Machinery}, 185 | address = {New York, NY, USA}, 186 | url = {https://doi.org/10.1145/1294261.1294267}, 187 | doi = {10.1145/1294261.1294267}, 188 | abstract = {We present Zyzzyva, a protocol that uses speculation to reduce the cost and simplify 189 | the design of Byzantine fault tolerant state machine replication. In Zyzzyva, replicas 190 | respond to a client's request without first running an expensive three-phase commit 191 | protocol to reach agreement on the order in which the request must be processed. Instead, 192 | they optimistically adopt the order proposed by the primary and respond immediately 193 | to the client. Replicas can thus become temporarily inconsistent with one another, 194 | but clients detect inconsistencies, help correct replicas converge on a single total 195 | ordering of requests, and only rely on responses that are consistent with this total 196 | order. This approach allows Zyzzyva to reduce replication overheads to near their 197 | theoretical minimal.}, 198 | booktitle = {Proceedings of Twenty-First ACM SIGOPS Symposium on Operating Systems Principles}, 199 | pages = {45–58}, 200 | numpages = {14}, 201 | keywords = {output commit, byzantine fault tolerance, replication, speculative execution}, 202 | location = {Stevenson, Washington, USA}, 203 | series = {SOSP '07} 204 | } 205 | 206 | @article{kotlaZyzzyvaSpeculativeByzantine2007, 207 | author = {Kotla, Ramakrishna and Alvisi, Lorenzo and Dahlin, Mike and Clement, Allen and Wong, Edmund}, 208 | title = {Zyzzyva: Speculative Byzantine Fault Tolerance}, 209 | year = {2007}, 210 | issue_date = {December 2007}, 211 | publisher = {Association for Computing Machinery}, 212 | address = {New York, NY, USA}, 213 | volume = {41}, 214 | number = {6}, 215 | issn = {0163-5980}, 216 | url = {https://doi.org/10.1145/1323293.1294267}, 217 | doi = {10.1145/1323293.1294267}, 218 | abstract = {We present Zyzzyva, a protocol that uses speculation to reduce the cost and simplify 219 | the design of Byzantine fault tolerant state machine replication. In Zyzzyva, replicas 220 | respond to a client's request without first running an expensive three-phase commit 221 | protocol to reach agreement on the order in which the request must be processed. Instead, 222 | they optimistically adopt the order proposed by the primary and respond immediately 223 | to the client. Replicas can thus become temporarily inconsistent with one another, 224 | but clients detect inconsistencies, help correct replicas converge on a single total 225 | ordering of requests, and only rely on responses that are consistent with this total 226 | order. This approach allows Zyzzyva to reduce replication overheads to near their 227 | theoretical minimal.}, 228 | journal = {SIGOPS Oper. Syst. Rev.}, 229 | month = oct, 230 | pages = {45–58}, 231 | numpages = {14}, 232 | keywords = {byzantine fault tolerance, replication, output commit, speculative execution} 233 | } 234 | 235 | @article{martinFastByzantineConsensus2006, 236 | title = {Fast {Byzantine} {Consensus}}, 237 | volume = {3}, 238 | copyright = {Copyright IEEE Computer Society Jul-Sep 2006}, 239 | issn = {15455971}, 240 | url = {http://www.proquest.com/docview/206534931/abstract/A91EECC1018D4A46PQ/1}, 241 | doi = {http://dx.doi.org.libproxy1.nus.edu.sg/10.1109/TDSC.2006.35}, 242 | abstract = {We present the first protocol that reaches asynchronous Byzantine consensus in two communication steps in the common case. We prove that our protocol is optimal in terms of both number of communication steps and number of processes for two--step consensus. The protocol can be used to build a replicated state machine that requires only three communication steps per request in the common case. Further, we show a parameterized version of the protocol that is safe despite f Byzantine failures and, in the common case, guarantees two-step execution despite some number t of failures (t{\textbackslash}le f). We show that this parameterized two-step consensus protocol is also optimal in terms of both number of communication steps and number of processes. [PUBLICATION ABSTRACT]}, 243 | language = {English}, 244 | number = {3}, 245 | journal = {IEEE Transactions on Dependable and Secure Computing}, 246 | author = {Martin, Jean-Philippe and Alvisi, Lorenzo}, 247 | month = sep, 248 | year = {2006}, 249 | note = {Num Pages: 202-215 250 | Place: Washington, United States 251 | Publisher: IEEE Computer Society}, 252 | keywords = {Communication, Computer programming, Computers--Computer Security, Protocol, Studies}, 253 | pages = {202--215}, 254 | } 255 | 256 | @inproceedings{martinFastByzantineConsensus2005, 257 | title = {Fast {Byzantine} {Consensus}}, 258 | doi = {10.1109/DSN.2005.48}, 259 | abstract = {We present the first consensus protocol that reaches asynchronous Byzantine consensus in two communication steps in the common case. We prove that our protocol is optimal in terms of both number of communication step, and number of processes for 2-step consensus. The protocol can be used to build a replicated state machine that requires only three communication steps per request in the common case.}, 260 | booktitle = {2005 {International} {Conference} on {Dependable} {Systems} and {Networks} ({DSN}'05)}, 261 | author = {Martin, J.-P. and Alvisi, L.}, 262 | month = jun, 263 | year = {2005}, 264 | note = {ISSN: 2158-3927}, 265 | keywords = {Computer crashes, Delay, Fault tolerance, Fault tolerant systems, Paper technology, Pathology, Protection, Protocols, Safety, Software performance}, 266 | pages = {402--411}, 267 | } 268 | 269 | @inproceedings{moraruThereMoreConsensus2013, 270 | address = {New York, NY, USA}, 271 | series = {{SOSP} '13}, 272 | title = {There is more consensus in {Egalitarian} parliaments}, 273 | isbn = {978-1-4503-2388-8}, 274 | url = {http://doi.org/10.1145/2517349.2517350}, 275 | doi = {10.1145/2517349.2517350}, 276 | abstract = {This paper describes the design and implementation of Egalitarian Paxos (EPaxos), a new distributed consensus algorithm based on Paxos. EPaxos achieves three goals: (1) optimal commit latency in the wide-area when tolerating one and two failures, under realistic conditions; (2) uniform load balancing across all replicas (thus achieving high throughput); and (3) graceful performance degradation when replicas are slow or crash. Egalitarian Paxos is to our knowledge the first protocol to achieve the previously stated goals efficiently---that is, requiring only a simple majority of replicas to be non-faulty, using a number of messages linear in the number of replicas to choose a command, and committing commands after just one communication round (one round trip) in the common case or after at most two rounds in any case. We prove Egalitarian Paxos's properties theoretically and demonstrate its advantages empirically through an implementation running on Amazon EC2.}, 277 | booktitle = {Proceedings of the {Twenty}-{Fourth} {ACM} {Symposium} on {Operating} {Systems} {Principles}}, 278 | publisher = {Association for Computing Machinery}, 279 | author = {Moraru, Iulian and Andersen, David G. and Kaminsky, Michael}, 280 | month = nov, 281 | year = {2013}, 282 | pages = {358--372}, 283 | } 284 | 285 | @inproceedings{nawabDPaxosManagingData2018, 286 | address = {New York, NY, USA}, 287 | series = {{SIGMOD} '18}, 288 | title = {{DPaxos}: {Managing} {Data} {Closer} to {Users} for {Low}-{Latency} and {Mobile} {Applications}}, 289 | isbn = {978-1-4503-4703-7}, 290 | shorttitle = {{DPaxos}}, 291 | url = {https://doi.org/10.1145/3183713.3196928}, 292 | doi = {10.1145/3183713.3196928}, 293 | abstract = {In this paper, we propose Dynamic Paxos (DPaxos), a Paxos-based consensus protocol to manage access to partitioned data across globally-distributed datacenters and edge nodes. DPaxos is intended to implement a State Machine Replication component in data management systems for the edge. DPaxos targets the unique opportunities of utilizing edge computing resources to support emerging applications with stringent mobility and real-time requirements such as Augmented and Virtual Reality and vehicular applications. The main objective of DPaxos is to reduce the latency of serving user requests, recovering from failures, and reacting to mobility. DPaxos achieves these objectives by a few proposed changes to the traditional Paxos protocol. Most notably, DPaxos proposes a dynamic allocation of quorums ( i.e. , groups of nodes) that are needed for Paxos Leader Election. Leader Election quorums in DPaxos are smaller than traditional Paxos and expand only in the presence of conflicts.}, 294 | urldate = {2021-09-07}, 295 | booktitle = {Proceedings of the 2018 {International} {Conference} on {Management} of {Data}}, 296 | publisher = {Association for Computing Machinery}, 297 | author = {Nawab, Faisal and Agrawal, Divyakant and El Abbadi, Amr}, 298 | month = may, 299 | year = {2018}, 300 | keywords = {edge computing, geo-replication, multi-datacenter, paxos, transaction processing}, 301 | pages = {1221--1236}, 302 | } 303 | 304 | @techreport{amos15812TermPaper2015, 305 | title = {15-812 {Term} {Paper}: {Specifying} and proving cluster membership for the {Raft} distributed consensus algorithm}, 306 | url = {https://www.cs.cmu.edu/~aplatzer/course/pls15/projects/bamos.pdf}, 307 | author = {Amos, Brandon and Zhang, Huanchen}, 308 | year = {2015}, 309 | pages = {46}, 310 | } 311 | 312 | @misc{howardRaftDoesNot2020, 313 | title = {Raft does not {Guarantee} {Liveness} in the face of {Network} {Faults}}, 314 | url = {https://decentralizedthoughts.github.io/2020-12-12-raft-liveness-full-omission/}, 315 | abstract = {Last month, Cloudflare published a postmortem of a recent 6-hour outage caused by a partial switch failure which left etcd unavailable as it was unable to establish a stable leader. This outage has understandably led to discussion online about exactly what liveness guarantees are provided by the Raft consensus algorithm...}, 316 | urldate = {2021-05-07}, 317 | author = {Howard, Heidi and Abraham, Ittai}, 318 | month = dec, 319 | year = {2020}, 320 | } 321 | 322 | @article{zaveUsingLightweightModeling2012, 323 | title = {Using lightweight modeling to understand chord}, 324 | volume = {42}, 325 | issn = {0146-4833}, 326 | url = {https://dl.acm.org/doi/10.1145/2185376.2185383}, 327 | doi = {10.1145/2185376.2185383}, 328 | abstract = {Correctness of the Chord ring-maintenance protocol would mean that the protocol can eventually repair all disruptions in the ring structure, given ample time and no further disruptions while it is working. In other words, it is “eventual reachability.” Under the same assumptions about failure behavior as made in the Chord papers, no published version of Chord is correct. This result is based on modeling the protocol in Alloy and analyzing it with the Alloy Analyzer. By combining the right selection of pseudocode and textual hints from several papers, and fixing flaws revealed by analysis, it is possible to get a version that may be correct. The paper also discusses the significance of these results, describes briefly how Alloy is used to model and reason about Chord, and compares Alloy analysis to model-checking.}, 329 | language = {en}, 330 | number = {2}, 331 | urldate = {2021-09-06}, 332 | journal = {ACM SIGCOMM Computer Communication Review}, 333 | author = {Zave, Pamela}, 334 | month = mar, 335 | year = {2012}, 336 | pages = {49--57}, 337 | } 338 | 339 | @article{zaveReasoningIdentifierSpaces2017, 340 | title = {Reasoning {About} {Identifier} {Spaces}: {How} to {Make} {Chord} {Correct}}, 341 | volume = {43}, 342 | issn = {1939-3520}, 343 | shorttitle = {Reasoning {About} {Identifier} {Spaces}}, 344 | doi = {10.1109/TSE.2017.2655056}, 345 | abstract = {The Chord distributed hash table (DHT) is well-known and often used to implement peer-to-peer systems. Chord peers find other peers, and access their data, through a ring-shaped pointer structure in a large identifier space. Despite claims of proven correctness, i.e., eventual reachability, previous work has shown that the Chord ring-maintenance protocol is not correct under its original operating assumptions. Previous work has not, however, discovered whether Chord could be made correct under the same assumptions. The contribution of this paper is to provide the first specification of correct operations and initialization for Chord, an inductive invariant that is necessary and sufficient to support a proof of correctness, and two independent proofs of correctness. One proof is informal and intuitive, and applies to networks of any size. The other proof is based on a formal model in Alloy, and uses fully automated analysis to prove the assertions for networks of bounded size. The two proofs complement each other in several important ways.}, 346 | number = {12}, 347 | journal = {IEEE Transactions on Software Engineering}, 348 | author = {Zave, Pamela}, 349 | month = dec, 350 | year = {2017}, 351 | note = {Conference Name: IEEE Transactions on Software Engineering}, 352 | keywords = {Analytical models, Computers and information processing, distributed computing, Distributed processing, formal verification, Formal verification, Information processing, peer-to-peer computing, Peer-to-peer computing, software engineering, Structural rings}, 353 | pages = {1144--1156}, 354 | } 355 | 356 | @incollection{azmyRigorousCorrectnessProof2016, 357 | address = {Cham}, 358 | title = {A {Rigorous} {Correctness} {Proof} for {Pastry}}, 359 | volume = {9675}, 360 | isbn = {978-3-319-33599-5 978-3-319-33600-8}, 361 | url = {http://link.springer.com/10.1007/978-3-319-33600-8_5}, 362 | abstract = {Peer-to-peer protocols for maintaining distributed hash tables, such as Pastry or Chord, have become popular for a class of Internet applications. While such protocols promise certain properties concerning correctness and performance, verification attempts using formal methods invariably discover border cases that violate some of those guarantees. Tianxiang Lu reported correctness problems in published versions of Pastry and also developed a model, which he called LuPastry, for which he provided a partial proof of correct delivery assuming no node departures, mechanized in the TLA+ Proof System. Lu’s proof is based on certain assumptions that were left unproven. We found counter-examples to several of these assumptions. In this paper, we present a revised model and rigorous proof of correct delivery, which we call LuPastry+. Aside from being the first complete proof, LuPastry+ also improves upon Lu’s work by reformulating parts of the specification in such a way that the reasoning complexity is confined to a small part of the proof.}, 363 | language = {en}, 364 | urldate = {2021-09-07}, 365 | booktitle = {Abstract {State} {Machines}, {Alloy}, {B}, {TLA}, {VDM}, and {Z}}, 366 | publisher = {Springer International Publishing}, 367 | author = {Azmy, Noran and Merz, Stephan and Weidenbach, Christoph}, 368 | editor = {Butler, Michael and Schewe, Klaus-Dieter and Mashkoor, Atif and Biro, Miklos}, 369 | year = {2016}, 370 | doi = {10.1007/978-3-319-33600-8_5}, 371 | note = {Series Title: Lecture Notes in Computer Science}, 372 | pages = {86--101}, 373 | } 374 | 375 | @article{azmyMachinecheckedCorrectnessProof2018, 376 | title = {A machine-checked correctness proof for {Pastry}}, 377 | volume = {158}, 378 | issn = {01676423}, 379 | url = {https://linkinghub.elsevier.com/retrieve/pii/S0167642317301612}, 380 | doi = {10.1016/j.scico.2017.08.003}, 381 | abstract = {Protocols implemented on overlay networks in a peer-to-peer (P2P) setting promise flexibility, performance, and scalability due to the possibility for nodes to join and leave the network while the protocol is running. These protocols must ensure that all nodes maintain a consistent view of the network, in the absence of centralized control, so that requests can be routed to the intended destination. This aspect represents an interesting target for formal verification. In previous work, Lu studied the Pastry algorithm for implementing a distributed hash table (DHT) over a P2P network and identified problems in published versions of the algorithm. He suggested a variant of the algorithm, together with a machine-checked proof in the TLA+ Proof System (tlaps), assuming the absence of node failures. We identify and correct problems in Lu’s proof that are due to unchecked assumptions concerning modulus arithmetic and underlying data structures. We introduce higher-level abstractions into the specifications and proofs that are intended for improving the degree of automation achieved by the proof backends. These abstractions are instrumental for presenting the first complete formal proof. Finally, we formally prove that an even simpler version of Lu’s algorithm, in which the final phase of the join protocol is omitted, is still correct, again assuming that nodes do not fail.}, 382 | language = {en}, 383 | urldate = {2021-09-07}, 384 | journal = {Science of Computer Programming}, 385 | author = {Azmy, Noran and Merz, Stephan and Weidenbach, Christoph}, 386 | month = jun, 387 | year = {2018}, 388 | pages = {64--80}, 389 | } 390 | 391 | @article{abrahamRevisitingFastPractical2017, 392 | title = {Revisiting {Fast} {Practical} {Byzantine} {Fault} {Tolerance}}, 393 | url = {http://arxiv.org/abs/1712.01367}, 394 | abstract = {In this note, we observe a safety violation in Zyzzyva and a liveness violation in FaB. To demonstrate these issues, we require relatively simple scenarios, involving only four replicas, and one or two view changes. In all of them, the problem is manifested already in the first log slot.}, 395 | urldate = {2021-09-06}, 396 | journal = {arXiv:1712.01367 [cs]}, 397 | author = {Abraham, Ittai and Gueta, Guy and Malkhi, Dahlia and Alvisi, Lorenzo and Kotla, Rama and Martin, Jean-Philippe}, 398 | month = dec, 399 | year = {2017}, 400 | note = {arXiv: 1712.01367}, 401 | keywords = {Computer Science - Distributed, Parallel, and Cluster Computing}, 402 | } 403 | 404 | 405 | @article{sutraCorrectnessEgalitarianPaxos2020, 406 | title = {On the correctness of {Egalitarian} {Paxos}}, 407 | volume = {156}, 408 | issn = {0020-0190}, 409 | url = {https://www.sciencedirect.com/science/article/pii/S002001901930184X}, 410 | doi = {10.1016/j.ipl.2019.105901}, 411 | abstract = {This paper identifies a problem in both the TLA+ specification and the implementation of the Egalitarian Paxos protocol. It is related to how replicas switch from one ballot to another when computing the dependencies of a command. The problem may lead replicas to diverge and break the linearizability of the replicated service.}, 412 | language = {en}, 413 | urldate = {2021-04-01}, 414 | journal = {Information Processing Letters}, 415 | author = {Sutra, Pierre}, 416 | month = apr, 417 | year = {2020}, 418 | keywords = {Fault tolerance, Consensus, Distributed systems, State-machine replication}, 419 | } 420 | 421 | @article{whittakerMatchmakerPaxosReconfigurable2021, 422 | title = {Matchmaker {Paxos}: {A} {Reconfigurable} {Consensus} {Protocol}}, 423 | abstract = {State machine replication protocols, like MultiPaxos and Raft, are at the heart of numerous distributed systems. To tolerate machine failures, these protocols must replace failed machines with new machines, a process known as reconfiguration. Reconfiguration has become increasingly important over time as the need for frequent reconfiguration has grown. Despite this, reconfiguration has largely been neglected in the literature. In this paper, we present Matchmaker Paxos and Matchmaker MultiPaxos, a reconfigurable consensus and state machine replication protocol respectively. Our protocols can perform a reconfiguration with little to no impact on the latency or throughput of command processing; they can perform a reconfiguration in a few milliseconds; and they present a framework that can be generalized to other replication protocols in a way that previous reconfiguration techniques can not. We provide proofs of correctness for the protocols and optimizations, and present empirical results from an open source implementation showing that throughput and latency do not change significantly during a reconfiguration.}, 424 | language = {en}, 425 | journal = {Journal of Systems Research}, 426 | author = {Whittaker, Michael and Hellerstein, Joseph M and Giridharan, Neil and Szekeres, Adriana and Howard, Heidi and Nawab, Faisal}, 427 | year = {2021}, 428 | pages = {22}, 429 | } 430 | 431 | @article{michaelRecoveringSharedObjects2017, 432 | title = {Recovering {Shared} {Objects} {Without} {Stable} {Storage}}, 433 | abstract = {This paper considers the problem of building fault-tolerant shared objects when processes can crash and recover but lose their persistent state on recovery. This Diskless Crash-Recovery (DCR) model matches the way many long-lived systems are built. We show that it presents new challenges, as operations that are recorded at a quorum may not persist after some of the processes in that quorum crash and then recover.}, 434 | language = {en}, 435 | author = {Michael, Ellis and Ports, Dan R K and Sharma, Naveen Kr and Szekeres, Adriana}, 436 | month = aug, 437 | note = {Appendix B}, 438 | year = {2017}, 439 | pages = {27}, 440 | } 441 | 442 | @techreport{konczakJPaxosStateMachine2011, 443 | title = {{JPaxos}: {State} machine replication based on the {Paxos} protocol}, 444 | shorttitle = {{JPaxos}}, 445 | abstract = {State machine replication is a technique for making services fault-tolerant by replicating them over a group of machines. Although the theory of state machine replication has been studied extensively, the engineering challenges of converting a theoretical description into a fully functional system is less understood. This creates difficulties to implementors, because in designing such a system they face many engineering challenges which are crucial to ensure good performance and stability of a replicated system. In this report, we address this problem by describing the design and implementation of JPaxos, a fully-functional implementation of state machine replication based on the MultiPaxos protocol. Our description includes the basic modules of a state machine replication implementation, like snapshotting of service state, state-transfer and keeping up-to-date all replicas, but focus mainly on three aspects: recovery mechanisms, batching and pipelining optimizations, and a scalable threading-architecture. We present several recovery algorithms that vary in the usage of stable storage and on the system assumptions, including some that use stable storage only once per-recovery. Batching and pipelining are well-known optimizations commonly used in state machine replication. With JPaxos we have studied their interaction in detail, and provide guidelines to tune these mechanisms for a variety of systems. Finally, the threading architecture of JPaxos was designed to scale with the number of cores, while at the same time minimizing complexity to reduce the risk of concurrency bugs}, 446 | number = {EPFL-REPORT-167765}, 447 | author = {Kończak, Jan and de Sousa Santos, Nuno Filipe and Żurkowski, Tomasz and Wojciechowski, Paweł T. and Schiper, André}, 448 | year = {2011}, 449 | keywords = {Distributed Systems, Fault tolerance, Implementation, Paxos, State Machine Replication}, 450 | file = {Kończak et al. - 2011 - JPaxos State machine replication based on the Pax.pdf:C\:\\Users\\georg\\Zotero\\storage\\99JPDXUY\\Kończak et al. - 2011 - JPaxos State machine replication based on the Pax.pdf:application/pdf}, 451 | } 452 | 453 | @techreport{liskovViewstampedReplicationRevisited2012, 454 | title = {Viewstamped {Replication} {Revisited}}, 455 | abstract = {This paper presents an updated version of Viewstamped Replication, a replication technique that handles failures in which nodes crash. It describes how client requests are handled, how the group reorganizes when a replica fails, and how a failed replica is able to rejoin the group. The paper also describes a number of important optimizations and presents a protocol for handling reconfigurations that can change both the group membership and the number of failures the group is able to handle.}, 456 | language = {en}, 457 | number = {MIT-CSAIL-TR-2012-021}, 458 | author = {Liskov, Barbara and Cowling, James}, 459 | month = jul, 460 | year = {2012}, 461 | pages = {16}, 462 | } 463 | 464 | @inproceedings{chandraPaxosMadeLive2007, 465 | address = {Portland, Oregon, USA}, 466 | title = {Paxos made live: an engineering perspective}, 467 | isbn = {978-1-59593-616-5}, 468 | shorttitle = {Paxos made live}, 469 | url = {http://dl.acm.org/citation.cfm?doid=1281100.1281103}, 470 | doi = {10.1145/1281100.1281103}, 471 | abstract = {We describe our experience in building a fault-tolerant data-base using the Paxos consensus algorithm. Despite the existing literature in the field, building such a database proved to be non-trivial. We describe selected algorithmic and engineering problems encountered, and the solutions we found for them. Our measurements indicate that we have built a competitive system.}, 472 | language = {en}, 473 | urldate = {2021-01-19}, 474 | booktitle = {Proceedings of the twenty-sixth annual {ACM} symposium on {Principles} of distributed computing - {PODC} '07}, 475 | publisher = {ACM Press}, 476 | author = {Chandra, Tushar D. and Griesemer, Robert and Redstone, Joshua}, 477 | year = {2007}, 478 | pages = {398--407}, 479 | } 480 | 481 | @misc{hochConfigurationChanges2014, 482 | title = {Configuration changes}, 483 | url = {https://groups.google.com/g/raft-dev/c/xux5HRxH3Ic/m/mz_PDK-qMJgJ}, 484 | urldate = {2021-09-09}, 485 | author = {Hoch, Ezra}, 486 | month = feb, 487 | year = {2014}, 488 | } 489 | 490 | @techreport{sutraFastGenuineGeneralized2010, 491 | title = {Fast {Genuine} {Generalized} {Consensus}}, 492 | url = {https://drive.google.com/open?id=0BwFkGepvBDQoRjNYRGJTdWQ0SzA}, 493 | abstract = {Consensus is a central primitive for building replicated systems, but its latency constitutes a bottleneck. A well-known solution to consensus is Fast Paxos. In a recent paper, Lamport enhances Fast Paxos by leveraging the commutativity of concurrent commands. The new primitive, called Generalized Paxos, reduces the collision rate, and thus the latency of Fast Paxos. However if a collision occurs, the latency of Generalized Paxos equals six communication steps, which is higher than Fast Paxos. This paper presents FGGC , a novel consensus algorithm that reduces recovery delay when a collision occurs to one. FGGC tolerates f {\textless} n/2 replicas crashes, and during failure-free runs, processes learn commands in two steps if all commands commute, and three steps otherwise; this is optimal. Moreover, as long as no fault occurs, FGGC needs only f + 1 replicas to progress.}, 494 | author = {Sutra, Pierre and Shapiro, Marc}, 495 | month = feb, 496 | year = {2010}, 497 | note = {(corrected August 2010). Section 6.3.}, 498 | pages = {62}, 499 | } 500 | 501 | @techreport{lamportGeneralizedConsensusPaxos2005, 502 | title = {Generalized {Consensus} and {Paxos}}, 503 | url = {https://www.microsoft.com/en-us/research/publication/generalized-consensus-and-paxos/}, 504 | abstract = {In [153], I proved lower bounds for the number of message delays required to reach consensus. I showed that the best algorithms can reach consensus in the normal case in 2 message delays. This result in turn led me to a new version of the Paxos algorithm of [122] called Fast Paxos, described in [158], […]}, 505 | number = {MSR-TR-2005-33}, 506 | institution = {Microsoft Research}, 507 | author = {Lamport, Leslie}, 508 | month = mar, 509 | year = {2005}, 510 | } 511 | 512 | @unpublished{whittakerCRAQBug2020, 513 | title = {{CRAQ} {Bug}}, 514 | url = {https://github.com/mwhittaker/craq_bug}, 515 | abstract = {A minor bug in CRAQ's garbage collection}, 516 | urldate = {2021-09-09}, 517 | author = {Whittaker, Michael}, 518 | month = jun, 519 | year = {2020}, 520 | note = {original-date: 2020-06-13T18:44:33Z}, 521 | } 522 | 523 | @inproceedings{terraceObjectStorageCRAQ2009, 524 | title = {Object {Storage} on \{{CRAQ}\}: {High}-{Throughput} {Chain} {Replication} for {Read}-{Mostly} {Workloads}}, 525 | shorttitle = {Object {Storage} on \{{CRAQ}\}}, 526 | url = {https://www.usenix.org/conference/usenix-09/object-storage-craq-high-throughput-chain-replication-read-mostly-workloads}, 527 | urldate = {2021-09-09}, 528 | author = {Terrace, Jeff and Freedman, Michael J.}, 529 | year = {2009}, 530 | } 531 | 532 | @inproceedings{jensenExaminingRaftBehaviour2021, 533 | address = {New York, NY, USA}, 534 | series = {{HAOC} '21}, 535 | title = {Examining {Raft}'s behaviour during partial network failures}, 536 | isbn = {978-1-4503-8336-3}, 537 | url = {https://doi.org/10.1145/3447851.3458739}, 538 | doi = {10.1145/3447851.3458739}, 539 | abstract = {State machine replication protocols such as Raft are widely used to build highly-available strongly-consistent services, maintaining liveness even if a minority of servers crash. As these systems are implemented and optimised for production, they accumulate many divergences from the original specification. These divergences are poorly documented, resulting in operators having an incomplete model of the system's characteristics, especially during failures. In this paper, we look at one such Raft model used to explain the November Cloudflare outage and show that etcd's behaviour during the same failure differs. We continue to show the specific optimisations in etcd causing this difference and present a more complete model of the outage based on etcd's behaviour in an emulated deployment using reckon. Finally, we highlight the upcoming PreVote optimisation in etcd, which might have prevented the outage from happening in the first place.}, 540 | booktitle = {Proceedings of the 1st {Workshop} on {High} {Availability} and {Observability} of {Cloud} {Systems}}, 541 | publisher = {Association for Computing Machinery}, 542 | author = {Jensen, Chris and Howard, Heidi and Mortier, Richard}, 543 | month = apr, 544 | year = {2021}, 545 | keywords = {Cloudflare, etcd, Partial-Partition, Raft}, 546 | pages = {11--17}, 547 | } 548 | 549 | @misc{whittakerEPaxosDependencySet2021, 550 | title = {{EPaxos} {Dependency} {Set} {Compaction} {Bug}}, 551 | url = {https://github.com/mwhittaker/bipartisan_paxos/blob/cbd99cc735215d18c163dc41cb0a05edcb55437d/epaxos_bugs/epaxos_dependency_bug.pdf}, 552 | abstract = {Bipartisan Paxos}, 553 | urldate = {2021-09-16}, 554 | author = {Whittaker, Michael}, 555 | month = sep, 556 | year = {2021}, 557 | note = {original-date: 2018-11-03T04:31:20Z}, 558 | } 559 | 560 | @article{neuEbbandFlowProtocolsResolution2021, 561 | title = {Ebb-and-{Flow} {Protocols}: {A} {Resolution} of the {Availability}-{Finality} {Dilemma}}, 562 | shorttitle = {Ebb-and-{Flow} {Protocols}}, 563 | url = {http://arxiv.org/abs/2009.04987}, 564 | abstract = {The CAP theorem says that no blockchain can be live under dynamic participation and safe under temporary network partitions. To resolve this availability-finality dilemma, we formulate a new class of flexible consensus protocols, ebb-and-flow protocols, which support a full dynamically available ledger in conjunction with a finalized prefix ledger. The finalized ledger falls behind the full ledger when the network partitions but catches up when the network heals. Gasper, the current candidate protocol for Ethereum 2.0's beacon chain, combines the finality gadget Casper FFG with the LMD GHOST fork choice rule and aims to achieve this property. However, we discovered an attack in the standard synchronous network model, highlighting a general difficulty with existing finality-gadget-based designs. We present a construction of provably secure ebb-and-flow protocols with optimal resilience. Nodes run an off-the-shelf dynamically available protocol, take snapshots of the growing available ledger, and input them into a separate off-the-shelf BFT protocol to finalize a prefix. We explore connections with flexible BFT and improve upon the state-of-the-art for that problem.}, 565 | urldate = {2021-09-16}, 566 | journal = {arXiv:2009.04987 [cs]}, 567 | author = {Neu, Joachim and Tas, Ertem Nusret and Tse, David}, 568 | month = feb, 569 | year = {2021}, 570 | note = {arXiv: 2009.04987}, 571 | keywords = {Computer Science - Cryptography and Security, Computer Science - Distributed, Parallel, and Cluster Computing}, 572 | } 573 | 574 | @article{buterinCombiningGHOSTCasper2020, 575 | title = {Combining {GHOST} and {Casper}}, 576 | url = {http://arxiv.org/abs/2003.03052}, 577 | abstract = {We present "Gasper," a proof-of-stake-based consensus protocol, which is an idealized version of the proposed Ethereum 2.0 beacon chain. The protocol combines Casper FFG, a finality tool, with LMD GHOST, a fork-choice rule. We prove safety, plausible liveness, and probabilistic liveness under different sets of assumptions.}, 578 | urldate = {2021-09-16}, 579 | journal = {arXiv:2003.03052 [cs]}, 580 | author = {Buterin, Vitalik and Hernandez, Diego and Kamphefner, Thor and Pham, Khiem and Qiao, Zhi and Ryan, Danny and Sin, Juhyeok and Wang, Ying and Zhang, Yan X.}, 581 | month = may, 582 | year = {2020}, 583 | note = {arXiv: 2003.03052}, 584 | keywords = {68W15, Computer Science - Cryptography and Security}, 585 | } 586 | 587 | 588 | @article{shresthaRevisitingHBFTSpeculative2019, 589 | title = {Revisiting {hBFT}: {Speculative} {Byzantine} {Fault} {Tolerance} with {Minimum} {Cost}}, 590 | shorttitle = {Revisiting {hBFT}}, 591 | url = {http://arxiv.org/abs/1902.08505}, 592 | abstract = {FaB Paxos[5] sets a lower bound of 5f + 1 replicas for any two-step consensus protocols tolerating f byzantine failures. Yet, hBFT[3] promises a two-step consensus protocol with only 3f + 1 replicas. As a result, it violates safety property of a consensus protocol. In this note, we review the lower bound set by FaB Paxos and present a simple execution scenario that produces a safety violation in hBFT. To demonstrate the scenario, we require a relatively simple setup with only 4 replicas and one view-change.}, 593 | urldate = {2021-09-16}, 594 | journal = {arXiv:1902.08505 [cs]}, 595 | author = {Shrestha, Nibesh and Kumar, Mohan and Duan, SiSi}, 596 | month = apr, 597 | year = {2019}, 598 | note = {arXiv: 1902.08505}, 599 | keywords = {Computer Science - Distributed, Parallel, and Cluster Computing}, 600 | } 601 | 602 | @article{duanHBFTSpeculativeByzantine2015, 603 | title = {{hBFT}: {Speculative} {Byzantine} {Fault} {Tolerance} with {Minimum} {Cost}}, 604 | volume = {12}, 605 | issn = {1941-0018}, 606 | shorttitle = {{hBFT}}, 607 | doi = {10.1109/TDSC.2014.2312331}, 608 | abstract = {We present hBFT, a hybrid, Byzantine fault-tolerant, replicated state machine protocol with optimal resilience. Under normal circumstances, hBFT uses speculation, i.e., replicas directly adopt the order from the primary and send replies to the clients. As in prior work such as Zyzzyva, when replicas are out of order, clients can detect the inconsistency and help replicas converge on the total ordering. However, we take a different approach than previous work that has four distinct benefits: it requires many fewer cryptographic operations, it moves critical jobs to the clients with no additional costs, faulty clients can be detected and identified, and performance in the presence of client participation will not degrade as long as the primary is correct. The correctness is guaranteed by a three-phase checkpoint subprotocol similar to PBFT, which is tailored to our needs. The protocol is triggered by the primary when a certain number of requests are executed or by clients when they detect an inconsistency.}, 609 | number = {1}, 610 | journal = {IEEE Transactions on Dependable and Secure Computing}, 611 | author = {Duan, Sisi and Peisert, Sean and Levitt, Karl N.}, 612 | month = jan, 613 | year = {2015}, 614 | note = {Conference Name: IEEE Transactions on Dependable and Secure Computing}, 615 | keywords = {client/server, Concurrent computing, Digital signatures, Distributed systems, fault tolerance, Fault tolerance, Fault tolerant systems, Protocols, Resilience, state machine replication, Switches}, 616 | pages = {58--70}, 617 | } 618 | 619 | 620 | @inproceedings{enesEfficientReplicationTimestamp2021, 621 | address = {Online Event United Kingdom}, 622 | title = {Efficient replication via timestamp stability}, 623 | isbn = {978-1-4503-8334-9}, 624 | url = {https://dl.acm.org/doi/10.1145/3447786.3456236}, 625 | doi = {10.1145/3447786.3456236}, 626 | abstract = {Modern web applications replicate their data across the globe and require strong consistency guarantees for their most critical data. These guarantees are usually provided via statemachine replication (SMR). Recent advances in SMR have focused on leaderless protocols, which improve the availability and performance of traditional Paxos-based solutions. We propose Tempo – a leaderless SMR protocol that, in comparison to prior solutions, achieves superior throughput and offers predictable performance even in contended workloads. To achieve these benefits, Tempo timestamps each application command and executes it only after the timestamp becomes stable, i.e., all commands with a lower timestamp are known. Both the timestamping and stability detection mechanisms are fully decentralized, thus obviating the need for a leader replica. Our protocol furthermore generalizes to partial replication settings, enabling scalability in highly parallel workloads. We evaluate the protocol in both real and simulated geo-distributed environments and demonstrate that it outperforms state-of-the-art alternatives.}, 627 | language = {en}, 628 | urldate = {2021-09-16}, 629 | booktitle = {Proceedings of the {Sixteenth} {European} {Conference} on {Computer} {Systems}}, 630 | publisher = {ACM}, 631 | author = {Enes, Vitor and Baquero, Carlos and Gotsman, Alexey and Sutra, Pierre}, 632 | month = apr, 633 | year = {2021}, 634 | pages = {178--193}, 635 | } 636 | 637 | @inproceedings{arunSpeedingConsensusChasing2017, 638 | title = {Speeding up {Consensus} by {Chasing} {Fast} {Decisions}}, 639 | doi = {10.1109/DSN.2017.35}, 640 | abstract = {This paper proposes CAESAR, a novel multi-leader Generalized Consensus protocol for geographically replicated sites. The main goal of CAESAR is to overcome one of the major limitations of existing approaches, which is the significant performance degradation when application workload produces conflicting requests. CAESAR does that by changing the way a fast decision is taken: its ordering protocol does not reject a fast decision for a client request if a quorum of nodes reply with different dependency sets for that request. The effectiveness of CAESAR is demonstrated through an evaluation study performed on Amazon's EC2 infrastructure using 5 geo-replicated sites. CAESAR outperforms other multi-leader (e.g., EPaxos) competitors by as much as 1.7x in the presence of 30\% conflicting requests, and single-leader (e.g., Multi-Paxos) by up to 3.5x.}, 641 | booktitle = {2017 47th {Annual} {IEEE}/{IFIP} {International} {Conference} on {Dependable} {Systems} and {Networks} ({DSN})}, 642 | author = {Arun, Balaji and Peluso, Sebastiano and Palmieri, Roberto and Losa, Giuliano and Ravindran, Binoy}, 643 | month = jun, 644 | year = {2017}, 645 | note = {ISSN: 2158-3927}, 646 | keywords = {Computer crashes, Consensus, Databases, Degradation, Delays, Geo-Replication, Paxos, Protocols, Reliability, Synchronization}, 647 | pages = {49--60}, 648 | } 649 | 650 | 651 | @techreport{momoseForceLockingAttackSync2019, 652 | title = {Force-{Locking} {Attack} on {Sync} {Hotstuff}}, 653 | url = {http://eprint.iacr.org/2019/1484}, 654 | abstract = {Blockchain, which realizes state machine replication (SMR), is a fundamental building block of decentralized systems, such as cryptocurrencies and smart contracts. These systems require a consensus protocol in their global-scale, public, and trustless networks. In such an environment, consensus protocols require high resiliency, which is the ability to tolerate a fraction of faulty replicas, and thus synchronous protocols have been gaining significant research attention recently. Abraham et al. proposed a simple and practical synchronous SMR protocol called Sync Hotstuff (to be presented in IEEE S{\textbackslash}\&P 2020). Sync Hotstuff achieves \$2{\textbackslash}Delta\$ latency, which is near optimal in a synchronous protocol, and its throughput without lock-step execution is comparable to that of partially synchronous protocols. Sync Hotstuff was presented under a standard synchronous model as well as under a weaker, but more realistic, model called mobile sluggish model. Sync Hotstuff also adopts an optimistic responsive mode, in which the latency is independent of \${\textbackslash}Delta\$. However, Sync Hotstuff has a critical security vulnerability with which an adversary can conduct double spending or denial-of-service attack. In this paper, we present an attack we call force-locking attack on Sync Hotstuff. This attack violates the safety, i.e., consistency of agreements, of the protocol under the standard synchronous model and the liveness, i.e., progress of agreements, of all versions of the protocol, including the mobile sluggish model and responsive mode. The force-locking attack is not only a specific attack on Sync Hotstuff but also on some general blockchain protocols. After describing the attack, we will present some refinements to prevent this attack. Our refinements remove the security vulnerability on Sync Hotstuff without any performance compromises. We will also provide formal proofs of the security for each model.}, 655 | number = {1484}, 656 | urldate = {2021-09-16}, 657 | author = {Momose, Atsuki and Cruz, Jason Paul}, 658 | year = {2019}, 659 | keywords = {attack, blockchain, consensus, cryptographic protocols, SMR}, 660 | } 661 | 662 | @techreport{abrahamSyncHotStuffSimple2019, 663 | title = {Sync {HotStuff}: {Simple} and {Practical} {Synchronous} {State} {Machine} {Replication}}, 664 | shorttitle = {Sync {HotStuff}}, 665 | url = {http://eprint.iacr.org/2019/270}, 666 | abstract = {Synchronous solutions for Byzantine Fault Tolerance (BFT) can tolerate up to minority faults. In this work, we present Sync HotStuff, a surprisingly simple and intuitive synchronous BFT solution that achieves consensus with a latency of \$2{\textbackslash}Delta\$ in the steady state (where \${\textbackslash}Delta\$ is a synchronous message delay upper bound). In addition, Sync HotStuff ensures safety in a weaker synchronous model in which the synchrony assumption does not have to hold for all replicas all the time. Moreover, Sync HotStuff has optimistic responsiveness, i.e., it advances at network speed when less than one-quarter of the replicas are not responding. Borrowing from practical partially synchronous BFT solutions, Sync HotStuff has a two-phase leader-based structure, and has been fully prototyped under the standard synchrony assumption. When tolerating a single fault, Sync HotStuff achieves a throughput of over 280 Kops/sec under typical network performance, which is comparable to the best known partially synchronous solution.}, 667 | number = {270}, 668 | urldate = {2021-09-16}, 669 | author = {Abraham, Ittai and Malkhi, Dahlia and Nayak, Kartik and Ren, Ling and Yin, Maofan}, 670 | year = {2019}, 671 | keywords = {blockchains, consensus protocols, Distributed computing, SMR, Synchrony}, 672 | } 673 | 674 | @article{cachinBlockchainConsensusProtocols2017, 675 | title = {Blockchain {Consensus} {Protocols} in the {Wild}}, 676 | url = {http://arxiv.org/abs/1707.01873}, 677 | abstract = {A blockchain is a distributed ledger for recording transactions, maintained by many nodes without central authority through a distributed cryptographic protocol. All nodes validate the information to be appended to the blockchain, and a consensus protocol ensures that the nodes agree on a unique order in which entries are appended. Consensus protocols for tolerating Byzantine faults have received renewed attention because they also address blockchain systems. This work discusses the process of assessing and gaining confidence in the resilience of a consensus protocols exposed to faults and adversarial nodes. We advocate to follow the established practice in cryptography and computer security, relying on public reviews, detailed models, and formal proofs; the designers of several practical systems appear to be unaware of this. Moreover, we review the consensus protocols in some prominent permissioned blockchain platforms with respect to their fault models and resilience against attacks. The protocol comparison covers Hyperledger Fabric, Tendermint, Symbiont, R3{\textasciitilde}Corda, Iroha, Kadena, Chain, Quorum, MultiChain, Sawtooth Lake, Ripple, Stellar, and IOTA.}, 678 | urldate = {2021-09-16}, 679 | journal = {arXiv:1707.01873 [cs]}, 680 | author = {Cachin, Christian and Vukolić, Marko}, 681 | month = jul, 682 | year = {2017}, 683 | note = {arXiv: 1707.01873}, 684 | keywords = {Computer Science - Distributed, Parallel, and Cluster Computing}, 685 | } 686 | 687 | @phdthesis{buchmanTendermintByzantineFault2016, 688 | address = {Guelph, Ontario, Canada}, 689 | title = {Tendermint: {Byzantine} {Fault} {Tolerance} in the {Age} of {Blockchains}}, 690 | url = {https://atrium.lib.uoguelph.ca/xmlui/handle/10214/9769}, 691 | school = {University of Guelph}, 692 | author = {Buchman, Ethan}, 693 | month = jun, 694 | year = {2016}, 695 | } 696 | 697 | @article{bergerMakingReadsBFT2021, 698 | title = {Making {Reads} in {BFT} {State} {Machine} {Replication} {Fast}, {Linearizable}, and {Live}}, 699 | url = {http://arxiv.org/abs/2107.11144}, 700 | abstract = {Practical Byzantine Fault Tolerance (PBFT) is a seminal state machine replication protocol that achieves a performance comparable to non-replicated systems in realistic environments. A reason for such high performance is the set of optimizations introduced in the protocol. One of these optimizations is read-only requests, a particular type of client request which avoids running the three-step agreement protocol and allows replicas to respond directly, thus reducing the latency of reads from five to two communication steps. Given PBFT's broad influence, its design and optimizations influenced many BFT protocols and systems that followed, e.g., BFT-SMaRt. We show, for the first time, that the read-only request optimization introduced in PBFT more than 20 years ago can violate its liveness. Notably, the problem affects not only the optimized read-only operations but also standard, totally-ordered operations. We show this weakness by presenting an attack in which a malicious leader blocks correct clients and present two solutions for patching the protocol, making read-only operations fast and correct. The two solutions were implemented on BFT-SMaRt and evaluated in different scenarios, showing their effectiveness in preventing the identified attack.}, 701 | urldate = {2021-11-10}, 702 | journal = {arXiv:2107.11144 [cs]}, 703 | author = {Berger, Christian and Reiser, Hans P. and Bessani, Alysson}, 704 | month = jul, 705 | year = {2021}, 706 | note = {arXiv: 2107.11144}, 707 | keywords = {Computer Science - Distributed, Parallel, and Cluster Computing}, 708 | } 709 | 710 | @inproceedings {castroPracticalByzantineFault1999, 711 | author = {Miguel Castro and Barbara Liskov}, 712 | title = {Practical Byzantine Fault Tolerance}, 713 | booktitle = {3rd Symposium on Operating Systems Design and Implementation ({OSDI} 99)}, 714 | year = {1999}, 715 | address = {New Orleans, LA}, 716 | url = {https://www.usenix.org/conference/osdi-99/practical-byzantine-fault-tolerance}, 717 | publisher = {{USENIX} Association}, 718 | month = feb, 719 | } 720 | 721 | @inproceedings {Imbs2011, 722 | author = {Damien Imbs and Michel Raynal}, 723 | title = {Software transactional memories: an approach for multicore programming}, 724 | booktitle = {The Journal of Supercomputing}, 725 | year = {2010}, 726 | note = {DOI: https://doi.org/10.1007/s11227-010-0388-0}, 727 | month = feb, 728 | } 729 | 730 | @inproceedings {Belyaev2010, 731 | author = {Alexey Belyaev}, 732 | title = {Верификация алгоритма поддержки транзакционной памяти {[Verifying an algorithm for transactional memory support]}}, 733 | booktitle = {Информатика, телекоммуникации и управление {[Informatics, telecommunications and control]}. 2010. №3 (101)}, 734 | year = {2010}, 735 | url = {https://cyberleninka.ru/article/n/verifikatsiya-algoritma-podderzhki-tranzaktsionnoy-pamyati}, 736 | month = feb, 737 | language = {russian}, 738 | } 739 | 740 | @inproceedings{ClarkeGHJLMN93, 741 | author = {Edmund M. Clarke and 742 | Orna Grumberg and 743 | Hiromi Hiraishi and 744 | Somesh Jha and 745 | David E. Long and 746 | Kenneth L. McMillan and 747 | Linda A. Ness}, 748 | title = {Verification of the Futurebus+ Cache Coherence Protocol}, 749 | booktitle = {Computer Hardware Description Languages and their Applications, Proceedings 750 | of the 11th {IFIP} {WG10.2} International Conference on Computer Hardware 751 | Description Languages and their Applications - {CHDL} '93, sponsored 752 | by {IFIP} {WG10.2} and in cooperation with {IEEE} COMPSOC, Ottawa, 753 | Ontario, Canada, 26-28 April, 1993}, 754 | pages = {15--30}, 755 | year = {1993}, 756 | timestamp = {Thu, 03 Jan 2002 11:54:34 +0100}, 757 | biburl = {https://dblp.org/rec/bib/conf/chdl/ClarkeGHJLMN93}, 758 | bibsource = {dblp computer science bibliography, https://dblp.org}, 759 | } 760 | 761 | @inproceedings{IEEE8961Futurebus, 762 | title = {IEEE 896.1-1991 IEEE Standard for Futurebus+(R) -- Logical Protocol Specification}, 763 | year = {1992}, 764 | url = {https://standards.ieee.org/ieee/896.1/1269/} 765 | } 766 | -------------------------------------------------------------------------------- /table.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | Errors found in distributed protocols 8 | 189 | 190 | 191 |
192 |

Errors found in distributed protocols

193 |
194 |
195 |

(begin table)

196 |
197 |
198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 211 | 214 | 215 | 217 | 218 | 219 | 220 | 223 | 226 | 229 | 230 | 231 | 232 | 235 | 236 | 239 | 240 | 241 | 242 | 245 | 248 | 251 | 252 | 253 | 254 | 257 | 258 | 261 | 262 | 263 | 266 | 268 | 269 | 272 | 273 | 274 | 275 | 278 | 279 | 282 | 283 | 284 | 285 | 288 | 291 | 293 | 294 | 295 | 296 | 299 | 300 | 303 | 304 | 305 | 306 | 309 | 310 | 313 | 314 | 315 | 316 | 319 | 320 | 323 | 324 | 325 | 326 | 329 | 330 | 333 | 334 | 335 | 336 | 339 | 342 | 344 | 345 | 346 | 347 | 349 | 352 | 355 | 356 | 357 | 358 | 361 | 362 | 365 | 366 | 367 | 368 | 371 | 372 | 375 | 376 | 377 | 378 | 381 | 382 | 385 | 386 | 387 | 388 | 391 | 392 | 395 | 396 | 397 | 398 | 400 | 401 | 404 | 405 | 406 | 407 | 410 | 411 | 414 | 415 | 416 | 417 | 420 | 421 | 424 | 425 | 426 | 427 | 429 | 430 | 432 | 433 | 434 | 435 | 437 | 438 | 440 | 441 | 442 |
ProtocolReferenceViolationCounter-example
PBFT1[Castro and Liskov 213 | 1999]liveness[Berger et al. 2021]
Chord[Stoica 222 | et al. 2001; Liben-Nowell et al. 2002]liveness2[Zave 228 | 2012; Zave 2017]
Pastry[Rowstron and 234 | Druschel 2001]safety[Azmy 238 | et al. 2016; Azmy et al. 2018]
Generalised Paxos[Lamport 244 | 2005]non-triviality3[Sutra and Shapiro 250 | 2010]
FaB Paxos[Martin 256 | and Alvisi 2005; Martin and Alvisi 2006]liveness[Abraham et al. 260 | 2017]
Multi-Paxos4[Chandra et al. 2007]safety[Michael et al. 271 | 2017]
Zyzzyva[Kotla 277 | et al. 2007; Kotla et al. 2010]safety[Abraham et al. 281 | 2017]
CRAQ[Terrace and Freedman 287 | 2009]safety5[Whittaker 2020]
JPaxos[Kończak et al. 298 | 2011]safety[Michael et al. 302 | 2017]
VR Revisited[Liskov and 308 | Cowling 2012]safety[Michael et al. 312 | 2017]
EPaxos[Moraru et al. 318 | 2013]safety[Sutra 322 | 2020]
EPaxos[Moraru et al. 328 | 2013]safety[Whittaker 332 | 2021]
Raft[Ongaro and 338 | Ousterhout 2014]liveness6[Hoch 2014]
Raft[Ongaro 2014]safety7[Amos 354 | and Zhang 2015; Ongaro 2015]
Raft[Ongaro 360 | and Ousterhout 2014; Ongaro 2014]liveness[Howard 364 | and Abraham 2020; Jensen et al. 2021]
hBFT[Duan et al. 370 | 2015]safety[Shrestha et al. 374 | 2019]
Tendermint[Buchman 380 | 2016]liveness[Cachin and Vukolić 384 | 2017]
CAESAR[Arun et al. 390 | 2017]liveness[Enes et al. 394 | 2021]
DPaxos[Nawab et al. 2018]safety[Whittaker et 403 | al. 2021]
Sync HotStuff[Abraham et al. 409 | 2019]safety & liveness[Momose and Cruz 413 | 2019]
Gasper[Buterin et al. 419 | 2020]safety & liveness[Neu et al. 423 | 2021]
STM[Imbs and Raynal 2010]safety & liveness[Belyaev 2010]
FutureBus+[1992]safety & liveness[Clarke et al. 1993]
443 |
444 |
445 |

(end table)

446 |
447 |
449 |
451 | Abraham, I., Gueta, G., Malkhi, D., Alvisi, L., 452 | Kotla, R., and Martin, J.-P. 2017. Revisiting Fast 454 | Practical Byzantine Fault 455 | Tolerance. arXiv:1712.01367 [cs]. 456 |
457 |
459 | Abraham, I., Malkhi, D., Nayak, K., Ren, L., and 460 | Yin, M. 2019. Sync 461 | HotStuff: Simple and Practical 462 | Synchronous State Machine 463 | Replication. 464 |
465 |
466 | Amos, B. and Zhang, H. 2015. 15-812 468 | Term Paper: Specifying and 469 | proving cluster membership for the Raft distributed 470 | consensus algorithm. 471 |
472 |
474 | Arun, B., Peluso, S., Palmieri, R., Losa, G., 475 | and Ravindran, B. 2017. Speeding up 477 | Consensus by Chasing Fast 478 | Decisions. 2017 47th Annual 479 | IEEE/IFIP International 480 | Conference on Dependable Systems 481 | and Networks (DSN), 49–60. 482 |
483 |
485 | Azmy, N., Merz, S., and Weidenbach, C. 486 | 2016. A 487 | Rigorous Correctness Proof for 488 | Pastry. In: M. Butler, K.-D. Schewe, A. Mashkoor and M. 489 | Biro, eds., Abstract State Machines, 490 | Alloy, B, TLA, VDM, 491 | and Z. Springer International Publishing, Cham, 492 | 86–101. 493 |
494 |
496 | Azmy, N., Merz, S., and Weidenbach, C. 497 | 2018. A 498 | machine-checked correctness proof for Pastry. 499 | Science of Computer Programming 158, 64–80. 500 |
501 |
502 | Belyaev, A. 2010. Верификация 504 | алгоритма поддержки транзакционной памяти [Verifying an algorithm for transactional memory 506 | support]. Информатика, телекоммуникации и управление 507 | [Informatics, telecommunications and 508 | control]. 2010. №3 (101). 509 |
510 |
512 | Berger, C., Reiser, H.P., and Bessani, A. 513 | 2021. Making 514 | Reads in BFT State 515 | Machine Replication Fast, 516 | Linearizable, and Live. 517 | arXiv:2107.11144 [cs]. 518 |
519 |
521 | Buchman, E. 2016. Tendermint: 522 | Byzantine Fault Tolerance in the 523 | Age of Blockchains. https://atrium.lib.uoguelph.ca/xmlui/handle/10214/9769. 525 |
526 |
528 | Buterin, V., Hernandez, D., Kamphefner, T., et 529 | al. 2020. Combining 530 | GHOST and Casper. arXiv:2003.03052 531 | [cs]. 532 |
533 |
535 | Cachin, C. and Vukolić, M. 2017. Blockchain Consensus 537 | Protocols in the Wild. 538 | arXiv:1707.01873 [cs]. 539 |
540 |
542 | Castro, M. and Liskov, B. 1999. Practical 544 | byzantine fault tolerance. 3rd symposium on operating systems 545 | design and implementation (OSDI 99), 546 | USENIX Association. 547 |
548 |
550 | Chandra, T.D., Griesemer, R., and Redstone, 551 | J. 2007. Paxos 552 | made live: An engineering perspective. Proceedings of the 553 | twenty-sixth annual ACM symposium on 554 | Principles of distributed computing - PODC 555 | ’07, ACM Press, 398–407. 556 |
557 |
558 | Clarke, E.M., Grumberg, O., Hiraishi, H., et 559 | al. 1993. Verification of the 560 | futurebus+ cache coherence protocol. Computer hardware 561 | description languages and their applications, proceedings of the 11th 562 | IFIP WG10.2 international conference on 563 | computer hardware description languages and their applications - 564 | CHDL ’93, sponsored by IFIP 565 | WG10.2 and in cooperation with IEEE COMPSOC, 566 | ottawa, ontario, canada, 26-28 april, 1993, 15–30. 567 |
568 |
570 | Duan, S., Peisert, S., and Levitt, K.N. 571 | 2015. hBFT: Speculative 573 | Byzantine Fault Tolerance with 574 | Minimum Cost. IEEE Transactions on 575 | Dependable and Secure Computing 12, 1, 58–70. 576 |
577 |
579 | Enes, V., Baquero, C., Gotsman, A., and Sutra, 580 | P. 2021. Efficient replication via 582 | timestamp stability. Proceedings of the Sixteenth 583 | European Conference on Computer 584 | Systems, ACM, 178–193. 585 |
586 |
588 | Hoch, E. 2014. Configuration changes. https://groups.google.com/g/raft-dev/c/xux5HRxH3Ic/m/mz_PDK-qMJgJ. 590 |
591 |
592 | Howard, H. and Abraham, I. 2020. Raft 593 | does not Guarantee Liveness in the face of 594 | Network Faults. https://decentralizedthoughts.github.io/2020-12-12-raft-liveness-full-omission/. 596 |
597 |
598 | IEEE 896.1-1991 IEEE 600 | standard for futurebus+(r) – logical protocol specification. 601 | 1992. 602 |
603 |
604 | Imbs, D. and Raynal, M. 2010. Software 605 | transactional memories: An approach for multicore programming. The 606 | journal of supercomputing. 607 |
608 |
610 | Jensen, C., Howard, H., and Mortier, R. 611 | 2021. Examining 612 | Raft’s behaviour during partial network failures. 613 | Proceedings of the 1st Workshop on High 614 | Availability and Observability of 615 | Cloud Systems, Association for Computing 616 | Machinery, 11–17. 617 |
618 |
620 | Kończak, J., Sousa Santos, N.F. de, Żurkowski, 621 | T., Wojciechowski, P.T., and Schiper, A. 2011. 622 | JPaxos: State machine replication based on 623 | the Paxos protocol. 624 |
625 |
627 | Kotla, R., Alvisi, L., Dahlin, M., Clement, A., 628 | and Wong, E. 2007. Zyzzyva: Speculative 630 | byzantine fault tolerance. SIGOPS Oper. Syst. Rev. 631 | 41, 6, 45–58. 632 |
633 |
635 | Kotla, R., Alvisi, L., Dahlin, M., Clement, A., 636 | and Wong, E. 2010. Zyzzyva: Speculative 638 | byzantine fault tolerance. ACM Trans. Comput. Syst. 639 | 27, 4. 640 |
641 |
643 | Lamport, L. 2005. Generalized 645 | Consensus and Paxos. Microsoft 646 | Research. 647 |
648 |
650 | Liben-Nowell, D., Balakrishnan, H., and Karger, 651 | D. 2002. Analysis 652 | of the evolution of peer-to-peer systems. Proceedings of the 653 | twenty-first annual symposium on principles of distributed 654 | computing, Association for Computing Machinery, 233–242. 655 |
656 |
658 | Liskov, B. and Cowling, J. 2012. 659 | Viewstamped Replication Revisited. 660 |
661 |
663 | Martin, J.-P. and Alvisi, L. 2005. Fast Byzantine 665 | Consensus. 2005 International 666 | Conference on Dependable Systems 667 | and Networks (DSN’05), 402–411. 668 |
669 |
671 | Martin, J.-P. and Alvisi, L. 2006. Fast 673 | Byzantine Consensus. IEEE Transactions 674 | on Dependable and Secure Computing 3, 3, 202–215. 675 |
676 |
678 | Michael, E., Ports, D.R.K., Sharma, N.K., and 679 | Szekeres, A. 2017. Recovering Shared 680 | Objects Without Stable 681 | Storage. 27. 682 |
683 |
685 | Momose, A. and Cruz, J.P. 2019. Force-Locking 687 | Attack on Sync Hotstuff. 688 |
689 |
691 | Moraru, I., Andersen, D.G., and Kaminsky, 692 | M. 2013. There 693 | is more consensus in Egalitarian parliaments. 694 | Proceedings of the Twenty-Fourth 695 | ACM Symposium on Operating 696 | Systems Principles, Association for 697 | Computing Machinery, 358–372. 698 |
699 |
701 | Nawab, F., Agrawal, D., and El Abbadi, A. 702 | 2018. DPaxos: 704 | Managing Data Closer to 705 | Users for Low-Latency and 706 | Mobile Applications. Proceedings of 707 | the 2018 International Conference on 708 | Management of Data, Association for 709 | Computing Machinery, 1221–1236. 710 |
711 |
713 | Neu, J., Tas, E.N., and Tse, D. 2021. Ebb-and-Flow 715 | Protocols: A Resolution of the 716 | Availability-Finality 717 | Dilemma. arXiv:2009.04987 [cs]. 718 |
719 |
721 | Ongaro, D. 2014. Consensus: Bridging 722 | theory and practice. 723 |
724 |
726 | Ongaro, D. 2015. Bug in single-server 727 | membership changes. https://groups.google.com/g/raft-dev/c/t4xj6dJTP6E/m/d2D9LrWRza8J. 729 |
730 |
732 | Ongaro, D. and Ousterhout, J. 2014. In 733 | search of an understandable consensus algorithm. Proceedings of the 734 | 2014 USENIX conference on USENIX annual technical conference, 735 | USENIX Association, 305–320. 736 |
737 |
739 | Rowstron, A. and Druschel, P. 2001. Pastry: 741 | Scalable, Decentralized Object 742 | Location, and Routing for 743 | Large-Scale 744 | Peer-to-Peer Systems. 745 | Middleware 2001, Springer, 329–350. 746 |
747 |
749 | Shrestha, N., Kumar, M., and Duan, S. 750 | 2019. Revisiting hBFT: Speculative 752 | Byzantine Fault Tolerance with 753 | Minimum Cost. arXiv:1902.08505 754 | [cs]. 755 |
756 |
758 | Stoica, I., Morris, R., Karger, D., Kaashoek, 759 | M.F., and Balakrishnan, H. 2001. Chord: A scalable 761 | peer-to-peer lookup service for internet applications. SIGCOMM 762 | Comput. Commun. Rev. 31, 4, 149–160. 763 |
764 |
766 | Sutra, P. 2020. On the correctness of 768 | Egalitarian Paxos. Information 769 | Processing Letters 156. 770 |
771 |
773 | Sutra, P. and Shapiro, M. 2010. Fast 775 | Genuine Generalized 776 | Consensus. 777 |
778 |
780 | Terrace, J. and Freedman, M.J. 2009. Object 782 | Storage on {CRAQ}: 783 | High-Throughput Chain 784 | Replication for Read-Mostly 785 | Workloads. 786 |
787 |
788 | Whittaker, M. 2020. CRAQ 789 | Bug. https://github.com/mwhittaker/craq_bug. 791 |
792 |
794 | Whittaker, M. 2021. EPaxos 795 | Dependency Set Compaction 796 | Bug. https://github.com/mwhittaker/bipartisan_paxos/blob/cbd99cc735215d18c163dc41cb0a05edcb55437d/epaxos_bugs/epaxos_dependency_bug.pdf. 798 |
799 |
801 | Whittaker, M., Hellerstein, J.M., Giridharan, 802 | N., Szekeres, A., Howard, H., and Nawab, F. 2021. Matchmaker 803 | Paxos: A Reconfigurable 804 | Consensus Protocol. Journal of Systems 805 | Research, 22. 806 |
807 |
809 | Zave, P. 2012. Using lightweight 811 | modeling to understand chord. ACM SIGCOMM Computer Communication 812 | Review 42, 2, 49–57. 813 |
814 |
816 | Zave, P. 2017. Reasoning 818 | About Identifier Spaces: 819 | How to Make Chord 820 | Correct. IEEE Transactions on Software 821 | Engineering 43, 12, 1144–1156. 822 |
823 |
824 |
826 |
827 |
    828 |

  1. With the read-only optimisation.↩︎

    2. 830 |

  2. Eventual reachability is Chord’s key correctness 831 | property.↩︎

    3. 833 |

  3. Acceptors might accept commands that have not been 834 | proposed.↩︎

    4. 836 |

  4. As described in Paxos Made Live.↩︎

    5. 838 |

  5. Client reads might fail due to incorrect garbage 839 | collection.↩︎

    6. 841 |

  6. The joint consensus membership change algorithm 842 | described in the paper version of Raft had a liveness bug, which was 843 | fixed in Ongaro’s PhD thesis.↩︎

    7. 845 |

  7. The bug is in the single-server membership change scheme 846 | described in Ongaro’s thesis.↩︎

    8. 848 |
849 |
850 | 851 | 852 | -------------------------------------------------------------------------------- /table.md: -------------------------------------------------------------------------------- 1 | --- 2 | bibliography: bibliography.bib 3 | csl: acm-siggraph.csl 4 | title: Errors found in distributed protocols 5 | --- 6 | 7 | (begin table) 8 | 9 | | Protocol | Reference | Violation | Counter-example | 10 | |:--:|:--:|:--:|:--:| 11 | | PBFT[^1] | \[Castro and Liskov 1999\] | liveness | \[Berger et al. 2021\] | 12 | | Chord | \[Stoica et al. 2001; Liben-Nowell et al. 2002\] | liveness[^2] | \[Zave 2012; Zave 2017\] | 13 | | Pastry | \[Rowstron and Druschel 2001\] | safety | \[Azmy et al. 2016; Azmy et al. 2018\] | 14 | | Generalised Paxos | \[Lamport 2005\] | non-triviality[^3] | \[Sutra and Shapiro 2010\] | 15 | | FaB Paxos | \[Martin and Alvisi 2005; Martin and Alvisi 2006\] | liveness | \[Abraham et al. 2017\] | 16 | | Multi-Paxos[^4] | \[Chandra et al. 2007\] | safety | \[Michael et al. 2017\] | 17 | | Zyzzyva | \[Kotla et al. 2007; Kotla et al. 2010\] | safety | \[Abraham et al. 2017\] | 18 | | CRAQ | \[Terrace and Freedman 2009\] | safety[^5] | \[Whittaker 2020\] | 19 | | JPaxos | \[Kończak et al. 2011\] | safety | \[Michael et al. 2017\] | 20 | | VR Revisited | \[Liskov and Cowling 2012\] | safety | \[Michael et al. 2017\] | 21 | | EPaxos | \[Moraru et al. 2013\] | safety | \[Sutra 2020\] | 22 | | EPaxos | \[Moraru et al. 2013\] | safety | \[Whittaker 2021\] | 23 | | Raft | \[Ongaro and Ousterhout 2014\] | liveness[^6] | \[Hoch 2014\] | 24 | | Raft | \[Ongaro 2014\] | safety[^7] | \[Amos and Zhang 2015; Ongaro 2015\] | 25 | | Raft | \[Ongaro and Ousterhout 2014; Ongaro 2014\] | liveness | \[Howard and Abraham 2020; Jensen et al. 2021\] | 26 | | hBFT | \[Duan et al. 2015\] | safety | \[Shrestha et al. 2019\] | 27 | | Tendermint | \[Buchman 2016\] | liveness | \[Cachin and Vukolić 2017\] | 28 | | CAESAR | \[Arun et al. 2017\] | liveness | \[Enes et al. 2021\] | 29 | | DPaxos | \[Nawab et al. 2018\] | safety | \[Whittaker et al. 2021\] | 30 | | Sync HotStuff | \[Abraham et al. 2019\] | safety & liveness | \[Momose and Cruz 2019\] | 31 | | Gasper | \[Buterin et al. 2020\] | safety & liveness | \[Neu et al. 2021\] | 32 | | STM | \[Imbs and Raynal 2010\] | safety & liveness | \[Belyaev 2010\] | 33 | | FutureBus+ | \[1992\] | safety & liveness | \[Clarke et al. 1993\] | 34 | 35 | (end table) 36 | 37 | ABRAHAM, I., GUETA, G., MALKHI, D., ALVISI, L., KOTLA, R., AND MARTIN, 38 | J.-P. 2017. [Revisiting Fast Practical Byzantine Fault 39 | Tolerance](http://arxiv.org/abs/1712.01367). *arXiv:1712.01367 \[cs\]*. 40 | 41 | ABRAHAM, I., MALKHI, D., NAYAK, K., REN, L., AND YIN, M. 2019. *[Sync 42 | HotStuff: Simple and Practical Synchronous State Machine 43 | Replication](http://eprint.iacr.org/2019/270)*. 44 | 45 | AMOS, B. AND ZHANG, H. 2015. *[15-812 Term Paper: Specifying and proving 46 | cluster membership for the Raft distributed consensus 47 | algorithm](https://www.cs.cmu.edu/~aplatzer/course/pls15/projects/bamos.pdf)*. 48 | 49 | ARUN, B., PELUSO, S., PALMIERI, R., LOSA, G., AND RAVINDRAN, B. 2017. 50 | [Speeding up Consensus by Chasing Fast 51 | Decisions](https://doi.org/10.1109/DSN.2017.35). *2017 47th Annual 52 | IEEE/IFIP International Conference on Dependable Systems and Networks 53 | (DSN)*, 49–60. 54 | 55 | AZMY, N., MERZ, S., AND WEIDENBACH, C. 2016. [A Rigorous Correctness 56 | Proof for Pastry](https://doi.org/10.1007/978-3-319-33600-8_5). In: M. 57 | Butler, K.-D. Schewe, A. Mashkoor and M. Biro, eds., *Abstract State 58 | Machines, Alloy, B, TLA, VDM, and Z*. Springer International Publishing, 59 | Cham, 86–101. 60 | 61 | AZMY, N., MERZ, S., AND WEIDENBACH, C. 2018. [A machine-checked 62 | correctness proof for 63 | Pastry](https://doi.org/10.1016/j.scico.2017.08.003). *Science of 64 | Computer Programming* *158*, 64–80. 65 | 66 | BELYAEV, A. 2010. [Верификация алгоритма поддержки транзакционной памяти 67 | \[Verifying an algorithm for transactional memory 68 | support\]](https://cyberleninka.ru/article/n/verifikatsiya-algoritma-podderzhki-tranzaktsionnoy-pamyati). 69 | *Информатика, телекоммуникации и управление \[Informatics, 70 | telecommunications and control\]. 2010. №3 (101)*. 71 | 72 | BERGER, C., REISER, H.P., AND BESSANI, A. 2021. [Making Reads in BFT 73 | State Machine Replication Fast, Linearizable, and 74 | Live](http://arxiv.org/abs/2107.11144). *arXiv:2107.11144 \[cs\]*. 75 | 76 | BUCHMAN, E. 2016. Tendermint: Byzantine Fault Tolerance in the Age of 77 | Blockchains. . 78 | 79 | BUTERIN, V., HERNANDEZ, D., KAMPHEFNER, T., ET AL. 2020. [Combining 80 | GHOST and Casper](http://arxiv.org/abs/2003.03052). *arXiv:2003.03052 81 | \[cs\]*. 82 | 83 | CACHIN, C. AND VUKOLIĆ, M. 2017. [Blockchain Consensus Protocols in the 84 | Wild](http://arxiv.org/abs/1707.01873). *arXiv:1707.01873 \[cs\]*. 85 | 86 | CASTRO, M. AND LISKOV, B. 1999. [Practical byzantine fault 87 | tolerance](https://www.usenix.org/conference/osdi-99/practical-byzantine-fault-tolerance). 88 | *3rd symposium on operating systems design and implementation (OSDI 89 | 99)*, USENIX Association. 90 | 91 | CHANDRA, T.D., GRIESEMER, R., AND REDSTONE, J. 2007. [Paxos made live: 92 | An engineering perspective](https://doi.org/10.1145/1281100.1281103). 93 | *Proceedings of the twenty-sixth annual ACM symposium on Principles of 94 | distributed computing - PODC ’07*, ACM Press, 398–407. 95 | 96 | CLARKE, E.M., GRUMBERG, O., HIRAISHI, H., ET AL. 1993. [Verification of 97 | the futurebus+ cache coherence protocol](https://CHDL93.pdf). *Computer 98 | hardware description languages and their applications, proceedings of 99 | the 11th IFIP WG10.2 international conference on computer hardware 100 | description languages and their applications - CHDL ’93, sponsored by 101 | IFIP WG10.2 and in cooperation with IEEE COMPSOC, ottawa, ontario, 102 | canada, 26-28 april, 1993*, 15–30. 103 | 104 | DUAN, S., PEISERT, S., AND LEVITT, K.N. 2015. [hBFT: Speculative 105 | Byzantine Fault Tolerance with Minimum 106 | Cost](https://doi.org/10.1109/TDSC.2014.2312331). *IEEE Transactions on 107 | Dependable and Secure Computing* *12*, 1, 58–70. 108 | 109 | ENES, V., BAQUERO, C., GOTSMAN, A., AND SUTRA, P. 2021. [Efficient 110 | replication via timestamp 111 | stability](https://doi.org/10.1145/3447786.3456236). *Proceedings of the 112 | Sixteenth European Conference on Computer Systems*, ACM, 178–193. 113 | 114 | HOCH, E. 2014. Configuration changes. 115 | . 116 | 117 | HOWARD, H. AND ABRAHAM, I. 2020. Raft does not Guarantee Liveness in the 118 | face of Network Faults. 119 | . 120 | 121 | [IEEE 896.1-1991 IEEE STANDARD FOR FUTUREBUS+(R) – LOGICAL PROTOCOL 122 | SPECIFICATION](https://standards.ieee.org/ieee/896.1/1269/). 1992. 123 | 124 | IMBS, D. AND RAYNAL, M. 2010. Software transactional memories: 125 | An approach for multicore programming. *The journal of supercomputing*. 126 | 127 | JENSEN, C., HOWARD, H., AND MORTIER, R. 2021. [Examining Raft’s 128 | behaviour during partial network 129 | failures](https://doi.org/10.1145/3447851.3458739). *Proceedings of the 130 | 1st Workshop on High Availability and Observability of Cloud Systems*, 131 | Association for Computing Machinery, 11–17. 132 | 133 | KOŃCZAK, J., SOUSA SANTOS, N.F. DE, ŻURKOWSKI, T., WOJCIECHOWSKI, P.T., 134 | AND SCHIPER, A. 2011. *JPaxos: State machine replication based on the 135 | Paxos protocol*. 136 | 137 | KOTLA, R., ALVISI, L., DAHLIN, M., CLEMENT, A., AND WONG, E. 2007. 138 | [Zyzzyva: Speculative byzantine fault 139 | tolerance](https://doi.org/10.1145/1323293.1294267). *SIGOPS Oper. Syst. 140 | Rev.* *41*, 6, 45–58. 141 | 142 | KOTLA, R., ALVISI, L., DAHLIN, M., CLEMENT, A., AND WONG, E. 2010. 143 | [Zyzzyva: Speculative byzantine fault 144 | tolerance](https://doi.org/10.1145/1658357.1658358). *ACM Trans. Comput. 145 | Syst.* *27*, 4. 146 | 147 | LAMPORT, L. 2005. *[Generalized Consensus and 148 | Paxos](https://www.microsoft.com/en-us/research/publication/generalized-consensus-and-paxos/)*. 149 | Microsoft Research. 150 | 151 | LIBEN-NOWELL, D., BALAKRISHNAN, H., AND KARGER, D. 2002. [Analysis of 152 | the evolution of peer-to-peer 153 | systems](https://doi.org/10.1145/571825.571863). *Proceedings of the 154 | twenty-first annual symposium on principles of distributed computing*, 155 | Association for Computing Machinery, 233–242. 156 | 157 | LISKOV, B. AND COWLING, J. 2012. *Viewstamped Replication Revisited*. 158 | 159 | MARTIN, J.-P. AND ALVISI, L. 2005. [Fast Byzantine 160 | Consensus](https://doi.org/10.1109/DSN.2005.48). *2005 International 161 | Conference on Dependable Systems and Networks (DSN’05)*, 402–411. 162 | 163 | MARTIN, J.-P. AND ALVISI, L. 2006. [Fast Byzantine 164 | Consensus](http://dx.doi.org.libproxy1.nus.edu.sg/10.1109/TDSC.2006.35). 165 | *IEEE Transactions on Dependable and Secure Computing* *3*, 3, 202–215. 166 | 167 | MICHAEL, E., PORTS, D.R.K., SHARMA, N.K., AND SZEKERES, A. 2017. 168 | Recovering Shared Objects Without Stable Storage. 27. 169 | 170 | MOMOSE, A. AND CRUZ, J.P. 2019. *[Force-Locking Attack on Sync 171 | Hotstuff](http://eprint.iacr.org/2019/1484)*. 172 | 173 | MORARU, I., ANDERSEN, D.G., AND KAMINSKY, M. 2013. [There is more 174 | consensus in Egalitarian 175 | parliaments](https://doi.org/10.1145/2517349.2517350). *Proceedings of 176 | the Twenty-Fourth ACM Symposium on Operating Systems Principles*, 177 | Association for Computing Machinery, 358–372. 178 | 179 | NAWAB, F., AGRAWAL, D., AND EL ABBADI, A. 2018. [DPaxos: Managing Data 180 | Closer to Users for Low-Latency and Mobile 181 | Applications](https://doi.org/10.1145/3183713.3196928). *Proceedings of 182 | the 2018 International Conference on Management of Data*, Association 183 | for Computing Machinery, 1221–1236. 184 | 185 | NEU, J., TAS, E.N., AND TSE, D. 2021. [Ebb-and-Flow Protocols: A 186 | Resolution of the Availability-Finality 187 | Dilemma](http://arxiv.org/abs/2009.04987). *arXiv:2009.04987 \[cs\]*. 188 | 189 | ONGARO, D. 2014. Consensus: Bridging theory and practice. 190 | 191 | ONGARO, D. 2015. Bug in single-server membership changes. 192 | . 193 | 194 | ONGARO, D. AND OUSTERHOUT, J. 2014. In search of an understandable 195 | consensus algorithm. *Proceedings of the 2014 USENIX conference on 196 | USENIX annual technical conference*, USENIX Association, 305–320. 197 | 198 | ROWSTRON, A. AND DRUSCHEL, P. 2001. [Pastry: Scalable, Decentralized 199 | Object Location, and Routing for Large-Scale Peer-to-Peer 200 | Systems](https://doi.org/10.1007/3-540-45518-3_18). *Middleware 2001*, 201 | Springer, 329–350. 202 | 203 | SHRESTHA, N., KUMAR, M., AND DUAN, S. 2019. [Revisiting hBFT: 204 | Speculative Byzantine Fault Tolerance with Minimum 205 | Cost](http://arxiv.org/abs/1902.08505). *arXiv:1902.08505 \[cs\]*. 206 | 207 | STOICA, I., MORRIS, R., KARGER, D., KAASHOEK, M.F., AND BALAKRISHNAN, H. 208 | 2001. [Chord: A scalable peer-to-peer lookup service for internet 209 | applications](https://doi.org/10.1145/964723.383071). *SIGCOMM Comput. 210 | Commun. Rev.* *31*, 4, 149–160. 211 | 212 | SUTRA, P. 2020. [On the correctness of Egalitarian 213 | Paxos](https://doi.org/10.1016/j.ipl.2019.105901). *Information 214 | Processing Letters* *156*. 215 | 216 | SUTRA, P. AND SHAPIRO, M. 2010. *[Fast Genuine Generalized 217 | Consensus](https://drive.google.com/open?id=0BwFkGepvBDQoRjNYRGJTdWQ0SzA)*. 218 | 219 | TERRACE, J. AND FREEDMAN, M.J. 2009. [Object Storage on {CRAQ}: 220 | High-Throughput Chain Replication for Read-Mostly 221 | Workloads](https://www.usenix.org/conference/usenix-09/object-storage-craq-high-throughput-chain-replication-read-mostly-workloads). 222 | 223 | WHITTAKER, M. 2020. CRAQ Bug. . 224 | 225 | WHITTAKER, M. 2021. EPaxos Dependency Set Compaction Bug. 226 | . 227 | 228 | WHITTAKER, M., HELLERSTEIN, J.M., GIRIDHARAN, N., SZEKERES, A., HOWARD, 229 | H., AND NAWAB, F. 2021. Matchmaker Paxos: A Reconfigurable Consensus 230 | Protocol. *Journal of Systems Research*, 22. 231 | 232 | ZAVE, P. 2012. [Using lightweight modeling to understand 233 | chord](https://doi.org/10.1145/2185376.2185383). *ACM SIGCOMM Computer 234 | Communication Review* *42*, 2, 49–57. 235 | 236 | ZAVE, P. 2017. [Reasoning About Identifier Spaces: How to Make Chord 237 | Correct](https://doi.org/10.1109/TSE.2017.2655056). *IEEE Transactions 238 | on Software Engineering* *43*, 12, 1144–1156. 239 | 240 | [^1]: With the read-only optimisation. 241 | 242 | [^2]: Eventual reachability is Chord’s key correctness property. 243 | 244 | [^3]: Acceptors might accept commands that have not been proposed. 245 | 246 | [^4]: As described in Paxos Made Live. 247 | 248 | [^5]: Client reads might fail due to incorrect garbage collection. 249 | 250 | [^6]: The joint consensus membership change algorithm described in the 251 | paper version of Raft had a liveness bug, which was fixed in 252 | Ongaro’s PhD thesis. 253 | 254 | [^7]: The bug is in the single-server membership change scheme described 255 | in Ongaro’s thesis. 256 | -------------------------------------------------------------------------------- /table.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/dranov/protocol-bugs-list/e69048559f81a090cc74a3e0602cc05a132c6f05/table.pdf -------------------------------------------------------------------------------- /table.tex: -------------------------------------------------------------------------------- 1 | \documentclass{article} 2 | \usepackage[utf8]{inputenc} 3 | \usepackage[T2A]{fontenc} 4 | \usepackage[main=english, russian]{babel} 5 | \usepackage{booktabs} 6 | \usepackage{footnote} 7 | \usepackage{xcolor} 8 | \makesavenoteenv{tabular} 9 | \usepackage[backend=biber, style=alphabetic, sorting=nyt, urldate=iso]{biblatex} 10 | \addbibresource{bibliography.bib} 11 | \usepackage[hidelinks]{hyperref} 12 | 13 | \title{Errors found in distributed protocols} 14 | \date{} 15 | \begin{document} 16 | 17 | \maketitle 18 | 19 | % To make it easier to filter output in table.md 20 | \begin{center} 21 | {\footnotesize \color{white} (begin table)} 22 | \end{center} 23 | 24 | \begin{center} 25 | \begin{tabular}{ c c c c } 26 | \toprule 27 | Protocol & Reference & Violation & Counter-example \\ 28 | \midrule 29 | 30 | PBFT\footnote{With the read-only optimisation.} & 31 | \cite{castroPracticalByzantineFault1999} & liveness & 32 | \cite{bergerMakingReadsBFT2021} \\ 33 | 34 | Chord & \cite{stoicaChordScalablePeertopeer2001, 35 | liben-nowellAnalysisEvolutionPeertopeer2002} & 36 | liveness\footnote{Eventual reachability is Chord's key 37 | correctness property.} & \cite{zaveUsingLightweightModeling2012, 38 | zaveReasoningIdentifierSpaces2017} \\ 39 | 40 | Pastry & \cite{rowstronPastryScalableDecentralized2001} & safety & 41 | \cite{azmyRigorousCorrectnessProof2016, azmyMachinecheckedCorrectnessProof2018}\\ 42 | 43 | Generalised Paxos & \cite{lamportGeneralizedConsensusPaxos2005} & 44 | non-triviality\footnote{Acceptors might accept commands that have not been 45 | proposed.} & \cite{sutraFastGenuineGeneralized2010} \\ 46 | 47 | FaB Paxos & \cite{martinFastByzantineConsensus2005, 48 | martinFastByzantineConsensus2006} & liveness & 49 | \cite{abrahamRevisitingFastPractical2017} \\ 50 | 51 | Multi-Paxos\footnote{As described in Paxos Made Live.} & 52 | \cite{chandraPaxosMadeLive2007} & safety & 53 | \cite{michaelRecoveringSharedObjects2017} \\ 54 | 55 | Zyzzyva & \cite{kotlaZyzzyvaSpeculativeByzantine2007, 56 | kotlaZyzzyvaSpeculativeByzantine2009} & safety & 57 | \cite{abrahamRevisitingFastPractical2017} \\ 58 | 59 | CRAQ & \cite{terraceObjectStorageCRAQ2009} & safety\footnote{Client reads 60 | might fail due to incorrect garbage collection.} & 61 | \cite{whittakerCRAQBug2020} \\ 62 | 63 | JPaxos & \cite{konczakJPaxosStateMachine2011} & safety & 64 | \cite{michaelRecoveringSharedObjects2017} \\ 65 | 66 | VR Revisited & \cite{liskovViewstampedReplicationRevisited2012} & safety & 67 | \cite{michaelRecoveringSharedObjects2017} \\ 68 | 69 | EPaxos & \cite{moraruThereMoreConsensus2013} & safety & 70 | \cite{sutraCorrectnessEgalitarianPaxos2020} \\ 71 | 72 | EPaxos & \cite{moraruThereMoreConsensus2013} & safety & 73 | \cite{whittakerEPaxosDependencySet2021} \\ 74 | 75 | Raft & \cite{ongaroSearchUnderstandableConsensus2014} & 76 | liveness\footnote{The joint consensus membership change algorithm described 77 | in the paper version of Raft had a liveness bug, which was fixed in 78 | Ongaro's PhD thesis.} & \cite{hochConfigurationChanges2014} \\ 79 | 80 | Raft & \cite{ongaroConsensusBridgingTheory2014} & safety\footnote{The bug 81 | is in the single-server membership change scheme described in Ongaro's 82 | thesis.} & \cite{amos15812TermPaper2015, 83 | ongaroBugSingleserverMembership2015} \\ 84 | 85 | Raft & \cite{ongaroSearchUnderstandableConsensus2014, 86 | ongaroConsensusBridgingTheory2014} & liveness & 87 | \cite{howardRaftDoesNot2020, jensenExaminingRaftBehaviour2021} \\ 88 | 89 | hBFT & \cite{duanHBFTSpeculativeByzantine2015} & safety & 90 | \cite{shresthaRevisitingHBFTSpeculative2019} \\ 91 | 92 | Tendermint & \cite{buchmanTendermintByzantineFault2016} & liveness & 93 | \cite{cachinBlockchainConsensusProtocols2017} \\ 94 | 95 | CAESAR & \cite{arunSpeedingConsensusChasing2017} & liveness & 96 | \cite{enesEfficientReplicationTimestamp2021} \\ 97 | 98 | DPaxos & \cite{nawabDPaxosManagingData2018} & safety & 99 | \cite{whittakerMatchmakerPaxosReconfigurable2021} \\ 100 | 101 | Sync HotStuff & \cite{abrahamSyncHotStuffSimple2019} & safety \& liveness & 102 | \cite{momoseForceLockingAttackSync2019} \\ 103 | 104 | Gasper & \cite{buterinCombiningGHOSTCasper2020} & safety \& liveness & 105 | \cite{neuEbbandFlowProtocolsResolution2021} \\ 106 | 107 | STM & \cite{Imbs2011} & safety \& liveness & 108 | \cite{Belyaev2010} \\ 109 | 110 | FutureBus+ & \cite{IEEE8961Futurebus} & safety \& liveness & 111 | \cite{ClarkeGHJLMN93} \\ 112 | 113 | \bottomrule 114 | \end{tabular} 115 | \end{center} 116 | 117 | % To make it easier to filter output in table.md 118 | \begin{center} 119 | {\footnotesize \color{white} (end table)} 120 | \end{center} 121 | 122 | \newpage 123 | \printbibliography 124 | 125 | \end{document} 126 | --------------------------------------------------------------------------------