Hyperledger Sawtooth Architecture: An Introduction To The Validator Network
Open Source For You|February 2019
Hyperledger Sawtooth Architecture: An Introduction To The Validator Network

This article is for open source technology enthusiasts who are interested in blockchain technologies and have a working knowledge of the Hyperledger Sawtooth project. It will give them a quick overview of the network layer in the Hyperledger Sawtooth architecture.

The network layer is responsible for communication between validators in a Sawtooth network, including performing initial connectivity, peer discovery and message handling.

Upon start-up, validator instances begin listening on a specified interface and port for incoming connections.

Upon connection and peering, validators exchange messages with each other based on the rules of a gossip or epidemic protocol.

A primary design goal is to keep the network layer as self contained as possible — the application should not need to understand implementation details of the network in order to send and receive messages.

Services

Sawtooth has adopted the 0MQ (Zero MQ) asynchronous client/server pattern. This consists of a 0MQ router socket on the server side which listens on a provided endpoint, with a number of connected 0MQ dealer sockets as the connected clients.

The 0MQ guide describes the features of this pattern as follows:

Clients connect to the server and send requests.

For each request, the server sends 0 or more replies.

Clients can send multiple requests without waiting for a reply.

Servers can send multiple replies without waiting for new requests.

States

Sawtooth defines three states related to the connection between any two validator nodes.

Unconnected

Connected - A connection is a required prerequisite for peering.

Peered - A bi-directional relationship that forms the base case for application-level message passing (gossip).

Message types

This protocol includes the following types of messages.

Connect is the mechanism for initiating the connection to the remote node. Connect performs a basic 0MQ dealerto-router connection to the remote node and exchanges identity information for the purpose of supporting a two-way conversation. Connections sit atop 0MQ sockets and allow the dealer/router conversation.

Ping messages allow for keep-alive between router and dealer sockets.

Peer requests establish a bi-directional peering relationship between the two nodes. A peer request can be rejected by the remote node. If a peer request is rejected, the expectation is that a node attempts to connect with other nodes in the network via some strategy until the peering minimum connectivity threshold for that node is reached. If possible, the bi-directional relationship occurs over the already established 0MQ socket between dealer and router.

articleRead

You can read up to 3 premium stories before you subscribe to Magzter GOLD

Log in, if you are already a subscriber

GoldLogo

Get unlimited access to thousands of curated premium stories, newspapers and 5,000+ magazines

READ THE ENTIRE ISSUE

February 2019