BFT in Blockchains: Protocols & Use Cases
This presentation delves into the world of Byzantine Fault Tolerance (BFT) in blockchains, exploring various protocols, system settings, smart contracts, atomic broadcast agreements, traditional measures, and parallel BFT approaches. The content covers topics like asynchronous timing, fault models, computational thresholds, token limits, malicious schedulers, throughput, latency, message complexity, server and client scalability, and parallel transaction confirmation techniques. Learn about the fundamentals and practical applications of BFT in blockchain technology.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
BFT in Blockchains: From Protocols to Use Cases Authors: Xin Wang, Sisi Duan, James Clavin, and Haibin Presentation by Joseph Oglio
System Settings Timing Asynchronous no bound on message delivery Partially Asynchronous an unknown bound on message delivery Synchronous a known bound on message deliver Fault Model Threshold f faults say < n/2 Computational Threshold threshold on the computational power of the adversary Token Threshold limit on the number of tokens the adversary may control Malicious Scheduler delvers messages in a particular order
Smart Contracts Small programs that can be written by any client and that are deployed to the blockchain in the form of a transaction These contracts contain functions that can be called by users to update the smart contract, who will then submit a transaction to the system After confirming the transaction, replicas then execute the smart contract s requirements accordingly and return the result to the clients
Atomic Broadcast Agreement. If a correct replica delivers a transaction m, then every correct replica delivers m. Total Order. If a correct replica delivers transaction m1 before m2, then any other correct replica delivers m1 before m2. Liveness. If a transaction is submitted to a sufficient number of correct replicas, then all correct replicas eventually deliver m.
Traditional Measures Throughput tx/s Latency time from tx creation to client reply Message Complexity number of messages sent Communication Complexity total size of the messages sent Server Scalability number of nodes tolerable Client Scalability number of clients tolerable
Parallel BFT CBASE groups transactions that can be confirmed in parallel EVE reach consensus on batches in parallel and resolve conflicting transactions after SAREK no details in the survey but can handle conflicting and non to achieve total order? May be relevant
Scalable BFT Steward hierarchical, leader committee does the ordering and may be replaced if overtaken Mir-BFT partitioned, uses rotating hashes to split up requests to avoid conflict Snowball Gossip instead of broadcast
BFT in an Asynchronous Model Usually uses a cryptographic common coin to achieve agreement with probability 1
BFT in Permissionless Setting Use Proof of Work (PoW) or Proof of Stake (PoS) to overcome sybil attacks These are usually costly algorithms so to overcome that you can: Use a highly forking DAG in an attempt to increase throughput Create a hybrid algorithm
Hybrid Blockchains Bitcoin-NG Mining makes you a leader, you propose many blocks, transaction fee is given to the current and next leader (motivation to mine on the longest chain?) Algorand only peers with enough coins can participate in consensus PeerConsensus PeerConsensus was first but the remaining protocols use PoW to decide who participates in consensus. Additional things are added to them to make them better or unique such as routing schemes, rotations, different BFT algorithms, etc.
Hybrid Downsides Most require coins or related to coins Not many are proven secure Committee sizes can still be too large PoW needs to be synchronous (short delays) to work PoW also needs adversary to have less than half of the comp. power BFT requires a third usually
Use Cases Financials Crypto currency, cross border transactions, documents, anti money laundering, tax fraud Supply chain track food, (all leafy greens in Walmart must be tracked by blockchain), NFT Health Care data management, epidemic tracking Infrastructure power grids, track tourists, government records, identity, student data
