github.com/muhammedhassanm/blockchain@v0.0.0-20200120143007-697261defd4d/sawtooth-core-master/docs/source/glossary.rst (about)

     1  Glossary
     2  ========
     3  
     4  This glossary defines general Sawtooth terms and concepts.
     5  
     6  .. glossary::
     7  
     8    Batch
     9      Group of related transactions.
    10      In Sawtooth, a batch is the atomic unit of state change for the blockchain.
    11      A batch can contain one or more transactions. For a batch with multiple
    12      transactions, if one transaction fails, all transactions in that batch fail.
    13      (The client application is responsible for handling failure appropriately.)
    14      For more information, see :doc:`architecture/transactions_and_batches`.
    15  
    16    Blockchain
    17      Distributed ledger that records transactions, in chronological order,
    18      shared by all participants in a Sawtooth network. Each block on the
    19      blockchain is linked by a cryptographic hash to the previous block.
    20  
    21    Consensus
    22      Process of building agreement among a group of mutually distrusting
    23      participants (other nodes on a Sawtooth network). Sawtooth allows
    24      different types of consensus on the same blockchain.
    25      See also :term:`Dynamic consensus`.
    26  
    27    Core
    28      See :term:`Sawtooth core`.
    29  
    30    Distributed ledger
    31      See :term:`Blockchain`.
    32  
    33    Dynamic consensus
    34      Ability to change the blockchain consensus protocol for a running Sawtooth
    35      network. The current consensus is an on-chain setting, so it can be changed
    36      by submitting a transaction.  For more information, see
    37      :ref:`dynamic-consensus-label`.
    38  
    39    Genesis block
    40      First block on the blockchain. The genesis block initializes the
    41      Sawtooth network.
    42  
    43    Global state
    44      Database that stores a local (validator-specific) record of transactions for
    45      the blockchain. Sawtooth represents state in a single instance of a
    46      Merkle-Radix tree on each validator node.  For more information, see
    47      :doc:`architecture/global_state`.
    48  
    49    Identity
    50      Sample transaction family that handles on-chain permissions (settings
    51      stored on the blockchain) for transactor and validator keys. This
    52      transaction family demonstrates how to streamline managing identities
    53      for lists of public keys. For more information, see
    54      :doc:`transaction_family_specifications/identity_transaction_family`.
    55  
    56    IntegerKey
    57      Sample transaction family with only three operations (set, increment, and
    58      decrement) that can be used to test deployed ledgers. For more information,
    59      see :doc:`transaction_family_specifications/integerkey_transaction_family`.
    60  
    61    Journal
    62      Sawtooth core component that is responsible for maintaining and extending
    63      the blockchain for the validator. For more information, see
    64      :doc:`architecture/journal`.
    65  
    66    Merkle-Radix tree
    67      Addressable data structure that stores state data. A Merkle-Radix tree
    68      combines the benefits of a Merkle tree (also called a "hash tree"), which
    69      stores successive node hashes from leaf-to-root upon any changes to the
    70      tree, and a Radix tree, which has addresses that uniquely identify the
    71      paths to leaf nodes where information is stored.  For more information, see
    72      :ref:`merkle-radix-overview-label`.
    73  
    74    Node
    75      Participant in Sawtooth network. Each node runs a single validator, a
    76      REST API, and one or more transaction processors.
    77  
    78    Off-chain setting
    79      Setting or value that is stored locally, rather than on the blockchain.
    80  
    81    On-chain setting
    82      Setting or value that is stored on the blockchain (also referred to as
    83      "in state") so that all participants on the network can access that
    84      information.
    85  
    86    Permissioned network
    87      Restricted network of Sawtooth nodes. A permissioned network
    88      typically includes multiple parties with a mutual interest but without
    89      the mutual trust found in a network controlled by a single company or
    90      entity.
    91  
    92      The blockchain stores the settings that specify permissions, such as roles
    93      and identities, so that all participants in the network can access this
    94      information.
    95  
    96    PoET
    97      Proof of Elapsed Time, a Nakamoto-style consensus algorithm that is designed
    98      to support large networks. PoET relies on a Trusted Execution Environment
    99      (TEE) such as |Intel (R)| Software Guard Extensions (SGX).
   100  
   101      Sawtooth offers two version of PoET consensus. PoET-SGX relies on
   102      |Intel (R)| SGX to implement a leader-election lottery system. PoET
   103      simulator provides the same consensus algorithm on an SGX simulator.
   104      For more information, see :doc:`architecture/poet`.
   105  
   106    REST API
   107      In Sawtooth, a core component that adapts communication with a validator to
   108      HTTP/JSON standards. Sawtooth includes a REST API that is used by clients
   109      such as the Sawtooth CLI commands. Developers can use this REST API or
   110      develop custom APIs for client-validator communication.  For more
   111      information, see :doc:`architecture/rest_api`.
   112  
   113    Sawtooth core
   114      Central Sawtooth software that is responsible for message handling,
   115      block validation and publishing, consensus, and global state management.
   116      The Sawtooth architecture separates these core functions from
   117      application-specific business logic, which is is handled by
   118      transaction families.
   119  
   120    Sawtooth network
   121      Peer-to-peer network of nodes running a validator (and associated
   122      components) that are working on the same blockchain.
   123  
   124    Settings
   125      Sample transaction family that provides a reference implementation for
   126      storing on-chain configuration settings. For more information, see
   127      :doc:`transaction_family_specifications/settings_transaction_family`.
   128  
   129    State
   130      See :term:`Global state`.
   131  
   132    State delta
   133      Result of a single change for a specific address in global state.
   134  
   135    State delta subscriber
   136      Client framework that subscribes to a validator for state deltas (changes)
   137      for a specific set of transaction families. Usually, an application
   138      subscribes to state deltas for the purpose of off-chain storage or action,
   139      such as handling the failure of a transaction appropriately.
   140  
   141    Transaction
   142      Function that changes the state of the blockchain. Each transaction is put
   143      into a Batch, either alone or with other related transactions, then sent to
   144      the validator for processing.  For more information, see
   145      :doc:`architecture/transactions_and_batches`.
   146  
   147    Transaction family
   148      Application-specific business logic that defines a set of operations or
   149      transaction types that are allowed on the blockchain. Sawtooth transaction
   150      families separate the transaction rules and content from the Sawtooth core
   151      functionality.
   152  
   153      A transaction family implements a data model and transaction language for
   154      an application. Sawtooth includes example transaction families in several
   155      languages, such as Python, Go, and Java.  For more information, see
   156      :ref:`sample-transaction-families-label`.
   157  
   158    Transaction processor
   159      Validates transactions and updates state based on the rules defined by the
   160      associated transaction family. Sawtooth includes transaction processors for
   161      the sample transaction families, such as ``identity-tp`` for the Identity
   162      transaction family. For more information, see
   163      :doc:`transaction_family_specifications`.
   164  
   165    Validator
   166      Component responsible for validating batches of transactions, combining
   167      them into blocks, maintaining consensus with the Sawtooth network,
   168      and coordinating communication between clients, transaction processors, and
   169      other validator nodes.
   170  
   171    XO
   172      Sample transaction family that demonstrates basic transactions by playing
   173      `tic-tac-toe <https://en.wikipedia.org/wiki/Tic-tac-toe>`_ on the
   174      blockchain. For more information, see
   175      :doc:`transaction_family_specifications/xo_transaction_family`.
   176  
   177  .. |Intel (R)| unicode:: Intel U+00AE .. registered copyright symbol
   178  
   179  .. Licensed under Creative Commons Attribution 4.0 International License
   180  .. https://creativecommons.org/licenses/by/4.0/