Last active
April 30, 2019 13:36
-
-
Save gokulsan/514ce69a10ad17f00890397cb2acc91c to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Creating Transaction Handlers
https://sawtooth.hyperledger.org/docs/core/nightly/master/_autogen/sdk_TP_tutorial_go.html