As you know Hyperledger Sawtooth is one of 5 Hyperledger Umbrella Framework of Linux Foundation including: Hyperledger Fabric, HyperledgerSawtooth, Hyperledger Iroha, Hyperledger Burror. Hypeledger Sawtooth is a blockchain platform that helps businesses build their own distributed network of blockchain and ledger applications. Considered to be very suitable for the business environment.
Sawtooth simplifies the development of a blockchain application by separating the core of the system from the application, so that application developers can define the logic of economic activities in the form of a language. The process they choose, regardless of the system’s underlying design.
Sawtooth’s core design allows applications to choose transaction rules, privacy scopes, and consensus algorithms to fit specific business operations.
1. Distributed ledgers
“Distributed ledger” is a term – another term for blockchain. It distributes the database storing transaction data to all participants of the network:
- Distributed (Distributed): A database is shared to all participants that they do not need to trust each other, all parties have the same data.
- Immutable: All data about transactions cannot be modified, checking the block’s hash will help detect data modification behavior.
2. Features of Hyperledger Sawtooth
2.1 Separate application floor with core
Sawtooth makes developing and deploying a blockchain application easy by providing a clear separation between the application layer and the core of the system. Sawtooth provides a smart contract abstracion that allows application developers to write their business logic in the language they want.
An application can be a native business logic or a smart contract virtual machine . In fact, both of these types of applications can co-exist on a blockchain network. Sawtooth allows users to define their designs at the transaction-processing layer, allowing multiple types of applications to coexist on 1instance of the blockchain network.
Each application will define transaction processors’ customizations to fit their own requirements. Sawtooth provides a sample transaction family to model low-level functions and for applications that can analyze performance and store block information.
2.2 Sawtooth’s privacy
Sawtooth was built to address the “permissioned” (private) challenges of the network. Sawtooth nodes clusters can be easily deployed with separate “permissions”. No centralized service will be able to “leak” transactions and other confidential information.
The Sawtooth blockchain network will store “permission” settings such as roles and identities, which in turn determine access for the participants.
2.3 Execute transactions in parallel
Most of the current blockchain implement transactions in order to ensure data consistency among nodes on the network. But Sawtooth has a “parallel scheduler” that separates transactions into parallel streams. Based on locations in the state by a single transaction, Sawtooth will separate transactions from each other while maintaining changes.
When possible, transactions will be performed in parallel, while preventing “double spending” even if there are many changes that are impacting the same state. Parallel scheduling greatly improves performance compared to executing transactions in order.
2.4 Event System
Hyperledger Sawtooth supports the creation and broadcasting of events. This allows the application:
- Keep track of events that are related to the blockchain, such as a new block being committed or turning into a new branch.
- Track application specific events defined by a transaction family.
- Forward information about making a transaction to the client without storing that data in the state.
The event tracking was submitted and serviced through a ZMQ Socket.
2.5 Compatibility with Ethereum Contract.
There is a project on Sawtooth and Ethereum compatibility called Seth, extending the interactivity of the Sawtooth platform to Ethereum. EVM (Ethereum Virtual Machine) can be deployed on Sawtooth using the Seth transaction family.
2.6 Dynamic Consensus
In a blockchain network, consensus is a process of building an agreement between a group of network participants. Algorithms to reach a limited consensus often require some form of votting between a known group of participants. The common approach may be “Nakamotot-style” consensus, electing a leader via random form, and the Byzantine Fault Tolerance (BFT) algorithm variants, using multiple votting loops. transparency to reach consensus.
Sawtooth abstracted the core concepts of consensus and separated consensus from the context of the transaction. The Consensus interface in Sawtooth flexibly supports various consensus implementations in the form of consensus engines interacting with validators through consensus APIs . More importantly, Sawtooth allows you to change the consensus algorithm even when your network has been created. The consensus algorithm is chosen during the initial network setup, and can be changed as soon as the network is running with one or two transactions.
Sawtooth’s Consensus API supports a variety of consensus algorithms. Sawtooth currently has consensus engines for the following algorithms:
- Sawtooth PBFT (Practical Byzatine Fault Tolerance) is a votting consensus algorithm that provides Byzantine fault tolerance with finite properties. Sawtooth PBFT extends from the basic PBFT with features such as “dynamic network membership”, “regular view changes” and a “block catch – up procedure”. A Sawtooth network with PBFT consensus algorithm requires 4 or more nodes.
- PoET (Proof of Elapsed Time) is a “Nakamoto-style” consensus algorithm designed to be a production-grade level protocol capable of supporting large networks. PoET relies on “secure instruction execution” to gain the added benefits of Nakamoto-style consensus algorithms, eliminating the drawbacks of the computational power of the Proof of Work algorithm. A Sawtooth network with PoET consensus algorithm requires at least 3 nodes.
Sawtooh currently has 2 versions of PoET:
1. PoET-SGX relies on a Trusted Execution Environment (TEE), such as Intel® Software Guard Extensions (SGX), to implement a random leader election system. PoET-SGX is sometimes called “PoET / BFT” because it is still “Byzantine fault tolerant”.
2. PoET simulator provides PoET-style consensus on all hardware, including virtualized cloud environment. PoET simulator is also called “PoET / CFT” because it is a “crash fault tolerant” and not “Byzantine fault tolerant”.
- Sawtooth Raft is a consensus algorithm that also has a leader, also a “crash fault tolerance” but it is only for small networks with member restrictions.
- Devmode (short for “Developer mode”) is a simple random vote of leader, this algorithm is useful for developing and testing a transaction processor. Devmode is not recommended for a network with many nodes should not use it for production.
2.7 Transaction Families
In a Sawtooth application, a data model and transaction language are implemented in a transaction family, running on the Sawtooth node as a transaction processor.
While most application developers will build a custom transaction family that reflects their own requirements, Sawtooth provides a number of core transaction families as models:
- IntegerKey : used to test the ledger that has been deployed
- Settings : Provides a reference deployment to store on-chain configuration settings.
- Identity : Processes “permissioning” on-chain for transactor and validator keys to validate managing identities for the list of public keys.
Transaction families also provide modela for specific fields:
- Smallbank : Process performance analysis to test benchmarking and performance when comparing performance between blockchain systems. This transaction family is based on “H-Store Smallbank benchmark”.
- BlockInfo : Provides a method to store information about a historical block.
Some other Hyperledger projects provide “smart contract functionality” to the Sawtooth platform:
- Sawtooth Saber : implements smart contract on-chain, implemented in WebAbssembly (WASM) virtual machine.
- Sawtooth Seth : Support for running the Ethereum Virtual Machine (EVM) smart contract on Sawtooth.
3. A few practical application examples
- XO: Presenting how to build basic transactions using Tic-tac-toe. Transaction family XO includes creating and implementing transactio. Reference link https://sawtooth.hyperledger.org/docs/core/releases/latest/app_developers_guide/intro_xo_transaction_family.html
- Sawtooth Supply Chain: Shows how traceability and other relevant information on any product. Supply Chain provides a sample application with a transaction processor , REST API and web app. This application also presents a decentralized solution for signing transactions on the browser, and illustrates how to synchronize the blockchain state to local databases for complex queries. Reference link https://github.com/hyperledger/sawtooth-supply-chain
- Sawtooth Marketplace: Shows how to exchange properties in arbitrary quantities between users. This sample application contains a number of components, along with the Sawtooth validator that runs the Sawtooth blockchain and provides RESTAPI to interact with. Reference link: https://github.com/hyperledger/sawtooth-marketplace
summary
This day I just introduced the Hyperledger Sawtooth platform, so most of the content I translated from Hyperledger Sawtooth docs. In the following articles, I will go into learning the components of a Sawtooth network, the implementation flow of the network, the steps to build a complete application, so remember to click “Follow” me =)) If you have any questions, please leave below the “Comments” section, I will try to answer to the extent that what I know.
Refer
https://sawtooth.hyperledger.org/docs/core/releases/latest/introduction.html