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

     1  *********************
     2  Namespace Restriction
     3  *********************
     4  
     5  A transaction family is defined by a set of parameters including a
     6  name, some version numbers, an *apply* function and namespaces. The
     7  apply function is what defines the behavior of a transaction family
     8  according to the `get` and `set` operations on addresses of the Global
     9  State. The goal of having a family declaring namespaces is to indicate
    10  the subset of addresses it will use for its `get` (read, inputs) and
    11  `set` (write, outputs) operations. It is important to remember that the
    12  namespace is not necessarily a 1-to-1 relationship between namespaces and
    13  transaction families.  Some transaction families like :doc:`Settings
    14  Transaction Family
    15  <../transaction_family_specifications/settings_transaction_family>` or
    16  :doc:`BlockInfo Transaction Family
    17  <../transaction_family_specifications/blockinfo_transaction_family>`
    18  write data at addresses that other transaction families could use,
    19  like a specific on-chain setting, or the timestamp of the latest
    20  block. Nevertheless, for security reasons, it is important to make
    21  sure transaction families cannot write data at addresses that is only
    22  intended to be read. This is the goal of the *namespace restriction*
    23  feature, when explicitly activated, the
    24  validators verify that transaction processors only perform `set`
    25  operations whose addresses have a prefix in common with one of the
    26  family’s specified namespace prefix(es). By default and for better
    27  flexibility, this namespace restriction is not enforced by the
    28  validators, but when activated, this feature augments enforcement of
    29  the transaction processors declaration done during registration.
    30  
    31  
    32  In order to activate some namespace restrictions,
    33  appropriate settings must be published on-chain using the
    34  :doc:`Settings Transaction Family
    35  <../transaction_family_specifications/settings_transaction_family>`.
    36  For every block, a validator loads the JSON data stored under the
    37  specific key ``sawtooth.validator.transaction_families``.  At this
    38  key the data is a list of JSON entries, one per transaction family,
    39  possibly including its namespaces. When a transaction family entry
    40  includes namespaces, the validator enforces that the corresponding
    41  transaction processor only writes at addresses with a prefix matching
    42  at least one of the namespaces.
    43  
    44  Here is an example in which the namespaces are set for the transaction
    45  families ``block_info``, ``sawtooth_settings`` and ``intkey``:
    46  
    47  .. code-block:: python
    48  
    49    sawtooth.validator.transaction_families='[
    50      {\"family\": \"block_info\", \"version\": \"1.0\", \"namespaces\": [\"00b10c\"]},
    51      {\"family\":\"sawtooth_settings\", \"version\":\"1.0\"},
    52      {\"family\": \"intkey\", \"version\": \"1.0\", \"namespaces\": [\"1cf126\"]} ]'
    53  
    54  In the case where a family has no ``"namespaces"``, the validator does
    55  not restrict the write permission of the family. In the example above,
    56  the family `sawtooth_settings` does not indicate any namespace and
    57  therefore the validator will let it write at any address. This is
    58  legitimate for :doc:`transaction
    59  families<../transaction_family_specifications>` which are reviewed thoroughly,
    60  like the ones included in Sawtooth.