# A MILP Model for a Byzantine Fault Tolerant Blockchain Consensus

^{1}

^{2}

^{3}

^{4}

^{5}

^{*}

## Abstract

**:**

**Key Contribution:**This paper introduces a MILP model focusing on exact optimization proofs for consensus systems; explores the inherent challenges of MILP models for practical optimization problems, describing the phases of PBFT algorithm and its adaptations for blockchain; and presents a MILP tool with graphical diagrams to assist large-scale projects, contributing to the byzantine fault tolerant used by public Neo Blockchain.

## 1. Introduction

## 2. Background and Related Work

#### 2.1. Phase I—PrepareRequest

#### 2.2. Phase II—PrepareResponse

#### 2.3. Phase III—Commit

#### 2.4. View Change

#### 2.5. dBFT 2.0 Diagram

## 3. Formulation for the dBFT Consensus

#### 3.1. Sets and General Parameters

- N:
- Number of Nodes, $N=3f+1$.
- f:
- Maximum allowed faulty nodes, $f=(N-1)/3$.
- M:
- Safety level $M=N-f=2f+1$.
- $\mathcal{T}$:
- Set of discretization schedules $\{1,\dots ,{t}^{max}\}$.
- $\mathcal{R}$:
- Set of nodes $\{1,\dots ,N\}$.
- ${\mathcal{R}}_{OK}$:
- Set of honest nodes $\{1,\dots ,M\}$, where ${\mathcal{R}}_{OK}\subset \mathcal{R}$.
- $\mathcal{V}$:
- Set of rounds/views $\{1,\dots ,N\}$.

#### 3.2. Auxiliary and Decision Variables

- $IsPrimar{y}_{i,v}$:
- Binary variable indicates if node $i\in \mathcal{R}$ is primary/speaker node on $v\in \mathcal{V}$; otherwise is backup node.
- $PrepRe{q}_{t,i,v}^{-}$:
- Binary variable indicates if node $i\in \mathcal{R}$ sent a $PrepareRequest$ message at time $t\in \mathcal{T}$ on view $v\in \mathcal{V}$.
- $PrepRe{q}_{t,i,j,v}^{+}$:
- Binary variable indicates if node $i\in \mathcal{R}$ received a $PrepareRequest$ message from node $j\in \mathcal{R}$ time $t\in \mathcal{T}$ on view $v\in \mathcal{V}$.
- $PrepRes{p}_{t,i,v}^{-}$:
- Binary variable indicates if node $i\in \mathcal{R}$ sent a $PrepareResponse$ message at time $t\in \mathcal{T}$ on view $v\in \mathcal{V}$.
- $PrepRes{p}_{t,i,j,v}^{+}$:
- Binary variable indicates if node $i\in \mathcal{R}$ received a $PrepareResponse$ message from node $j\in \mathcal{R}$ time $t\in \mathcal{T}$ on view $v\in \mathcal{V}$.
- $Commi{t}_{t,i,v}^{-}$:
- Binary variable indicates if node $i\in \mathcal{R}$ sent a $Commit$ message at time $t\in \mathcal{T}$ on view $v\in \mathcal{V}$.
- $Commi{t}_{t,i,j,v}^{+}$:
- Binary variable indicates if node $i\in \mathcal{R}$ received a $Commit$ message from node $j\in \mathcal{R}$ time $t\in \mathcal{T}$ on view $v\in \mathcal{V}$.
- $ChVie{w}_{t,i,v}^{-}$:
- Binary variable indicates if node $i\in \mathcal{R}$ sent a $ChangeView$ message at time $t\in \mathcal{T}$ on view $v\in \mathcal{V}$.
- $ChVie{w}_{t,i,j,v}^{+}$:
- Binary variable indicates if node $i\in \mathcal{R}$ received a $ChangeView$ message from node $j\in \mathcal{R}$ time $t\in \mathcal{T}$ on view $v\in \mathcal{V}$.
- $BlockRela{y}_{t,i,v}^{-}$:
- Binary variable indicates if node $i\in \mathcal{R}$ relayed a block at time $t\in \mathcal{T}$ on view $v\in \mathcal{V}$.

- $TotalChVie{w}_{i,v}^{+}$:
- Counts the number of received $ChVie{w}_{t,i,j,v}^{+}$ messages for a node $i\in \mathcal{R}$ on view $v\in \mathcal{V}$.
- $IsBlockRelaye{d}_{v}$:
- Tells if any blocks was relayed at view $v\in \mathcal{V}$;

#### 3.3. Goals to Be Optimized

**1.**${B}^{\prime}$:- Number of blocks relayed considering all views and total simulation time.
**2.**${V}^{\prime}$:- Number of views/rounds effectively used, which is the number of agreed view changes.
**3.**${C}^{\prime}$:- Number of communications, i.e., sent ($PrepRe{q}_{t,i,v}^{-}$, $PrepRes{p}_{t,i,v}^{-}$, $Commi{t}_{t,i,v}^{-}$ and $ChVie{w}_{t,i,v}^{-}$) and received ($PrepRe{q}_{t,i,j,v}^{+}$, $PrepRes{p}_{t,i,j,v}^{+}$, $Commi{t}_{t,i,j,v}^{+}$ and $ChVie{w}_{t,i,j,v}^{+}$) messages.

**1**is to guide if the model should maximize or minimize the numbers of produced blocks. When maximizing, if we want to ensure no sporks, it should be limited to one. When minimizing, the desired value is also to be kept to one, which would result in a conclusion that says that liveness of the model is preserved.

**2**guides the model to finish faster or slower, which would enforce more or fewer rounds, and it need M nodes to agree throughout $ChangeView$ payloads.

**3**brings more chaos to the system by maximizing the number of received message, as well as optionally minimizing it.

#### 3.4. Model Constraints and Blockchain Operational Requirements

#### 3.4.1. Time Zero Constraints

#### 3.4.2. IsPrimary Constraints

#### 3.4.3. Messages/Payloads Constraints

`PrepareResponse`message is only send if PrepareRequest was received in an instant before. A similar behavior is ensured for sending a Commit messages, but with a stricter need of M previous

`PrepareResponse`messages to have been received, as in Equation (9). Analogously, Equation (10) limits this by demanding that, at least, M

`Commit`messages should had been received before relaying a block.

`PrepareRequest`carries Primary’s preparation hash, it also acts as a

`PrepareResponse`for the Primary, as ensured at Equation (14).

#### 3.4.4. Honest Nodes Constraints

`PrepareRequest`when Primary (Equation (18)) and also respond to received messages. Equation (19) has four parameters ($Sen{d}^{-},Rec{v}^{+},Rate,Delta$) which are assigned to the following groups: $(PrepRes{p}^{-},PrepRe{q}^{+},1,0)$, $(Commi{t}^{-},PrepRes{p}^{+},2,-M+1)$ and $(BlockRela{y}^{-},Commi{t}^{+},2,-M+1)$.

`Change View`, ensured at Equations (21) and (22). The first one ensures that only for View 1 (the first view), while Equation (22) has an additional parcel that avoids forcing an honest node to send a Change View if previous view was not active.

`PrepareRequest`,

`PrepareResponse`or

`Commit`. A similar lock is ensured for

`Change View`if the node has the committed in an instant before or relayed a block with $BlockRela{y}^{-}$, which will also block an honest to send anything else. As should be noticed, the second parcel of the equation has a summation that limits $t2$ to be within the limits $1<t2\le t$.

#### 3.4.5. Objective Function and Auxiliary Variables Calculation

## 4. Computational Experiments

#### 4.1. Problem Instance Generation

`python3 dbft2.0_Byz_Liveness.py–maximization –w1 = 1000 –w2 = 100 –w3 = 0 –N = 7 –tMax = 5`, where parameters ${t}^{max}$ and N were iterated. Some characteristics of the generated problems can be seen at Table 1.

**vars**, while binary and integer variables are listed in Columns

**binaries**and

**integers**, respectively. The number of constraints, as well as their respective types (equality or inequality), are also presented on the table. To give an extra insight on the MILP problems generated, non-zero elements in optimization matrix are described in Column

**nzs**.For practical benchmarks and to allow future comparisons, we generated (and published together with generator code) twelve different base problems with several extra variations on weights and optimization directions, where the largest problems are typically much harder to solve due to the massive increase of variables and constraints in the model. Larger time intervals are useful to explore situations where the Byzantine agent (or optimization solver) tries to postpone all activities for the maximum time possible (thus maximizing the delays), while shorter time intervals may reduce execution time and also limit Byzantine ability and may eventually turn the problem infeasible on practice.

#### 4.2. Exploring Minimization and Maximization Optimization Directions

#### 4.3. Initial Experiments with Cbc and Gurobi

#### 4.4. Graphical Visualization

#### 4.5. Ensuring Packages Delivery

**1.**$(PrepRe{q}^{+},$ $PrepRe{q}^{-})$;

**2.**$(PrepRes{p}^{+},\phantom{\rule{3.33333pt}{0ex}}$$PrepRes{p}^{-})$;

**3.**$(Commi{t}^{+},\phantom{\rule{3.33333pt}{0ex}}Commi{t}^{-})$; and

**4.**$(ChVie{w}^{+},\phantom{\rule{3.33333pt}{0ex}}ChVie{w}^{-})$.

**4**) (receives ChView always when ChView is sent) and minimizing ${V}^{\prime}$, all commits will be relayed and lost (Byzantine agent will explore the fact that sent messages are not necessarily received, even for commits). On the other hand, by enabling it together with Property (

**3**), the model can only find N rounds as a minimum (the Byzantine agent explores the fact the MILP model is limited in time, thus leaving required constraints to be satisfied only on last time and not being computed by objective function). Thus, by considering only Property (

**4**), the optimal solution of Case P3 is kept as 100, while enabling Property (

**3**) moves this optimal to 200 because honest nodes would necessarily receive their respective commits on View 1, and then the system needs to have one node isolated and use the Byzantine node potential to pretend being dead on the next view (see Figure 3).

**4**). Node 1 is already committed at View 0, so it cannot agree on a new block for the next views. As time expires for View 0, honest backup ${Pr.}^{0}$ assumes as speaker (with support from nodes 2 and 3) and its new proposal is quickly resolved on View 1. In this case, no block is generated even if commits are received due to Property (

**3**). According to experiments, by enabling all sets of constraints created with Equation (31), i.e., Properties (

**1**)–(

**4**), the optimal value becomes 1100. This happens as it becomes impossible to avoid the generation of a block due to the guarantee of message delivery between honest nodes.

#### 4.6. Detected Problem Solving Limitations

## 5. Conclusions and Future Works

## Author Contributions

## Funding

## Conflicts of Interest

## Abbreviations

1BF | One Block Finality |

BFT | Byzantine Fault Tolerance |

dBFT | Delegated Byzantine Fault Tolerance |

dBFT 1.0 | Delegated Byzantine Fault Tolerance 1.0 |

dBFT 2.0 | Delegated Byzantine Fault Tolerance 2.0 |

DLT | Distributed Ledger Technology |

MILP | Mixed-Integer Linear Programming |

SM | State Machines |

P2P | Peer-to-Peer |

PBFT | Practical Byzantine Fault Tolerance |

PoW | Proof-of-Work |

## References

- Dantzig, G.B. Discrete-variable extremum problems. Oper. Res.
**1957**, 5, 266–288. [Google Scholar] [CrossRef] - Gleixner, A.; Hendel, G.; Gamrath, G.; Achterberg, T.; Bastubbe, M.; Berthold, T.; Christophel, P.M.; Jarck, K.; Koch, T.; Linderoth, J.; et al. MIPLIB 2017: Data-Driven Compilation of the 6th Mixed-Integer Programming Library. 2019. Available online: http://www.optimization-online.org/DB_FILE/2019/07/7285.pdf (accessed on 27 October 2020).
- Jünger, M.; Liebling, T.M.; Naddef, D.; Nemhauser, G.L.; Pulleyblank, W.R.; Reinelt, G.; Rinaldi, G.; Wolsey, L.A. 50 Years of Integer Programming 1958–2008: From the Early Years to the State-of-the-Art; Springer Science & Business Media: Berlin/Heidelberg, Germany, 2009. [Google Scholar]
- Cook, W.J. Pursuit of the Traveling Salesman: Mathematics at the Limits of Computation; Princeton University Press: Princeton, NJ, USA, 2011. [Google Scholar]
- Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. Available online: https://bitcoin.org/bitcoin.pdf (accessed on 27 October 2020).
- Handschuh, H. Encyclopedia of Cryptography and Security; Springer: Boston, MA, USA, 2011; Chapter SHA-0, SHA-1, SHA-2 (Secure Hash Algorithm); pp. 1190–1193. [Google Scholar] [CrossRef]
- Katz, J.; Lindell, Y. Introduction to Modern Cryptography; CRC Press: Boca Raton, FL, USA, 2014. [Google Scholar]
- Buterin, V. Ethereum white paper. GitHub Repos.
**2013**, 1, 1–23. [Google Scholar] - Turing, A.M. On computable numbers, with an application to the Entscheid. J. Math.
**1936**, 58, 5. [Google Scholar] - Hongfei, D.; Zhang, E. NEO: A Distributed Network for the Smart Economy. 2015. Available online: https://www.exodus.io/assets/docs/neo-whitepaper.pdf (accessed on 27 October 2020).
- Castro, M.; Liskov, B. Practical Byzantine fault tolerance. OSDI
**1999**, 99, 173–186. [Google Scholar] - Leslie, L. The part-time parliament. ACM Trans. Comput. Syst.
**1998**, 16, 133–169. [Google Scholar] - Lamport, L.; Shostak, R.; Pease, M. The Byzantine generals problem. ACM Trans. Program. Lang. Syst. (TOPLAS)
**1982**, 4, 382–401. [Google Scholar] [CrossRef][Green Version] - Veronese, G.S.; Correia, M.; Bessani, A.N.; Lung, L.C. Spin one’s wheels? Byzantine fault tolerance with a spinning primary. In Proceedings of the 2009 28th IEEE International Symposium on Reliable Distributed Systems, Niagara Falls, NY, USA, 27–30 September 2009; pp. 135–144. [Google Scholar]
- Coelho, I.; Coelho, V.; Araujo, R.; Wang, Y.Q.; Rhodes, B. Challenges of PBFT-Inspired Consensus for Blockchain and Enhancements over Neo dBFT. Future Internet
**2020**, 12, 129. [Google Scholar] [CrossRef] - Lamport, L. Time, Clocks, and the Ordering of Events in a Distributed System. Commun. ACM
**1978**, 21, 558. [Google Scholar] [CrossRef] - Schneider, F.B. Implementing fault-tolerant services using the state machine approach: A tutorial. ACM Comput. Surv. (CSUR)
**1990**, 22, 299–319. [Google Scholar] [CrossRef] - Araújo, R.P.A.; Coelho, I.M.; Ochi, L.S.; Coelho, V.N. LibBFT: A High-Performance Timed Automata Library Collection for Byzantine Fault Tolerance. In Proceedings of the 2019 31st International Symposium on Computer Architecture and High Performance Computing (SBAC-PAD), Campo Grande, Brazil, 15–18 October 2019; pp. 234–240. [Google Scholar]
- Alur, R.; Dill, D.L. A theory of timed automata. Theor. Comput. Sci.
**1994**, 126, 183–235. [Google Scholar] [CrossRef][Green Version] - Castro, M.; Liskov, B. Practical Byzantine fault tolerance and proactive recovery. ACM Trans. Comput. Syst. (TOCS)
**2002**, 20, 398–461. [Google Scholar] [CrossRef] - Morgenstern, O.; Von Neumann, J. Theory of Games and Economic Behavior; Princeton University Press: Princeton, NJ, USA, 1953. [Google Scholar]
- Winston, W.L. Operations Research: Applications and Algorithms. 1997. Available online: https://itslearningakarmazyan.files.wordpress.com/2015/09/operation-research-aplications-and-algorithms.pdf (accessed on 27 October 2020).
- Zaman, M.A.U.; Hosseinabad, E.R. On the Uses of LP and NLP to Formulate Game Theory Problems: A Brief Review. Tech. Rom. J. Appl. Sci. Technol.
**2020**, 2, 80–86. [Google Scholar] - Barroso, L.A.; Carneiro, R.D.; Granville, S.; Pereira, M.V.; Fampa, M.H. Nash equilibrium in strategic bidding: A binary expansion approach. IEEE Trans. Power Syst.
**2006**, 21, 629–638. [Google Scholar] [CrossRef] - Hesamzadeh, M.R.; Biggar, D.R. Computation of Extremal-Nash Equilibria in a Wholesale Power Market Using a Single-Stage MILP. IEEE Trans. Power Syst.
**2012**, 27, 1706–1707. [Google Scholar] [CrossRef] - Fanzeres, B.; Street, A.; Pozo, D. A Column-and-Constraint Generation Algorithm to Find Nash Equilibrium in Pool-Based Electricity Markets. Electr. Power Syst. Res.
**2020**, 189, 106806. [Google Scholar] [CrossRef] - Coelho, B.N.; Coelho, V.N.; Coelho, I.M.; Ochi, L.S.; Haghnazar, K.R.; Zuidema, D.; Lima, M.S.; da Costa, A.R. A multi-objective green UAV routing problem. Comput. Oper. Res.
**2017**, 88, 306–315. [Google Scholar] [CrossRef] - Coelho, V.N.; Coelho, I.M.; Coelho, B.N.; Cohen, M.W.; Reis, A.J.; Silva, S.M.; Souza, M.J.; Fleming, P.J.; Guimarães, F.G. Multi-objective energy storage power dispatching using plug-in vehicles in a smart-microgrid. Renew. Energy
**2016**, 89, 730–742. [Google Scholar] [CrossRef][Green Version] - Santos, H.G.; Toffolo, T. Python-MIP Online Documentation. 2020. Available online: https://python-mip.readthedocs.io/en/latest/ (accessed on 27 October 2020).
- Fourer, R.; Gay, D.M.; Kernighan, B.W. AMPL: A Mathematical Programming Language. 1987. Available online: https://ampl.com/REFS/amplmod.pdf (accessed on 27 October 2020).
- Glover, F.W.; Kochenberger, G.A. Handbook of Metaheuristics; Springer Science & Business Media: Berlin/Heidelberg, Germany, 2006; Volume 57. [Google Scholar]

**Figure 2.**Scenario $P6$ with $N=4$ and ${t}^{max}=10$ (block is quickly generated). Messages are so much minimized that speaker does not waste its commit (just marked as an empty circle), avoiding the computation of an extra message to be delivered.

**Figure 3.**Scenario P3 with $N=4$ and message reception Properties (

**3**) and (

**4**). Optimal value is 200, due to double views (no block is ever generated).

**Figure 4.**Scenario P7 with $N=4$ and message reception with all Properties (

**1**)–(

**4**). Optimal value is 707, a block is generated and byzantine was only able to delay the liveness for a single round.

**Figure 5.**Scenario $P1$ with $N=4$ and ${t}^{max}=10$ (block is generated in last view). Optimal value of 1400 is found.

Instance | N | ${\mathit{t}}^{\mathbf{max}}$ | Vars | Binaries | Integers | Const. | Equa. | Ineq. | Nzs |
---|---|---|---|---|---|---|---|---|---|

dbft-2-4-5 | 4 | 5 | 1722 | 1700 | 22 | 2838 | 611 | 2227 | 11,708 |

dbft-2-4-10 | 4 | 10 | 3402 | 3380 | 22 | 5238 | 931 | 4307 | 36,233 |

dbft-2-4-15 | 4 | 15 | 5082 | 5060 | 22 | 7638 | 1251 | 6387 | 72,758 |

dbft-2-7-5 | 7 | 5 | 8196 | 8141 | 55 | 12,745 | 2453 | 10,292 | 55,871 |

dbft-2-7-10 | 7 | 10 | 16,281 | 16,226 | 55 | 23,700 | 3433 | 20,267 | 177,571 |

dbft-2-7-15 | 7 | 15 | 24,366 | 24,311 | 55 | 34,655 | 4413 | 30,242 | 361,396 |

dbft-2-10-5 | 10 | 5 | 22,716 | 22,610 | 106 | 34,358 | 6203 | 28,155 | 154,982 |

dbft-2-10-15 | 10 | 15 | 67,716 | 67,610 | 106 | 93,958 | 10,203 | 83,755 | 1,021,962 |

dbft-2-10-25 | 10 | 25 | 112,716 | 112,610 | 106 | 153,558 | 14,203 | 139,355 | 2,604,942 |

dbft-2-16-5 | 16 | 5 | 88,854 | 88,592 | 262 | 130,846 | 22,019 | 108,827 | 606,716 |

dbft-2-16-25 | 16 | 25 | 442,134 | 441,872 | 262 | 589,086 | 42,499 | 546,587 | 10,450,216 |

dbft-2-19-25 | 19 | 25 | 731,772 | 731,405 | 367 | 969,093 | 64,261 | 904,832 | 17,405,223 |

ID (Direction) | ${\mathit{\omega}}_{1}$ | ${\mathit{\omega}}_{2}$ | ${\mathit{\omega}}_{3}$ | Expected Optimal Solution |
---|---|---|---|---|

P1 (Maximize) | 1000 | 100 | 0 | 1400, for $N=4$, and 1700 for $N=4$, as the consensus will find a single block and finish in the last available view N of the simulation. |

P2 (Maximize) | 1000 | $-100$ | 0 | 900 for any problem instance, the consensus will find no double blocks and finish in the first view. |

P3 (Minimize) | 1000 | 100 | 0 | As default, optimal will be 100, since messages are not ensured to be delivered (no block is generated). In the next sections/experiments we explore some extended P3 scenarios where distinct optimal values can be obtained, considering the additional constraints described at Section 4.5. |

P4 (Minimize) | 1000 | 100 | $-1$ | The behavior is similar to P3, but with the conflicting intention to maximize the number of messages (minimizing a negative factor yields a maximization behavior). Thus, this problem becomes some hybrid min-max, where the variation of weights produce distinct optimal values (with distinct view numbers). |

P5 (Maximize) | 1000 | 100 | 1 | Same result as P1, however generating a message flood over the network. |

P6 (Maximize) | 1000 | −100 | $-1$ | Minimizes number of messages and number of rounds. |

P7 (Minimize) | 1000 | −100 | $-1$ | Maximizes number of messages and number of rounds. |

Instance | N | ${\mathit{t}}^{\mathbf{max}}$ | Optimal |
---|---|---|---|

dbft-2-4-5 | 4 | 5 | yes |

dbft-2-4-10 | 4 | 10 | yes |

dbft-2-4-15 | 4 | 15 | yes |

dbft-2-7-5 | 7 | 5 | yes |

dbft-2-7-10 | 7 | 10 | yes |

dbft-2-7-15 | 7 | 15 | yes |

dbft-2-10-5 | 10 | 5 | no |

dbft-2-10-15 | 10 | 15 | no |

dbft-2-10-25 | 10 | 25 | no |

dbft-2-16-5 | 16 | 5 | no |

dbft-2-16-25 | 16 | 25 | no |

dbft-2-19-25 | 19 | 25 | no |

Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. |

© 2020 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Nazário Coelho, V.; Pereira Araújo, R.; Gambini Santos, H.; Yong Qiang, W.; Machado Coelho, I. A MILP Model for a Byzantine Fault Tolerant Blockchain Consensus. *Future Internet* **2020**, *12*, 185.
https://doi.org/10.3390/fi12110185

**AMA Style**

Nazário Coelho V, Pereira Araújo R, Gambini Santos H, Yong Qiang W, Machado Coelho I. A MILP Model for a Byzantine Fault Tolerant Blockchain Consensus. *Future Internet*. 2020; 12(11):185.
https://doi.org/10.3390/fi12110185

**Chicago/Turabian Style**

Nazário Coelho, Vitor, Rodolfo Pereira Araújo, Haroldo Gambini Santos, Wang Yong Qiang, and Igor Machado Coelho. 2020. "A MILP Model for a Byzantine Fault Tolerant Blockchain Consensus" *Future Internet* 12, no. 11: 185.
https://doi.org/10.3390/fi12110185