Smilo BFT

Elkan Roelen edited this page Aug 17, 2018 · 19 revisions

What is Smilo BFT?

A blockchain is a decentralised system which consist of multiple actors. How each actor acts depends on the information available to them and their incentives. When a new block is broadcasted to the network, each actor has the option to add or reject that block to their copy of the ledger. To achieve a consensus the majority of actors must decide on a single state. In order to achieve consensus, Smilo has created their own Byzantine fault tolerant, secure consensus protocol.

The 2 Generals problem

In 1975 (named "The 2 generals problem" in 1978) SOME CONSTRAINTS AND TRADEOFFS IN THE DESIGN OF NETWORK COMMUNICATIONS from Akkoyunlu, Ekanadham and Huber describes a scenario where two generals attack a common enemy. General 1 is the "Leader" and General 2 is the "Follower". There armies aren't strong enough to attack by themselves. to defeat the common enemy, they have to cooperate and attack at the same time.

When general 1 wants to plan an attack he has to inform General 2. Sending a messenger across camps delivering the time and date is not secure. There is a possibility that the messenger get captured by the enemy and alter or prevent the message from delivering. This will result in a 1 army attack, while General 2 hold their ground.

Even if the message is delivered, General 2 has to confirm (acknowledge) that he received the message, so he responds with a messenger, waiting for an confirmation of the received confirmation. Ending up in an infinite loop of acknowledges where the generals are unable to reach an agreement.

The byzantine Generals problem

In 1982 Lamport, Pease and Shostak published "The Byzantine Generals Problem", an updated "Two generals Problem". Instead of two generals, they described a scenario with more then two generals. Since one or more generals can act as an traitor, this introduces new complications. The first General is now a commander. And all other Generals are degraded to lieutenants.

To achieve consensus, the commander and every lieutenant must agree on the same result. (in this case: retreat or attack)

A commander must send an order to his n-1 lieutenant such that:

1. All loyal lieutenants obey the same order

2. if the commander is loyal, then every loyal lieutenant obeys the order he sends.

Even if the commander is a traitor, all lieutenants must still achieve consensus, taking a majority vote. To result of the consensus is based on the majority of votes the lieutenant observes.

_Theorem: For any m, Algorithm OM(m) reaches consensus if there are more than 3m generals and at most m traitors._

Therefore the actors can reach a consensus when ≥ 2/3 is honest. If ≥ 1/3 of the actors are traitors, the consensus is not reached. No attack is coordinated and the enemy will win this battle.

m = 0 → no traitors, each lieutenant is loyal

m > 0 → each lieutenants final choice comes from the majority of all lieutenants choices

Smilo Byzantine Fault Tolerance with SPoRT (Smilo's Proof of Resources and Time)

Smilo Platform faces the same challenges, and more. Since we are an open platform (permissionless) every Smilo Holder can be a lieutenant or commander. Therefore the Smilo network needs to handle thousands of actors and all of them can be a traitor. As the number of transactions and network size increase, Smilo must be able to scale proportionally. If it cannot scale with demand then transactions will be delayed or never processed at all.

To prevent every single actor communicating with every other actor, we bring structure to the network. And for structure we need rules. Read here more about the network.

Smilo BFT+ with SPoRT

99.9% Consensus

Although we need > 66% consensus with Smilo BFT, a node will never add a block to his chain when DECLINED. Even when > 66% APPROVED (in both networks), and NODE A DECLINED, NODE A will not add the block to his chain, and therefore all followup-blocks neither.

All Smilo Clients (like the API, Full Wallets, etc) are able to verify blocks and transactions too, providing a two-factor authentication for light clients. Clients can validate if it is connected to "Good actors" or "Bad actors", depending on the blockchain hash, and therefore decide to send a transaction to a Good or Bad actor.

Since Smilo BFT Blacklist “Bad actors”, each Bad Actor will become an orphan/bad chain (fork). This makes Smilo 99.9% secure against sibling attacks. A real Sibling attack is therefor only possible with 100% “Bad actors”.


Each block will be generated by the speaker, which will be determined by the Smilo Proof of Resource and Time (SPoRT) protocol. More info on the speaker and the selection of it can be found on the SPoRT page.

In short: The node that had the fastest correct response (who is not within the same two networks as the previous speaker) will become the new speaker and will generate the upcoming block.

See the following block generating process below:

Node A (N2) has won the SPoRT challenge (Started by N1) and can generate the next block

  • The Block is generated, signed and broadcasted to all peers in the first network (N2: B, C)
    • B and C verify Block and broadcast result to network 2 (N2).
      • A broadcasted the Block, only node approved/generated Blocks are broadcasted.
      • B broadcasts result to A,C
      • C broadcasts result to A,B
      • All nodes received the results from all nodes in network N2 (or at least 2/3 of the results, if all results are valid)
        • result: ≥ 2/3 valid
          • Block is valid in first network
          • Broadcast to second network
            • if second network is valid
              • Block is approved
            • if second network is invalid, verify block again
              • if valid, disconnect and blacklist from nodes that reject blocks (You or them are an Attacker, damaged or defect!) The nodes in the second network that approved will also blacklist the rejecting nodes. Result in a split: A new network with blacklisted nodes. Bad/defect actors will become orphans.
        • result: < 2/3 valid
          • node A broadcasted invalid block
            • Blacklist node
            • Disconnect node from network?
        • Network start new SPoRT challenge


The block will be generated by the speaker, signed and broadcasted to all the peers in the first network. The speaker will COMMIT the block to the network. The speaker (just like every other node) is connected to two networks directly. One network will verify the block and broadcast the result to the second network.


If the first network verifies the block, then the same block will be broadcasted to the second network. If the second network also verifies the block, then the block is APPROVED.


The block can be DECLINED (aka invalid) if:

  • A node tampered with the block, this results in invalid hash and/or signature
  • There are invalid transactions in the block, the block generating node is corrupt
  • A node can blacklist another node.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.