BiniBFT - An Optimized BFT on Fabric

Evaluation 1 - Report

Submitted By: Abhishek Ranjan

Collaborative Learning Program

Engagement Details

Tasks, Objectives, and Results

This Evaluation report consolidates the candidate’s work for Hyperledger CLP - BiniBFT project by BiniWorld Innovations Pvt Ltd during the internship (Weeks 1-6). The report has been categorized into two sections: outline the key task assigned to the candidate and day-to-day activities undertaken by the candidate.

Key Outline of the Task assigned to the candidate (This includes Project name, Problem statement, expected Output and other relevant details)

RAFT Implementation

It is the Raft Consensus algorithm Raft implemented in Go.

about Raft Protocol Description

The Raft consensus algorithm is a distributed system protocol designed to achieve consensus among a cluster of nodes in a network. It was introduced as an alternative to the more complex Paxos algorithm, aiming to provide a clearer and more understandable approach to distributed consensus. Raft has gained popularity in the field of distributed systems due to its simplicity and reliability.

Limitations of the Raft Consensus Algorithm:

• Lack of Byzantine Fault Tolerance: Raft is primarily designed to handle benign failures, where nodes fail or behave unpredictably but do not actively maliciously disrupt the network. It does not provide Byzantine Fault Tolerance, making it less suitable for scenarios with potentially malicious nodes.
• Limited Use Cases: While Raft is a reliable choice for many distributed systems, it may not be the best fit for all scenarios. Complex, large-scale, and high-performance distributed systems may require more specialized consensus algorithms.
• Unavoidable Leader Election Delays: Raft relies on leader elections to ensure that the system operates correctly. During leader elections, there can be a delay in processing client requests, which may affect real-time applications that require low-latency responses.

In conclusion, the Raft consensus algorithm offers several advantages, including simplicity, clear leader election, and safety, making it an attractive choice for a wide range of distributed systems. However, it also has its disadvantages and limitations, particularly in terms of performance overhead, flexibility, and scalability. It's important to carefully consider the specific requirements of your distributed system when choosing a consensus algorithm, as no single algorithm is suitable for all use cases.

Implementation

The sample uses a Go module to install the chaincode dependencies. The dependencies are listed in a go.mod file in the asset-transfer-basic/chaincode-go directory. You should take a moment to examine this file.

$ cat go.mod

module github.com/hyperledger/fabric-samples/asset-transfer-basic/chaincode-go

The SmartContract type is then used to create the transaction context for the functions defined within the smart contract that read and write data to the blockchain ledger.

func (s *SmartContract) CreateAsset(ctx contractapi.TransactionContextInterface, id string, color string, size int, owner string, appraisedValue int) error {

    exists, err := s.AssetExists(ctx, id)

    if err != nil {

        return err

    }

    if exists {

        return fmt.Errorf("the asset %s already exists", id)

    }

    asset := Asset{

        ID:             id,

        Color:          color,

        Size:           size,

        Owner:          owner,

        AppraisedValue: appraisedValue,

    }

    assetJSON, err := json.Marshal(asset)

    if err != nil {

        return err

    }

    return ctx.GetStub().PutState(id, assetJSON)

}

The AssetTransfer class provides the transaction context for the functions defined within the smart contract that read and write data to the blockchain ledger.

async CreateAsset(ctx, id, color, size, owner, appraisedValue) {

        const asset = {

            ID: id,

            Color: color,

            Size: size,

            Owner: owner,

            AppraisedValue: appraisedValue,

        };

        await ctx.stub.putState(id, Buffer.from(JSON.stringify(asset)));

    }

The command will produce a JSON map that displays if a channel member has approved the parameters that were specified in the checkcommitreadiness command:

         {

            "Approvals": {

                    "Org1MSP": true,

                    "Org2MSP": true

            }

        }

Output: