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

     1  ************
     2  Global State
     3  ************
     4  
     5  One goal of a distributed ledger like Sawtooth, indeed the
     6  *defining* goal, is to distribute a ledger among participating nodes.
     7  The ability to ensure a consistent copy of data amongst nodes in
     8  Byzantine consensus is one of the core strengths of blockchain technology.
     9  
    10  Sawtooth represents state for all transaction families in a single
    11  instance of a Merkle-Radix tree on each validator. The process of block
    12  validation on each validator ensures that the same transactions result
    13  in the same state transitions and that the resulting data is the same
    14  for all participants in the network.
    15  
    16  The state is split into namespaces which allow flexibility for
    17  transaction family authors to define, share, and reuse global state data
    18  between transaction processors.
    19  
    20  .. _merkle-radix-overview-label:
    21  
    22  Merkle-Radix Tree Overview
    23  ==========================
    24  
    25  Merkle Hashes
    26  -------------
    27  
    28  Sawtooth uses an addressable Merkle-Radix tree to store data for
    29  transaction families. Let's break that down: The tree is a Merkle tree because
    30  it is a copy-on-write data structure which stores successive node hashes
    31  from leaf-to-root upon any changes to the tree. For a given set of state
    32  transitions associated with a block, we can generate a single root hash
    33  which points to that *version* of the tree. By placing this state root
    34  hash on the block header, we can gain consensus on the expected version
    35  of state *in addition to* the consensus on the chain of blocks. If a
    36  validator's state transitions for a block result in a different hash,
    37  the block is not considered valid. For more information about general
    38  concepts, see the Merkle_ page on Wikipedia.
    39  
    40  .. image:: ../images/state_merkle_hashes.*
    41     :width: 80%
    42     :align: center
    43     :alt: Merkle hash diagram
    44  
    45  .. _Merkle: https://en.wikipedia.org/wiki/Merkle_tree
    46  
    47  Radix Addresses
    48  ---------------
    49  
    50  .. image:: ../images/state_address_format.*
    51     :width: 80%
    52     :align: center
    53     :alt: Tree address format
    54  
    55  The tree is an addressable Radix tree because addresses uniquely
    56  identify the paths to leaf nodes in the tree where information is
    57  stored. An address is a hex-encoded 70 character string representing
    58  35 bytes. In the tree implementation, each byte is a Radix path segment which
    59  identifies the next node in the path to the leaf containing the data
    60  associated with the address. The address format contains a 3 byte
    61  (6 hex character) namespace prefix which provides 2\ :sup:`24`
    62  (16,777,216) possible different namespaces in a given instance of
    63  Sawtooth. The remaining 32 bytes (64 hex characters) are encoded
    64  based on the specifications of the designer of the namespace, and may
    65  include schemes for subdividing further, distinguishing object types,
    66  and mapping domain-specific unique identifiers into portions of the address.
    67  For more information about general concepts, see the Radix_ page on
    68  Wikipedia.
    69  
    70  .. image:: ../images/state_radix.*
    71     :width: 80%
    72     :align: center
    73     :alt: Radix addressing diagram
    74  
    75  .. _Radix: https://en.wikipedia.org/wiki/Radix_tree
    76  
    77  Serialization Concerns
    78  ======================
    79  
    80  In addition to questions regarding the encoding of addresses,
    81  namespace designers also need to define the mechanism of serialization
    82  and the rules for serializing/deserializing the data stored at addresses.
    83  The domain-specific Transaction Processor makes get(address) and
    84  set(address, data) calls against a version of state that the validator
    85  provides. get(address) returns the byte array found at that address
    86  and set(address, data) sets the byte array stored at that address.
    87  The byte array is opaque to the core system. It only has meaning when
    88  deserialized by a domain-specific component based on the rules of the
    89  namespace. It is critical to select a serialization scheme which is
    90  deterministic across executions of the transaction, across platforms, and
    91  across versions of the serialization framework. Data structures which don't
    92  enforce ordered serialization (e.g. sets, maps, dicts) should be
    93  avoided. The requirement is to consistently produce the same byte array
    94  across space and time. If the same byte array is not produced, the leaf
    95  node hash containing the data will differ, as will every parent node back
    96  to the root. This will result in transactions and the blocks that contain
    97  them being considered valid on some validators and invalid on others,
    98  depending on the non-deterministic behavior. This is considered bad
    99  form.
   100  
   101  .. Licensed under Creative Commons Attribution 4.0 International License
   102  .. https://creativecommons.org/licenses/by/4.0/