remove outdated terms (#1336)

common/jargon.js

@@ -60,13 +60,10 @@ module.exports = {
     'An attack where a node downloads malicious snapshot files, including invalid transactions and balances.',
   'bootstrapping phase':
     'The initial phase of the IOTA 2.0 network where rewards and delegation mechanisms are designed to encourage early contributions to the network"s security.',
-  branch:
-    'In IOTA 2.0, this term refers to a version of the ledger that temporarily coexists with other versions, each spawned by conflicting transactions.',
   'causal order':
     'The order of events in the Tangle that reflects the causal relationships between transactions.',
   'chain-switching rule':
     'The Chain-Switching Rule is an algorithm that allows nodes to switch their Slot Commitment Chain to the heaviest one, resolving divergent network conditions and discrepancies in the commitments.',
-  child: 'In IOTA 2.0, a transaction that is referenced by Parents.',
   chronicle:
     "A permanode solution from the IOTA Foundation. It enables storing all transactions reaching a node in a secure and scalable distributed database. Chronicle allows the Tangle's unlimited data flow to be stored indefinitely and makes it easily accessible.",
   chrysalis: 'The name of the IOTA 1.5 network upgrade.',
@@ -100,10 +97,6 @@ module.exports = {
     'Hardware components or devices that are affordable for individual consumers.',
   coordinator:
     "(only up to iota 2.0) A trusted entity used as protection against malicious transactions. The Tangle is still in its beta phase and relies on the coordinator. This is open-source and runs on a Hornet node. The COO acts as a centralized, voluntary, and temporary alternative consensus mechanism for the Tangle by regularly sending honest transactions to the full nodes. These transactions contain a signed message with no value, called a milestone. Full nodes consider a transaction as confirmed only if it is approved by a milestone. The coordinator can confirm transactions but can't bypass consensus rules. Hence, creating, freezing, or stealing tokens is impossible for it. The coordinator's influence on the tangle is limited as the tangle is continuously monitored by all other full nodes. The COO will be switched off with the IOTA 2.0 upgrade.",
-  'core application':
-    'In IOTA 2.0, a core application is an application that all nodes must execute. For instance, the value transfer application.',
-  'core object type':
-    'In IOTA 2.0, this is an object type that all nodes must parse. Parsers are computer programs that decompose and convert input into a format more suitable for further processing.',
   cryptocurrency:
     'A digital or virtual form of currency maintained by a distributed ledger.',
   CTPS: 'Confirmed transactions per second.',
@@ -145,7 +138,6 @@ module.exports = {
   DLT: 'Distributed Ledger Technologyl; A type of technology that enables the secure and decentralized storage and sharing of information across a network and allows unaligned parties to maintain a common state. A DLT is a database system that enables the peer-to-peer transfer and recording of digital assets. Each transaction within a DLT is recorded in a distributed ledger, which is maintained across all network nodes.',
   'double-spending':
     'Two transactions that attempt to consume the same UTXO. Double-spending represents a major threat to digital currency systems. It involves spending the same digital token more than once. Digital tokens, unlike physical currency, comprise digital files that can be easily duplicated or counterfeited.',
-  dRNG: 'Decentralized Random Number Generator; dRNG is crucial for the Fast Probabilistic Consensus (FPC) as it fortifies the consensus model against attacks. For conflicting transactions, the FPC conducts several rounds of voting. The decision threshold for nodes is 50% plus or minus a slight random deviation generated by dRNG. This randomness prevents potential adversaries from manipulating the vote.',
   'dust protection':
     '(iota 1.5) To prevent IOTA from being exploited, one might continually send 1i to newly generated addresses for years, causing the ledger’s memory requirements to surge until only large servers could operate a full node. With Chrysalis, microtransactions (<1Mi) require the recipient address to enable dust. This permits a limited amount of dust transactions. Additionally, addresses with Colored Coins must be tokenized. Post-Coordicide, IOTA 2.0 will introduce a different solution.',
   'dynamic availability':
@@ -164,7 +156,6 @@ module.exports = {
     'Malicious actions or vulnerabilities that can be used to manipulate or compromise a system or network.',
   'fair access':
     'A property that ensures accessibility to network resources and functionalities for all participants, based in some Sybil protection algorithm.',
-  FPC: 'Fast Probabilistic Consensus; FPC is a consensus mechanism that employs a random number and node opinions to achieve consensus. In On-Tangle Voting, FPC is utilized only in specific edge cases. For more details, refer to OTVFPCS.',
   faucet:
     'A faucet is a reservoir of tokens. Users can easily request a limited quantity of tokens for testing purposes, which proves particularly useful for app developers.',
   fees: 'Amount in Mana consumed by users for the creation of blocks.',
@@ -185,16 +176,12 @@ module.exports = {
     "Full nodes constitute the network's backbone. For a full node to be part of the peer-to-peer network, it must always be online and connected to other full nodes. Moreover, it has to synchronize its transaction database with every other full node in the network. Full nodes process transactions from clients (like wallets and DApps), append them to the ledger, and share them with all other network nodes.",
   'future cone':
     'The future cone refers to all messages that directly or indirectly reference a particular message.',
-  'generic data object':
-    'In IOTA 2.0, this is the most elementary object type. All unrecognized data objects are treated as generic data objects.',
   'genesis commitment':
     'Every slot commitment chain starts with the genesis commitment (commitment of slot 0) in order to be considered valid.',
   'genesis slot':
     'The initial slot in the protocol"s timeline from which all subsequent slots are linked.',
   'genesis transaction':
     "The Genesis transaction is the inaugural transaction that spawned all IOTA and Shimmer tokens, distributing them to the purchasers' addresses.",
-  'goshimmer (no main net)':
-    'GoShimmer is a prototype of IOTA’s coordinator-less version written in the Go language. GoShimmer encapsulates various Coordicide modules, like auto peering, node identities, Mana, among others. It serves as a testing ground for the first alpha version and the testnet. Components tested in GoShimmer are systematically integrated with Hornet.',
   'gossip protocol':
     'A protocol for relaying information among nodes in a network.',
   'hash values':
@@ -259,8 +246,6 @@ module.exports = {
   mana: 'A reward resource generated by holding IOTA tokens. It is utilized for block issuance, access to network throughput, and protecting against Sybil attacks.',
   'mana burn':
     'The process of consuming a specific amount of Mana to create a block. The amount of Mana burned depends on recent congestion level.',
-  markers:
-    'In IOTA 2.0, a local tool that enhances efficiency in certain calculations, such as the computation of approval weight or determining the presence of specific messages in the past or future cone of another message.',
   MEV: 'Maximal or Miner Extractable Value; The potential profit that miners or validators can extract from information they glean from your transaction while it waits in the mempool.',
   mempool:
     'Where transactions are kept in waiting before being processed and where all details of a transaction can be seen by anyone. ',
@@ -295,16 +280,11 @@ module.exports = {
     'A node is any computer that communicates with other nodes in the network using specific software. Essentially, nodes act as connection points for data transfers. The Tangle employs various node types, including full nodes (Hornet, Bee), permanodes (Chronicle), and smart contract nodes (Wasp).',
   NFT: 'Non-Fungible Token; A type of digital token that represents ownership or proof of authenticity of a unique item or asset.',
   'non-validator nodes': 'Nodes in the network that are not validators.',
-  object:
-    'In IOTA 2.0, the fundamental unit of information in the IOTA protocol. Each object possesses a type, size, and data.',
   oracles:
     'Oracles establish a secure, decentralized bridge between digital and physical realms. They introduce off-chain data to decentralized applications and smart contracts within the network.',
   orphan:
     'A transaction (or block) lacking references from any subsequent transaction (or block). Orphans are unconfirmed and remain excluded from consensus.',
   'orphaned block': 'A block that is not accepted becomes orphaned.',
-  OTV: "On Tangle Voting; In IOTA 2.0, known as the multiverse consensus articulated by Hans Moog. It's a novel consensus mechanism allowing nodes to vote on conflicts by publishing a message to the tangle.",
-  otvfpcs:
-    'In IOTA 2.0, On Tangle Voting with FPCS (Fast Probabilistic Consensus on a Set) is a method designed to resolve metastability. In IOTA 2.0, achieving high approval weight signals finality. If this weight is sufficiently high, the message/transaction is confirmed. With OTVFPC, OTV forms the initial opinion. If node opinions remain divided over time, FPC initiates to resolve this metastable state, expediting transaction finality.',
   outbox:
     'A buffer where soon-to-be-scheduled blocks are enqueued before they are gossiped to the network.',
   output:
@@ -313,8 +293,6 @@ module.exports = {
     'A network where all nodes have equal roles and perform the same actions, running on top of another network like the internet.',
   'parallel processing':
     'The parallel validation of transactions without requiring total ordering. Processing can be done on multiple cores at the same time.',
-  'parallel reality ledger state':
-    'In IOTA 2.0, a state to monitor tangle conflicts. Two conflicting but causally valid ledger entries (e.g., Double Spend) are placed into separate "realities". These represent potential but exclusive future ledger states. The consensus mechanism, aided by FPC, operates until most nodes" perceptions align, leading to the acceptance of one true ledger state.',
   'parallel write access':
     'The ability for multiple participants to simultaneously write to the Tangle in the IOTA 2.0 protocol.',
   'parasite chain attacks':
@@ -401,8 +379,6 @@ module.exports = {
     'Solidification time is when a node has received the entire history of a transaction.',
   solidifier:
     'Ensures blocks are consistently linked to past blocks, creating solidity and preventing missing information when tracing back in time.',
-  solidity:
-    'In IOTA 2.0, a message is marked as solid if its entire past cone up to the Genesis (or the latest snapshot) is known.',
   'soul-bound token':
     'Non-transferable tokens representing traits/features/achievements of a person/entity.',
   'splitting attacks':
@@ -490,12 +466,8 @@ module.exports = {
     'The process of registering as a validator by issuing a block with a special payload type. The registration is only considered successful when the registration block and the mutating transaction get accepted',
   'value extraction':
     'The act of taking or deriving value from a system or network without contributing to its growth or sustainability.',
-  'value layer':
-    'In IOTA 2.0, the Value layer builds on the Communication layer. It works exclusively with payloads of type Value object. This layer has several responsibilities: forming the ledger state, processing, validating and outputting transactions, conflict detection, conflict resolution via FPC, forming a DAG from value objects, tip selection (on value object tips).',
   'value transactions':
     'Value transactions either withdraw tokens from an address or deposit them to an address. Nodes verify these transactions to ensure that the sender owns the Shimmer tokens and that additional tokens are not generated. To do this, the following checks are performed: All Shimmer tokens withdrawn from an address are also deposited into one or more other addresses; the value of each transaction does not exceed the total global supply; signatures are valid.',
-  'version number':
-    'In IOTA 2.0, the version number indicates the correct format of each type.',
   VM: 'Virtual Machine; A component responsible for executing transactions within the ledger.',
   'volume and velocity':
     'The capacity to handle a large number of transactions quickly, with fast confirmation times.',

docs/learn/protocols/iota2.0/core-concepts/consensus/preliminaries.md

@@ -132,11 +132,11 @@ Block references are crucial in the consensus protocol as they guide the [tip se
 
 ###### Strong
 
-Nodes randomly select strong parents from their _tip pool_ and attach their newly issued blocks to these selected tips. The number of strong parents sets a tradeoff between [confirmation time](consensus-flags.md#confirmation-of-blocks-and-non-conflicting-transactions) and the block size. More strong parents lead to shorter confirmation times and larger block sizes. When [computing the branch](relevant-algorithms.md#algorithm-to-compute-a-blocks-branch) of a new block, the branches of strong parents are directly inherited by the _branch_ of the new block.
+Nodes randomly select strong parents from their _tip pool_ and attach their newly issued blocks to these selected tips. The number of strong parents sets a tradeoff between [confirmation time](consensus-flags.md#confirmation-of-blocks-and-non-conflicting-transactions) and the block size. More strong parents lead to shorter confirmation times and larger block sizes. When [computing the branch](relevant-algorithms.md#algorithm-to-compute-a-blocks-branch) of a new block, the branches of strong parents are directly inherited by the branch of the new block.
 
 ###### Shallow Like
 
-Shallow like references are essential for rectifying the preliminary [block's branch](relevant-algorithms.md#algorithm-to-compute-a-blocks-branch) constructed from the strong parents. They align the block's _branch_ with the issuer's [preferred reality](relevant-algorithms.md#algorithm-to-compute-the-preferred-reality).
+Shallow like references are essential for rectifying the preliminary [block's branch](relevant-algorithms.md#algorithm-to-compute-a-blocks-branch) constructed from the strong parents. They align the block's branch with the issuer's [preferred reality](relevant-algorithms.md#algorithm-to-compute-the-preferred-reality).
 
 ###### Weak
 
@@ -262,7 +262,7 @@ The set of all conflicts in the causal history of a transaction $tx$ is called t
 
 #### Branch of a block
 
-For a block $b$, there is the branch of $b$, which is encoded through the references. This _branch_ is denoted as $Branch(b)$ and it can be computed using an [algorithm](relevant-algorithms.md#algorithm-to-compute-a-blocks-branch).
+For a block $b$, there is the branch of $b$, which is encoded through the references. This branch is denoted as $Branch(b)$ and it can be computed using an [algorithm](relevant-algorithms.md#algorithm-to-compute-a-blocks-branch).
 
 #### Vote
 

docs/learn/protocols/iota2.0/core-concepts/consensus/relevant-algorithms.md

@@ -27,7 +27,7 @@ $$
 removeConflicts  \gets ConflictWith(addLikeBranch),
 $$
 
-The function $ConflictWith(S)$ returns the set of all conflicts conflicting with at least one element from $S$. Finally, you can define the _branch_ of the block $b$ in two steps. First:
+The function $ConflictWith(S)$ returns the set of all conflicts conflicting with at least one element from $S$. Finally, you can define the branch of the block $b$ in two steps. First:
 
 $$
 Branch(b)\gets \left(addStrongBranch \cup addWeakBranch \cup addLikeBranch\right) \setminus removeConflicts.

docs/learn/protocols/iota2.0/core-concepts/consensus/tip-selection-algorithm.md

@@ -16,7 +16,7 @@ The node selects uniformly at random at most `blockMaxParent` (or `blockTypeVali
 
 After adding a new strong parent to the list of references $L$, the node attempts to select shallow-like references to align the current [branch of the block](relevant-algorithms.md#algorithm-to-compute-a-blocks-branch) with the [preferred reality](relevant-algorithms.md#algorithm-to-compute-the-preferred-reality).
 
-If `blockMaxParent` (or `blockTypeValidatorMaxParent`) shallow-like references are not sufficient to align the _branch_, the strong parent is removed from the list of references $L$ and moved to the weak tip pool $\mathcal{W}$, which is initialized as an empty set before running the _tip selection_ algorithm.
+If `blockMaxParent` (or `blockTypeValidatorMaxParent`) shallow-like references are not sufficient to align the branch, the strong parent is removed from the list of references $L$ and moved to the weak tip pool $\mathcal{W}$, which is initialized as an empty set before running the _tip selection_ algorithm.
 
 ### 3. Weak References
 

docs/learn/protocols/iota2.0/core-concepts/data-flow.md

@@ -28,7 +28,7 @@ modules control when and how many blocks can be gossiped.
 
 The _application layer_  lives on top of the _communication layer_. The _application layer_  is mainly related to objects called payloads (e.g., transactions are a type of payload). Anybody can develop applications on this layer, and nodes can choose which applications to run. Of course, these applications can also be dependent on each other.
 
-Nodes must also run several _core application_s, such as the engine, which maintains the [ledger state](data-structures.md) and a quantity called [Mana](mana.md). Mana is a scarce resource that serves as a _Sybil protection mechanism_ and spam protection. All nodes must also run the [Approval Weight and Finality Gadget](consensus/introduction.md) application, which provides a protocol that produces consensus between nodes on whether blocks are to be included in the Tangle (instead of being orphaned) and on whether transactions inside included blocks should mutate the ledger (instead of being deemed non-mutating). Lastly, the same gadget enables nodes to reorganize their perception of the Tangle when necessary, using the _fork-choice rule_.
+Nodes must also run several core applications, such as the engine, which maintains the [ledger state](data-structures.md) and a quantity called [Mana](mana.md). Mana is a scarce resource that serves as a _Sybil protection mechanism_ and spam protection. All nodes must also run the [Approval Weight and Finality Gadget](consensus/introduction.md) application, which provides a protocol that produces consensus between nodes on whether blocks are to be included in the Tangle (instead of being orphaned) and on whether transactions inside included blocks should mutate the ledger (instead of being deemed non-mutating). Lastly, the same gadget enables nodes to reorganize their perception of the Tangle when necessary, using the _fork-choice rule_.
 
 ## 4. Data Flow