Hyperledger_Sawtooth_101.txt

Validator, Journal, Completer, Chain Controller, Block Publisher
In Hyperledger Sawtooth, Blocks and Batches are both validated by authorized nodes in a similar way. For instance, the two are processed by the Journal — an interface that routes tasks through internal pipelines.
The first contact with the Journal from an incoming unit is through the Completer. This component makes sure that “all dependencies for the Blocks and Batches have been satisfied and delivered downstream”.
Then, the completed blocks are delivered to the Chain Controller for fork-resolution purposes, while the completed batches are sent to the Block Publisher for inclusion in a block.
Working in tandem, the Controller and Publisher allow for the processing of incoming blocks and the claiming of new ones respectively; this can all be done in parallel and scales through moments of high incoming block rates.
Block Store : Blocks can be accessed via Batch ID, Transaction ID, or block number.
Forks are not included in the store. To change the chain head from one fork to another, both lists for blocks to commit and uncommit up to the common root are provided to an atomic method.
The BlockCache holds the working set of blocks for the validator and tracks the processing state. It is the live, in-memory construct version of the Block Store, rebuilt when the system is started. Upon lookup, if the block isn’t found in the cache then a query is made to the store and if it is still missing the block is considered unknown to the system.
The Journal supports pluggable consensus algorithms like Proof of Work, Proof of Elapsed Time and other Practical Byzantine Fault Tolerant algorithms. Changes to the network protocol are done through authenticated proposals which are transactions of the settings family.

Transaction Processors can be developed using Transaction Processor SDK
Transaction Processors can be executed on virtual machines or containers

Clients can invoke transaction processors through REST API
Clients need to bootstrap Genesis Block using Genesis Block Utility and Adminstrative CLI

Dispatcher Model
TP Dispatcher, Publish Dispatcher, Client Dispatcher

Get Status using Stats Publish Dispatcher, Get Block Transaction Info using Client Dispatcher,
Create Metrics, Submit Events using TP Dispatcher

There is a Stats Keeper and Block, Batch, Tranasction Knower

Content Manager generate get/set the Merkle Root and Merkle Tree

Transaction Executor can create, finalize, destroy the context

Transactions can be scheduled in serial and parallel mode
Chain Controller produce schedule for the blocks
Chain Controller validate chain and update the Block Store
Chain Controller execute the plan for the Transaction Executor
Chain Controller notifies changes to the Journal Block Publisher
Chain Controller checks the Consensus Type ( Dev Mode / Poet Consensus )

Journal Block Publisher can also execute the plan through Transaction Executor
Journal Block Publisher can iteratively schedule batches into set through transaction scheduler
Journal Block Publisher can sign constructed blocks
Journal Block Publisher sends out Blocks to the network

Network maintains Authenticators, Completers, Gossip Responders
Network dispatches authentication messages to Authenticators
Network dispatches gossip messages ( blocks, batches ) to Completer
Network dispatches request messages to gossip responders
Network checks message validity with message validators
Network does block validations through remote validators

Message Validators check the message signature and sign constructed blocks

Completer sends out the blocks to the chain controller for block validation
Completer sends out the validated batches to the Journal Block Publisher

Validators have a larger process boundary compared to the Transaction Processors
Validators have a larger processor boundary compared to the REST APIs

Transaction Processors can connect to the interconnect through ipc or tcp
Validators can connect to the network through tcp 
Clients can connect to the REST APIs through http / https

Transaction Families helps to execute Safe Smart Contracts
We can use custom API servers with Transaction Processors 

Transactions can be wrapped in batches which can span across multiple transaction families
Transactions declare input and output addresses to allow for state access isolation calculations
Transaction declarations of this type can be considered similar to the Bitcoin UTXO model
Transaction state access isolation calculations involve topological sort on DAG in the scheduler

Transaction inputs and outputs are enforced by the context manager on the established context
Parallel validation and state delta aggregation across large number of transactions and blocks is supported

Writing Events in Hyperledger Sawtooth 
https://www.hyperledger.org/blog/2019/02/19/hyperledger-sawtooth-events-in-go-2

We can use custom API servers with Transaction Processors

Creating Transaction Handlers
https://sawtooth.hyperledger.org/docs/core/nightly/master/_autogen/sdk_TP_tutorial_go.html