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
- Homepage https://sawtooth.hyperledger.org/
- Documentation https://sawtooth.hyperledger.org/docs/core/releases/latest/
- Official Community https://chat.hyperledger.org/channel/sawtooth
Please suggest if there is anything else to be added
- Docker Compose
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 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.
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
The above thee are the most important things as of now, but we’ll introduce more components as we go deeper in this series.
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
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
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.