diff --git a/docs/alpha/blocks_ops.rst b/docs/alpha/blocks_ops.rst index 0d8f195a7e114b007f5b7b78c0ded591695384cc..82020cac9c8cf6fc28cb5ced45af2ea94bb586c3 100644 --- a/docs/alpha/blocks_ops.rst +++ b/docs/alpha/blocks_ops.rst @@ -76,8 +76,7 @@ voting operations: (``Pass``), when examining a protocol amendment proposal. Further details on each operation's implementation and semantics are -provided in the dedicated entry for :ref:`on-chain -governance`. +provided in the dedicated entry for :doc:`on-chain governance`. .. _anonymous_operations_alpha: diff --git a/docs/alpha/protocol_overview.rst b/docs/alpha/protocol_overview.rst index 953dd75fa03ef40b9502cee3472473d636a07517..09e0a774ad1f856e314c55cdf0f757bfc1321793 100644 --- a/docs/alpha/protocol_overview.rst +++ b/docs/alpha/protocol_overview.rst @@ -136,9 +136,9 @@ The *values* of protocol constants in any given protocol can be found using spec Further documentation of various protocol constants can be found in the subsystems where they conceptually belong. See, for example: -- :ref:`proof-of-stake parameters `. +- :ref:`proof-of-stake parameters ` - :ref:`consensus-related parameters ` -- :ref:`randomness generation parameters `. +- :ref:`randomness generation parameters ` See also ~~~~~~~~ diff --git a/docs/developer/guidelines.rst b/docs/developer/guidelines.rst index ed207ff53f7bf0d829692f7fe6c5f41263132f26..3539cac55afa5d76d3e020206d2c4060266c6deb 100644 --- a/docs/developer/guidelines.rst +++ b/docs/developer/guidelines.rst @@ -156,7 +156,7 @@ Here are a few tips and guidelines on using docstrings. - Docstrings in ``.mli`` and ``.ml`` files are handled the same, so do not omit documenting the interfaces in the latter files. -For more information on using docstrings, see the ``odoc`` `documentation for library authors `__. +For more information on using docstrings, see the ``odoc`` `documentation for library authors `__. Docstrings errors """"""""""""""""" diff --git a/docs/nairobi/protocol_overview.rst b/docs/nairobi/protocol_overview.rst index 338df6a99df7ac520c591ba317694ad13e725fca..308f349cded00edca413d3d52074bc99c2e2072a 100644 --- a/docs/nairobi/protocol_overview.rst +++ b/docs/nairobi/protocol_overview.rst @@ -174,9 +174,9 @@ The *values* of protocol constants in any given protocol can be found using spec Further documentation of various protocol constants can be found in the subsystems where they conceptually belong. See, for example: -- :ref:`proof-of-stake parameters `. +- :ref:`proof-of-stake parameters ` - :ref:`consensus-related parameters ` -- :ref:`randomness generation parameters `. +- :ref:`randomness generation parameters ` See also ~~~~~~~~ diff --git a/docs/shell/glossary.rst.h b/docs/shell/glossary.rst.h deleted file mode 100644 index 430f324e2c0392c5030e4dce483092b5d39cf44c..0000000000000000000000000000000000000000 --- a/docs/shell/glossary.rst.h +++ /dev/null @@ -1,77 +0,0 @@ -.. - This is the protocol-independent part of the glossary. - It is included by all the protocol-dependent glossaries. - -.. _blocks: - -_`Block` - The Tezos blockchain is a linked list of blocks (or actually, a tree when several competing branches exist). - Blocks conceptually contain a header and a list of operations_, - which are specific to the `economic protocol`_. - - The header itself decomposes into a :ref:`shell header` (common to all Tezos economic protocols), and a protocol-specific header. - The shell header contains protocol-agnostic data such as the predecessor's block hash and the block's timestamp. - -_`Context` - The state of the blockchain. The context is defined by the - `economic protocol`_ and typically includes information such as - “this account_ is credited with this many tez” and “this is the - code for that `smart contract`_.” - - The context is modified by operations_. For example, an - operation_ can transfer tez from one account_ to another, which modifies the - part of the context that tracks account_ credit. - -_`Economic protocol` - The economic protocol is the set of rules defining valid operations_ and blocks_, how the network agrees on the next block to build (the consensus algorithm), - and how operations update the blockchain state, also called context_. - - In Tezos, the economic protocol can be upgraded without interruption or - forking of the blockchain. This is because the procedure for an upgrade is also defined within the economic protocol, which can thus update itself. - -_`Fitness` (a.k.a. score, weight) - For each block, the consensus algotrithm can compute a score called fitness which determines the quality of the chain leading to that block. - The shell changes the head of the chain to the valid block that has the highest fitness. - -_`Height` - See level_. - -_`Level` (a.k.a. block height) - The position of a block_ in the blockchain, that is, the number of blocks - since the genesis block, where the genesis block is at level 0. - -_`Mempool` - A (block or operation) metadata is a piece of data - computed as a result of the application of the - block or operation on an associated context_. The metadata - consists of many pieces of information such as the operation receipts, - rewards updates, voting period, etc. - - A block's metadata is the collections of operations metadata for all the operations included in the block (if the validation was successful). - - For a detailed metadata content check the :doc:`./rpc` under - the prefix ``..//metadata``. - -_`Node` - A peer in the P2P network. It maintains a local state and propagates blocks_ - and operations_. - -.. _operations: - -_`Operation` - An operation transforms the context_; this is what makes the state of the chain - change. Operations are grouped into blocks_; thus, the chain progresses in - batches. - For the different kinds of operations defined by the protocol, see `operation kinds`_. - -_`Score` - See fitness_. - -_`Shell` - The shell is a software component of the node_. It is parameterized by a - specific `economic protocol`_. It serves as the bridge between the P2P layer - (handling communication between nodes) and the `economic protocol`_ layer - (handling the context_, operation_ application, scoring, etc.). - -_`Weight` - See fitness_.