BiniBFT - An Optimized BFT on Fabric

Evaluation 3 - Report

Submitted By: Riddhi Katarki , Ajitesh Kumar Soni , Abhishek Ranjan , Ashna P S , Sahilsher Singh , Siddhant Prateek Mahanayak

Collaborative Learning Program

Engagement Details

Name of Mentee	Riddhi Katarki , Ajitesh Kumar Soni , Abhishek Ranjan , Ashna P S , Sahilsher Singh , Siddhant Prateek Mahanayak
Evaluation Period	08-10-2023 to 13-12-2023
Task	BiniBFT Framework
Date Submitted	14-12-2023
Mentor	Dr. Anasuya Threse Innocent

Consensus Mechanism with Random Polling

Transaction Initiation: The process starts with the client initiating a transaction (Trx initiation). This is where a user or an application requests a transaction to be processed by the network.
Transaction Batching: After a transaction is initiated, it is grouped with other transactions into a batch (Batched trx) which improves the efficiency of processing multiple transactions together rather than individually.
Leader Selection: Once transactions are batched, a leader is selected to propose the batch of transactions to the rest of the network. The leader selection is aided by a Verifiable Random Function (VRF), which helps in choosing the leader in a way that is random but verifiable by other participants in the network.
Transaction Proposal: The leader then proposes the batched transactions (Trx proposal) to the network. This involves sending out the transaction data to other nodes in the network for validation.
Polling: Concurrently, there is a random polling of 33% of the network. This suggests that a subset of the network is selected randomly to vote on the proposed transactions. The chart indicates that the process waits until 1/3 of the votes are received.
Transaction Commitment: Once the leader has successfully proposed the transaction and the necessary votes are received, the transaction is committed (Commit Trx) by the network.
Transaction Settlement: After the transaction is committed, it is then settled (Finalised Trx), which means it is officially recorded on the blockchain. This completes the process, and the client is informed that the transaction has been finalised.

Consensus Mechanism with Time Weighted Voting

Transaction Initiation: A client starts the process by initiating a transaction.
Transaction Batching: Transactions are batched together for processing efficiency.
Leader Selection: A leader is selected through a Verifiable Random Function (VRF) to manage the batched transactions. This ensures randomness and fairness in leader selection.
Transaction Proposal: The selected leader proposes the batched transactions to the network.
Time Weighted Voting (Polling):

The network nodes participate in polling to approve the transaction proposal. This polling uses the Time Weighted Voting mechanism.
Each node in the network has a weight (w) that increases over time or epochs, representing their tenure in the network.

Voting Constraints:

Individual node weight is capped to ensure no single node can dominate the decision due to its longevity (as shown in the second chart, where w(i) <= 0.33 * (network_w)).
The sum of the weights (sum(w)) from the nodes participating in the polling must be greater than or equal to 51% of the total network weight to reach a decision (sum(w) >= (0.51 * network_w)).

Transaction Commitment: If the proposal receives enough weighted votes (>= 51% of network weight), the transaction is committed.
Transaction Settlement: The committed transaction is then finalized and recorded on the blockchain, and the client is notified of the transaction settlement.

Dynamic Leader Allocation Process

System Load Monitoring: Continuously monitor the system's transaction rate, processing capacity, and overall network load.
Load Thresholds: Define load thresholds that trigger dynamic leader allocation. Consider factors such as transaction backlog and processing delays.
Leader Availability: Track the availability and performance metrics of potential leaders in the network.
Allocation Trigger: When the system load surpasses predefined thresholds, initiate dynamic leader allocation based on a Verifiable Random Function (VRF).
VRF-Based Random Leader Selection: Use a Verifiable Random Function to generate a random number that determines the leader selection. This ensures randomness while providing verifiability to other participants.
Batch Queue Management: If a batch queue exists, distribute batches among the selected leaders to ensure an even workload distribution.
Concurrency Control: Implement synchronization protocols to manage interactions between multiple leaders and maintain consistency.
Transaction Proposal: Each leader, determined by the VRF-based random selection, independently proposes its assigned batches to the network for validation.
Polling and Voting: Continue with the random polling and voting process for each proposed batch, ensuring decentralized agreement on transaction validity.
Commitment Decision: Based on the voting outcomes for each leader's proposed batches, make a commitment decision for each batch independently.
Transaction Settlement: Finalise the committed batches and record them on the blockchain.
Leader Deallocation: Periodically reassess the system load. If the load decreases and additional leaders are no longer needed, deallocate the surplus leaders.