Skip to content
Switch branches/tags
Go to file
Cannot retrieve contributors at this time


Below is a list of terms (and their analogies) Insolar uses to designate its key concepts.

.. glossary::

      Tick that opens up a new block and is an event that ends the current time :term:`slot` and starts a new one. Every pulse carries a new entropy/seed. Pulses are numbered in a monotonously increasing sequence.

      Time period between two consequent :term:`pulses <pulse>`. Different slots may have different time duration.

      Shardchain that keeps :term:`records <record>` of a subset of :term:`objects <object>` (:term:`lifelines <lifeline>`) contained by a :term:`cloud`. The shardchain has nodes allocated to store related records.

   Material Jet
      :term:`Jet` that has no dependencies on other jets and is meant to provide persistence and access to data.

   Virtual Jet
      Logical group of affined objects for nodes allocated to process requests related to these objects. For example, each :term:`lifeline` is considered an individual virtual jet. Such jets rely on material ones to operate: e.g., material jets store data while virtual ones do various calculations and validations of that data.

   Jet Drop
      Block of a shardchain with adjoined blocks of relevant :term:`sidechains <sideline>` that keep records produced at a specific :term:`pulse`.
      Alternatively: Set of :term:`records <record>` representing changes of :term:`lifelines <lifeline>` (and their :term:`sidelines <Sideline>`) in a :term:`jet`, all happened within a :term:`slot`.

      Decentralized application (dApp) that governs access, consensus, mutability, and other capabilities for other dApps.
      Alternatively: Collection of :term:`objects <object>` and related policies (construction, referencing, logical consensus, etc.). Domain also chooses a :term:`cloud` to provide storage and processing for objects.
      Domain itself is a descendant of an :term:`object`.

      Smart contract, dApp, application object, addressable element of application logic or data. Resides within a :term:`domain`. Object is stored as a :term:`lifeline`. The first :term:`record` of a lifeline is a permanent identifier of the object. Objects can be of different types and their lifespan is virtually unlimited and usually controlled by or through the object itself or by the object's domain.

      Similar to a transaction record; Insolar has a variety of record types. Record contains information on request, response, state control, maintenance, etc.
      All records fall into two main categories depending on their usable lifetime—a period during which the record can be used under normal circumstances:

      * *Permanent* records are generated by an application and its business logic. The logic controls the record's usable lifetime, e.g., legal documents must stay for a period of action limitation.
      * *Dust* records are associated with a permanent record and are generated either by application or system logic. The usable lifetime of such a record is limited by maintenance procedures and usually measured in days, e.g., logs or transaction control records. Dust can also be used to identify complex forms of fraud or infringements; such will be registered as permanent records and the original dust records will be archived or removed.

      Linked sequence of :term:`records <record>` related to an entity (:term:`object`, operation, etc.). Stored as a unidirectional linked list, from older to earlier records.
      Filament is identified by the reference to its head (the first/earliest record) and every filament's record has an affinity field that refers to the head.
      Filament is a general term that denotes different sequences of records. For example:

      * object's state changes (:term:`lifeline`);
      * requests (received, pending, answered, validated);
      * listings (delta and full snapshots of child object's listings).

      Chain of :term:`records <record>` (:term:`filaments <filament>`) for a single object with relevant :term:`sidelines <sideline>` that represent auxiliary information about the object.
      Alternatively: Lifeline is all history and virtually all future changes of an :term:`object` or of a :term:`dust`. Lifeline never forks and belongs to a single domain.
      The first record (head) of a lifeline is an activation record and a permanent identifier. The last record (tail) is the latest state.
      Lifeline contains:

      * main filament (object's state);
      * additional filaments (states of requests);
      * indices, listings, etc., related to the object.

      Presence of additional filaments does not mean a fork to the object's state as they carry only additional information.

      Sidechain (:term:`filament`) for auxiliary information such as logs.

      Auxiliary object or record; a log record stored within a sidechain.

      Removable :term:`sideline` for a dust record.

      Blockchain network (group of :term:`nodes <node>`) under the same node membership policy. The nodes provide storage and processing methods (including storage consensus) supported by the cloud (e.g., a specific blockchain implementation). Nodes can have different roles within the cloud.

      Server that serves hardware capacity to a cloud. Node also represents an authorization (e.g., by putting a stake) of a :term:`member` to participate in a :term:`cloud`. Node is both a unique account and a unique address within a cloud. Node is always associated with a single member and with one or more :term:`hosts <host>`. Node performs *only one* role within a cloud but a member can have multiple nodes.

      Entity of a physical/transport network, e.g., a server. Each host can have multiple network addresses, can be in different networks, and use various transport protocols and encryption standards.

      External entity (user) registered within a special :term:`domain`.

      Set of :term:`hosts <host>` sharing same security, reliability, and network performance profiles and able to directly exchange data under at least one transport protocol and at least one encryption standard supported by all hosts.
      In other words, all hosts within the same network are able to use P2P communications without violation of security and other policies.