Hyperledger Sawtooth Series - 1. The Basics

hyperledger-sawtooth
sawtooth-series
hyperledger

(Varun Raj) #1

Next Part


A brief before we start

As a lot of people we’re asking us about how to develop blockchain based applications in sawtooth and also in order to make the community aware of the technology I wanted to start this series. Here I’ll be talking about various things involved in sawtooth development with multiple articles. Also this will be a open ground and anyone can contribute to this series so that we make it more robust for people to reference.

A Quick Warning! This article is going to be purely technical and most of the jargons will be inclined towards blockchain, if you face any such difficulties in the articles, please feel free to comment in below discussion.

What is Sawtooth?

Sawtooth is yet another blockchain framework initially developed by Intel and later submitted to Hyperledger Consortium. It follows a different architecture than it’s competitive framework Hyperledger Fabric. Sawtooth architecture is more like ethereum and bitcoin which gives the user more robust system and the power to host the infrastructure based on your needs.

A Few Links to Notice

Please suggest if there is anything else to be added :slight_smile:

Requirements

  • Docker
  • Docker Compose
  • NodeJS

For setting up the basic things you can have a look at one of my previous article here : https://discourse.skcript.com/t/guide-how-to-install-hyperledger-sawtooth-on-ubuntu-16-04/1513

The Basic Concepts

In sawtooth we’ve few set of components which are responsible for running the entire network together.

Validators

Validators are peer nodes which are interconnected in form of a mesh network and can talk with each other. These nodes holds the data in form of a merkle tree which is also called as the ledger data. Our application writes and retires data from this merkle tree.

Transaction Processors

Each and every project will have a set of business rules to be validated during the functioning of the system, These rules are also called as smart contracts in general blockchain world. Here we call them as transaction processors as they are processing each and every transactions before committing it to each and every node.

Sawtooth Rest Server

The Rest Server is the service which helps the users to talk with the validators to submit any transactions with help of HTTP Requests. This is going to be our close friend throughout the series :slight_smile:

The above thee are the most important things as of now, but we’ll introduce more components as we go deeper in this series.

Consensus

Sawtooth comes with three consensus algorithms which you can use in your network.

  • Proof of Elapsed Time (PoET), a Nakamoto-style consensus algorithm that is designed to be a production-grade protocol capable of supporting large network populations. PoET relies on secure instruction execution to achieve the scaling benefits of a Nakamoto-style consensus algorithm without the power consumption drawbacks of the Proof of Work algorithm.
  • PoET simulator, which provides PoET-style consensus on any type of hardware, including a virtualized cloud environment.
  • Dev mode, a simplified random-leader algorithm that is useful for development and testing.

Running the Network

As we already spoke a lot of theoretical stuff, it’s now time for us to get our hands dirty. Now as the first step let’s create project folder

mkdir sawtooth-kickstart
cd sawtooth-kickstart

The first and foremost file we need is the docker configuration file (docker-compose.yml) and start the network

For this series, I’ll be going with the docker compose file which is provided in the official example. Copy Paste the contents below to your docker-compose.yml

version: "2.1"

services:

  settings-tp:
    image: hyperledger/sawtooth-settings-tp:1.0
    container_name: sawtooth-settings-tp-default
    depends_on:
      - validator
    entrypoint: settings-tp -vv -C tcp://validator:4004
    
  validator:
    image: hyperledger/sawtooth-validator:1.0
    container_name: sawtooth-validator-default
    expose:
      - 4004
    ports:
      - "4004:4004"
    # start the validator with an empty genesis batch
    entrypoint: "bash -c \"\
        sawadm keygen && \
        sawtooth keygen my_key && \
        sawset genesis -k /root/.sawtooth/keys/my_key.priv && \
        sawadm genesis config-genesis.batch && \
        sawtooth-validator -vv \
          --endpoint tcp://validator:8800 \
          --bind component:tcp://eth0:4004 \
          --bind network:tcp://eth0:8800 \
        \""

  rest-api:
    image: hyperledger/sawtooth-rest-api:1.0
    container_name: sawtooth-rest-api-default
    ports:
      - "8008:8008"
    depends_on:
      - validator
    entrypoint: sawtooth-rest-api -C tcp://validator:4004 --bind rest-api:8008

According to this configuration we’ve one sawtooth validator (running on TCP port 4004) and one sawtooth rest-api (running on HTTP port 8008). As you can see it’s a very basic and most simplest sawtooth network.

Now let’s start the network with docker compose.

docker-compose -f docker-compose.yml up -d

image

This will pull the images if it’s not found in your local machine and start the containers. You can check the container running with the following command

docker ps

If everything is working fine, then you’ve successfully started the sawtooth network in your local machine.

But just keep in mind that it’s very basic and non scalable network which you can’t even think of using in production. This is just for development of your smart contracts and testing it.

In the next article, I’ll be explaining you how we can write our first transaction processor and deploy it in your sawtooth network.


Hyperledger Sawtooth Series - 2. Writing Your First Transaction Processor