I’ve been using both Hyperledger Fabric and Sawtooth for sometime now. While they’re both great frameworks, they each have their own nicks and workarounds. In this article I aim to draw both the framework differences so that you can choose what suits you best.
Transaction Processor & Chaincode
Validators vs Endorsement Peers
The process of validating a transaction in Fabric involves a set of endorsing peers defined by the endorsement policy. After validation, the distribution of the transaction is handled by ordering services.
However in the Sawtooth architecture, there are validators which take care of validating the transactions in the network as well as distributing the transaction to other peers.
The State Store
Each framework handles maintaining the state of the blockchain network in its own way.
Hyperledger Fabric stores the data in either leveldb or couchdb based on the setup and manages a ledger per channel.
In the case of Sawtooth, all the data is stored in a specific address and this address is generated based on the corresponding transaction processor’s prefix. For handling rich queries an instance of rethinkdb is setup and the ledger is replicated and synced with rethinkdb.
Hyperledger Fabric has a lot of components which function together to form a blockchain network. This includes Orderers, Peers, CAs, CouchDB and Tools.
But in the case of Sawtooth there is only three majors components which are Sawtooth Validator, Transaction Processors and the REST API for the Transaction Processors. This reduces the complexity of the network and brings more scalability.
This is a companion discussion topic for the original entry at https://www.skcript.com/svr/hyperledger-fabric-to-sawtooth/