Created March 3, 2022

The Raft Consensus Algorithm on C1100

An RTL kernel to accelerate the Hyperledger fabric. FPGA parallelized implementation of the blockchain's consensus algorithm RAFT.

Things used in this project

Hardware components

AMD Varium C1100 Blockchain Accelerator Card

Software apps and online services

AMD Vivado Design Suite

AMD Vitis Unified Software Platform

Story

idea

With the advent of virtual currency, blockchain technology came into being. Blockchain technology has the characteristics of decentralization, high reliability, and transaction transparency. Now its application is not limited to the financial industry. The use of blockchain technology can solve the problems of difficult supervision, difficult operation and low management efficiency of the carbon trading system. By analyzing the business mechanism and main stakeholders of the national carbon trading system based on blockchain, analyze the six-layer blockchain core technology framework and five-step implementation process of the carbon trading model, and construct the "enterprise trading + government" supervision" + the first Three-party audit + financial risk prevention" blockchain carbon trading model, and finally realize the consensus interconnection algorithm of carbon trading blockchain on FPGA. Among the many open source projects, hyperledger fabric is the most popular one. Its original design is aimed at enterprise-level applications. For other popular distributed ledger systems or blockchain platforms on the market, Hyperledger Fabric has many different features and application fields.

solution

The project plans to use the xilinx varium c1100 board to optimize the fabric's consensus algorithm RAFT. The ultimate goal is to arrange the RAFT algorithm on the C1100 board to make it run in parallel.

Hyperledger Fabric

The Linux Foundation created the Hyperledger project in 2015 to advance blockchain technology across industries. Like other blockchain technologies, it has a ledger, using smart contracts, a system for participants to manage transactions. What differentiates Hyperledger Fabric from other blockchain systems is that it is private and permissioned. Unlike open permissionless systems that allow unknown identities to participate in the network (requiring protocols such as "Proof of Work" to validate transactions and secure the network), Hyperledger Fabric Members of the network need to register from a trusted Membership Service Provider (MSP). Hyperledger Fabric also provides the ability to create channels, allowing a group of participants to create their own transaction ledger. For some networks, this is a particularly important choice. In these networks, some participants may be competitors and do not want every transaction they make to be known to every participant, e.g. they only offer special prices to some participants and not others. If two participants form a channel, only those two participants have a copy of the channel's ledger, and the other participants do not.

We initially created a fabric network with fewer nodes as the host computer of the project. The steps of creation are as follows:

step1. Prepare the network environment

1.1 Prepare certificate documents

Create a project root directory, create a folder named fixtures in this directory to store our network-related configuration files, and create a file named crypto-config.yaml in the folder

1.2 Prepare the channel file

Create a file named configtx.yaml under the fixtures path

To generate a genesis block file, use the following command to get a file genesis.block in the channel-artifacts directory of the current directory.

To generate a channel file, use the following command to get a file channel.tx in the channel-artifacts directory of the current directory.

To generate an Org-anchors update file, use the following command to get a file Org1MSPanchors.tx in the channel-artifacts directory of the current directory.

To generate an update file for the second anchor node of the organization, use the following command to get a file Org2MSPanchors.tx in the channel-artifacts directory of the current directory.

Step2. Prepare the docker-compose file

Create a file named docker-compose.yaml under the fixtures path, and use the docker-compose method to deploy the environment, so then we can configure the docker-compose yaml file to start the Fabric Docker environment smoothly .

Step3. the configuration file config.yaml

The client uses the sdk to interact with the fabric network, and needs to tell the sdk two types of information:

Who am I: Information about the current client, including the organization, the path to the key and certificate files, etc. This is information specific to each client.

Who is the counterparty: that is, the information of the fabric network structure, how the channel, org, orderer, and peer are combined to form the current fabric network. These structure information should be consistent with those in configytx.yaml. This is a common configuration that every client can use. In addition, this part of the information does not need to be the complete fabric network information. If the current client only interacts with some nodes, the configuration file only needs to contain the used network information.

include:

1. Statement

2. Client part

3. Channel section

4. Organization Section

5. Sort Node Section

6. Peer node section

7. CA section

8. EntityMatchers section

Step4. initialize and join the channel

RAFT

In distributed systems, consensus algorithms are crucial. Among all consensus algorithms, Paxos is the most famous. It was proposed by Leslie Lamport in 1990. It is a consensus algorithm based on message passing and is considered to be the most efficient among similar algorithms.

Raft is an algorithm that implements distributed consensus and is mainly used to manage the consistency of log replication. It has the same function as Paxos, but compared to Paxos, the Raft algorithm is easier to understand and easier to apply to actual systems. The Raft algorithm is also a consensus algorithm adopted by the alliance chain.

Raft role

According to the official documentation, a Raft cluster contains several nodes. Raft divides these nodes into three states: Leader, Follower, and Candidate. Each state is responsible for different tasks. Under normal circumstances, the nodes in the cluster only have two states: Leader and Follower.

• Leader: Responsible for the synchronization management of logs, processing requests from clients, and maintaining heartBeat contact with Followers;

• Follower: responds to the Leader's log synchronization request, responds to the Candidate's invitation request, and forwards (redirects) the client's request to the Follower's transaction to the Leader;

• Candidate: Responsible for election voting. When the cluster is just started or the leader is down, the node whose status is Follower will be converted to Candidate and initiate an election. After winning the election (more than half of the nodes' votes), the node will be converted from Candidate to Leader condition.

How Raft Works

The Raft algorithm can be divided into the following three parts:

1. Leader Election

(1) At the beginning, all nodes are started with the role of Follower, and the election timer is started at the same time (random time, reducing the probability of conflict)

(2) If a node finds that it has not received the heartbeat request sent by the Leader after the election timer expires, the node will become a candidate and will remain in this state until one of the following three situations occurs:

The node (Candidate) wins the election

Other nodes win the election

After a period of time, no server wins the election (enter the next round of Term election, and randomly set the election timer time)

(3) The candidate will then send a Request Vote to other nodes, and if it is approved by more than half of the nodes, it will become a Leader (Leader). If the election times out and no leader has been elected, the next term will be entered and a new election will take place.

(4) After the leader election is completed, the leader will periodically send heartbeat packets to other nodes to tell other nodes that the leader is still running, and reset the election timers of these nodes.

2. Log Replication

(1) The client submits an instruction (eg: SET 5) to the leader. After the leader receives the command, it appends the command to the local log. At this point, the command is in the "uncomitted" state and the replication state machine will not execute the command.

（2) Then, the Leader concurrently copies the command (SET 5) to other nodes, and waits for other nodes to write the command to the log. If some nodes fail or are slow at this time, the Leader node will keep retrying until all nodes are known. Both save the command to the log. After that, the Leader node submits the command (that is, the command is executed by the state machine, here: SET 5), and returns the result to the Client node.

(3) After the leader node submits the command, the next heartbeat packet will contain a message notifying other nodes to submit the command. After other nodes receive the leader's message, they will apply the command to the state machine (State Machine), and finally The logs of each node are kept consistent.

RTL KERNEL

Due to the epidemic, we did not have much time to debug the project. We completed the design of the RTL KERNEL and the design of the host computer based on the X86 CPU, but the joint debugging has not been completed, and we will continue to complete the project in the future. We designed the consensus algorithm RAFT that comes with the fabric as RTL KERNEL.

logic schematic

We correspond the functions of RAFT into 8 modules as shown in the figure. RX_RAM is responsible for receiving signals from the host computer and node, and forwarding them to the TERM counter. The TERM counter completes the TERM judgment logic, and then forwards the signal to the corresponding identity. The node_state module is responsible for judging the current identity of the node, and a gated clock controls which logical module corresponding to the identity works, and the election module is in the Candidate identity module. Finally, the sent data is packaged and sent through the TX_RAM module.

node_state

The overall RTL KERNEL comprehensive results are as follows:

The planing diagram is as follows：

result

At present, the basic functions of RAFT and fabric can be realized. In the future, we will complete the communication between RTL KERNEL and fabric according to the AXI bus protocol, and further try to increase the throughput of the system and accelerate the processing efficiency of the system.

Code

package main

import (
	"fmt"
	"fabric-go-sdk/sdkInit"
	"os"
)

const (
	cc_name = "simplecc"
	cc_version = "1.0.0"
)

var App sdkInit.Application
func main() {
	// init orgs information

	orgs := []*sdkInit.OrgInfo{
		{
			OrgAdminUser:  "Admin",
			OrgName:       "Org1",
			OrgMspId:      "Org1MSP",
			OrgUser:       "User1",
			OrgPeerNum:    2,
			OrgAnchorFile: "/root/go/src/fabric-go-sdk/fixtures/channel-artifacts/Org1MSPanchors.tx",
		},
	}

	// init sdk env info
	info := sdkInit.SdkEnvInfo{
		ChannelID:        "mychannel",
		ChannelConfig:    "/root/go/src/fabric-go-sdk/fixtures/channel-artifacts/channel.tx",
		Orgs:             orgs,
		OrdererAdminUser: "Admin",
		OrdererOrgName:   "OrdererOrg",
		OrdererEndpoint:  "orderer.example.com",
		ChaincodeID:      cc_name,
		ChaincodePath:    "/root/go/src/fabric-go-sdk/chaincode/",
		ChaincodeVersion: cc_version,
	}

	// sdk setup
	sdk, err := sdkInit.Setup("config.yaml", &info)
	if err != nil {
		fmt.Println(">> SDK setup error:", err)
		os.Exit(-1)
	}

	// create channel and join
	if err := sdkInit.CreateAndJoinChannel(&info); err != nil {
		fmt.Println(">> Create channel and join error:", err)
		os.Exit(-1)
	}

	// create chaincode lifecycle
	if err := sdkInit.CreateCCLifecycle(&info, 1, false, sdk); err != nil {
		fmt.Println(">> create chaincode lifecycle error: %v", err)
		os.Exit(-1)
	}

	// invoke chaincode set status
	fmt.Println(">> ......")

	if err := info.InitService(info.ChaincodeID, info.ChannelID, info.Orgs[0], sdk);err != nil{

		fmt.Println("InitService successful")
		os.Exit(-1)
	}

	App=sdkInit.Application{
		SdkEnvInfo: &info,
	}
	fmt.Println(">> ")

	a:=[]string{"set","ID","123"}
	ret, err := App.Set(a)
	if err != nil {
		fmt.Println(err)
	}
	fmt.Println("<--- --->", ret)


	b := []string{"get","ID"}
	response, err := App.Get(b)
	if err != nil {
		fmt.Println(err)
	}
	fmt.Println("<--- --->", response)

}

The Raft Consensus Algorithm on C1100