# A MILP Model for a Byzantine Fault Tolerant Blockchain Consensus
## 4 Computational Experiments
### Ensuring Packages Delivery  
Some additional set of constraints were used in MILP variants, in order to analyze how the model would behave for extreme scenarios. In this sense, Equation (31) can be created for the following pairs \((Recv^{+},\ Send^{-})\): **1. **\((PrepReq^{+},\ PrepReq^{-})\); **2. **\((PrepResp^{+},\ PrepRsep^{-})\); **3. **\((Commit^{+},\ Commit^{-})\); and **4. **\((ChView^{+},\ ChView^{-})\). \[\sum_{t\in\mathcal{T}:t>1}Recv^{+}_{t,j,\
u}\geq\sum_{t\in\mathcal{T}:t>1}Send^ {-}_{t,j,\
u}\qquad\qquad\forall i\in\mathcal{R}_{OK},j\in\mathcal{R}_{OK},v \in\mathcal{V} \tag{31}\]  
During experiments, it was observed that by only enabling Property (**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). 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 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. In Figure 3, the primary \(Pr.^{3}\) (Byzantine) _luckily_ sends two successful PrepareRequest messages (in blue) to nodes 0 and 1 (but not 2), and then engages into a successful view change due to Property **(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. In Figure 4, any other Primary of the first round would have made the system relay a block on View 0. However, Byzantine was intrinsically part of the optimal solution (as first speaker) in order to maximize number of messages and number of rounds. Thus, the model was able to prove that liveness cannot be impaired if messages between honest are ensured. Figure 5 graphically indicates the behavior of the Byzantine system on the P1 scenario. It maximizes the delays and blocks (trying to generate sports), still being limited by the three-phase logic of the model (thus only generating a single block after all). The models finds a situation where the first primary \(Pr.^{3}\) is Byzantine, so it does not propose a block and immediately requires a view change. The backup \(Pr.^{2}\) assumes control after a view change, being able to propose a block (Phase I in blue), but unsuccessfully receiving responses in time. Since the delays cannot grow indefinitely (Byzantine agent is computationally bound as described on dBFT and PBFT specification), in the last view, the messages arrive and primary \(Pr.^{1}\) is able to generate a relayed block (Phase 1 in blue, Phase II in green and Phase III in yellow).