updated docs

learn/protocol/block-format.md

@@ -14,6 +14,7 @@ Micro blocks contain user transactions, and each micro block is produced and sig
 
 | Data field | Description |
 | --- | --- |
+| `network` | The network ID associated with the block, such as mainnet or devnet. |
 | `version` | The block’s version number. A change in the version number implies a hard fork. |
 | `block_number` | The block’s number. |
 | `timestamp` | The block's Unix time with millisecond precision. |
@@ -36,7 +37,7 @@ Micro blocks contain user transactions, and each micro block is produced and sig
 
 | Data field | Description |
 | --- | --- |
-| `Micro(Signature)` | Block producer's signature. |
+| `Micro(Ed25519Signature)` | Block producer's signature. |
 | `Skip(SkipBlockProof)` | Contains aggregated signatures for a skip block. This field might be empty as skip blocks might not occur in a batch. |
 
 Note that only one of those is added as justification. The block producer signs the block when the micro block is produced within the expected time. But when the micro block isn't produced in the expected time, a `SkipBlockProof` is added instead.
@@ -49,6 +50,7 @@ There are two types of macro blocks: election and checkpoint. A new validator li
 
 | Data field | Description |
 | --- | --- |
+| `network` | The network ID associated with the block, such as mainnet or devnet. |
 | `version` | The block’s version number. A change in the version number implies a hard fork. |
 | `block_number` | The block’s number. |
 | `round` | The specific round where the block was proposed. |
@@ -82,7 +84,7 @@ Checkpoint or election macro blocks contain a `TendermintProof` as justification
 
 The following figure demonstrates the connection between a macro block and a micro block. Every block, macro or micro, is connected to the previous one by the parent hash and the random seed.
 
-![Alt Text](/assets/images/protocol/macro-micro.png)
+<img class="object-contain max-h-[max(80vh,220px)]" src="/assets/images/protocol/macro-micro.png" alt="skip block struct" />
 
 ## Blockchain format
 

learn/protocol/equivocation-proofs.md

@@ -32,7 +32,7 @@ pub struct ForkProof {
 
 The offending validator address, two micro headers from the same block height and the respective signatures are enough to prove the malicious behavior.
 
-### Double proposal
+### Double proposal proofs
 
 Macro blocks are produced using the Tendermint algorithm. A validator, selected as the round leader, proposes a macro block and gossips its proposal. Malicious validators may attempt to propose two different macro headers at the same block height, round and step.
 
@@ -50,9 +50,9 @@ pub struct DoubleProposalProof {
 
 The offending validator address, two macro headers from the same round and the respective signatures are enough to prove the malicious behavior.
 
-### Double vote
+### Double vote proofs
 
-Validators are expected to vote block or “none” for a single Tendermint proposal per round and step. Voting for different proposals at the same block height, round, and step is considered a double vote, disrupting Tendermint's voting principle. The double vote proof is used to identify and penalize validators for their misbehavior.
+Validators are expected to vote block or _nil_ for a single Tendermint proposal per round and step. Voting for different proposals at the same block height, round, and step is considered a double vote, disrupting Tendermint's voting principle. The double vote proof is used to identify and penalize validators for their misbehavior.
 
 ```rust
 pub struct DoubleVoteProof {

learn/protocol/glossary.md

@@ -56,9 +56,11 @@ A compressed signature is a compacted version of a typical digital signature gen
 
 A type of algorithm used to reach an agreement between nodes in a shared state. Nimiq PoS is a consensus algorithm where validators work together to follow the consensus rules, providing accuracy and consistency.
 
-## Disabled slot set
+## Double proposal
+The act of submitting two different Tendermint proposals in the same round.
 
-A set of slots not eligible to produce blocks due to misbehaving. This is one of the three punishment sets in the staking contract. Validators must send an unpark transaction referring to their disabled slot to resume the block production. We include a disabled set for the previous epoch and another one for the current epoch, as it affects the rewards distribution for a batch; thus, they get their rewards burned.
+## Double vote
+The act of voting twice for the same block height, at the same round and step of Tendermint.
 
 ## Election block
 
@@ -72,6 +74,12 @@ The measure of unpredictability of a random value. Using the entropy of the rand
 
 The time between two election macro blocks mark an epoch. An epoch starts with the first micro block after an election macro block and ends at an election macro block, including all the micro blocks and checkpoint macro blocks in between.
 
+## Equivocation
+An equivocation is when a validator acts maliciously against the consensus protocol. This can involve creating two blocks at the same height, proposing two Tendermint blocks for the same block height, or even voting twice for a proposal during the same round and step.
+
+## Equivocation proof
+An equivocation proof validates a validator's misbehavior, leading to jail (see [jailing](https://onmax.github.io/nimiq-developer-center/learn/protocol/glossary#jailing)) upon submission by any honest validator.
+
 ## Fork
 
 A split in the blockchain produced by a malicious validator. A malicious validator can fork the chain by producing two blocks at the same block height, attempting for a double-spend attack.
@@ -84,17 +92,13 @@ The designation of the first block in the blockchain - also known as block 0. De
 
 Part of the structure of a block. The block’s header contains general data about the block, such as the block number, the timestamp, and the version. Headers include required data to the consensus and commitments to the block. It also connects the current block to the previous one.
 
-## Inactive validator
-
-A validator becomes inactive in two cases: when they send a retire transaction or fail to send an unpark transaction before the end of the current epoch after misbehaving. Validators must first become inactive to exit the staking contract. When a validator is inactive, they are not eligible to produce or propose blocks or vote. They are not considered for validator selection, even if they remain in the staking contract.
-
 ## Inherent
 
 An inherent is a type of data that is intrinsic to the block. Unlike transactions, inherents are applied at specific times and serve different purposes, depending on their type. Inherents can be used to differentiate between a checkpoint block and an election block, for instance.
 
-## Jailing
+## Jail
 
-Jailing refers to the validator state characterized by incurring severe penalties, for actions such as forking or continuing on a fork. When a validator is in a jailed state, it is temporarily locked and cannot be re-elected during this period. Additionally, all the validator’s rewards are burned.
+Going to jail refers to the validator's state characterized by incurring severe penalties for actions such as forking or continuing on a fork. When a validator is in a jailed state, it is locked for an 8-epoch period and cannot be re-elected during this lockup. Additionally, all the validator’s rewards are burned.
 
 ## Justification
 
@@ -104,10 +108,6 @@ Part of the structure of a block. In micro blocks, the justification contains th
 
 The proposer selected to make a Tendermint proposal.
 
-## Lost reward set
-
-A set of validators that are not eligible to receive the batch rewards due to misbehavior. The lost reward set applies to the current and previous batches, as rewards are distributed with one batch delay to take into account possible misbehaviors.
-
 ## Luna
 
 The smallest unit of NIM.
@@ -132,22 +132,14 @@ A type of block produced by one validator at a time. Micro blocks include transa
 
 Nimiq’s native cryptocurrency.
 
-## Parked validator
-
-A validator that cannot produce or propose blocks during the current epoch due to misbehavior. To become active again, a parked validator must send an unpark transaction. If a parked validator fails to do so by the end of the epoch, they will be deemed inactive.
-
 ## Potential validator
 
-A validator who has staked coins to participate in the consensus but has not yet been included in the staking contract.
+A validator who has staked coins to participate in the consensus but has not yet been included in the block production.
 
 ## Proof-of-stake
 
 A blockchain model where nodes put their tokens as a deposit and get allowed to validate transactions in the blockchain. Nodes are elected proportionally by their stake. A higher deposit increases the probability of a node being selected as a validator.
 
-## Punishment set
-
-A set of punishments that consists of the parked set, lost reward set, and disabled slot set. A validator that misbehaves is punished and added to these three sets, disabling it from producing or proposing blocks and affecting the rewards to receive.
-
 ## Random seed
 
 A seed is present in every block. Random seeds are used in the validator selection to create a random and secure value. The initial random seed is generated at the genesis block, and the subsequent random seeds are generated by implementing the VXEDdSA algorithm instantiated as a verifiable random function.

learn/protocol/sync-protocol/state-live-sync.md

@@ -4,18 +4,16 @@ The state live sync method applies to both light nodes and full nodes. The state
 
 The state of the blockchain consists of all the accounts and corresponding balances. The accounts are stored in the accounts tree or state tree. Nodes fetch parts of the state tree present in every block to build their state tree and add it to their local storage.
 
-A Merkle tree (more precisely, a _[Merkle-Radix-Tree](https://en.wikipedia.org/wiki/Radix_tree)_) is used to store the accounts, with the account tree root stored in each block header, and each account functioning as a leaf node within the Merkle tree.
+A Merkle tree (more precisely, a [Merkle-Radix-Tree](https://en.wikipedia.org/wiki/Radix_tree)) is used to store the accounts, with the account tree root stored in each block header, and each account functioning as a leaf node within the Merkle tree.
 
 The Merkle Radix Tree efficiently stores accounts and their corresponding balances in the bottom layer. Leaf nodes in the tree represent the hashes of the accounts, and these leaf node hashes are combined through hashing to create parent or inner nodes. Parent nodes in the tree can have either one child, known as an "only child" node, or multiple children. "Only child" nodes are merged with their parent nodes, optimizing space. Combining adjacent nodes and creating parent nodes is repeated iteratively until only one hash value remains, known as the state root. This state root, stored as a single hash value, serves as proof of integrity for all the data within the accounts tree. Merkle Radix Trees allows for efficient storage and verification of accounts and balances in the blockchain while optimizing space by resulting in a single hash value representing the entire tree.
 
-Hash values are propagated up the tree from lower to higher levels until the state root is reached. The state root serves as the fingerprint of the entire tree, allowing for easy detection of unauthorized modifications and efficient data integrity verification stored in the block’s header. The following accounts tree illustrates how 5 accounts are stored in the state root:
+Hash values are propagated up the tree from lower to higher levels until the state root is reached. The state root serves as the fingerprint of the entire tree, allowing for easy detection of unauthorized modifications and efficient data integrity verification stored in the block’s header. The following accounts tree illustrates how 6 accounts are stored in the state root:
 
-![Alt Text](/assets/images/protocol/merkle-radix-tree.png)
+![Alt Text](/assets/images/protocol/merkle.png)
 
 > 💡 This figure is merely illustrative as the accounts tree hold multiple accounts.
 
-Following the above figure, account 3 has a leaf node that holds the account and the account's hash. The node above is its parent node which includes its children's hash (including data on accounts 1 and 2, their leaf nodes, and parent nodes). The second inner node is the parent of the first inner node, which is the parent of the leaf node.
-
 ## State sync
 
 Syncing with the blockchain state involves asking the network peers for chunks of their state tree to build a partial tree. A chunk is a fixed amount of state items. Adding chunks to a partial tree while the blockchain progresses enables the entire node to agree with all the peers on the current state.

learn/protocol/validators/skip-blocks.md

@@ -8,7 +8,7 @@ A skip block is a [micro block](/learn/protocol/block-format.md) with some diffe
 
 As for the justification, it attests that _x_ validator slots received and signed the skip block, and resuming the block production is unanimous among validators. The remainder data fields are similar to a micro block. The following images illustrate their differences:
 
-![Alt Text](/assets/images/protocol/skip-block.png) {align=center}
+<img class="object-contain max-h-[max(80vh,220px)]" src="/assets/images/protocol/skip-block.png" alt="skip block struct" />
 
 Mind these differentiating aspects:
 

learn/protocol/validators/validators-and-stakers.md

@@ -63,7 +63,7 @@ Stakers delegate their stake to validators, but validators are not aware of thei
 | --- | --- | --- |
 | `address` | `Address` | The address of the staker. Used for most transactions, except AddStake which accepts any address. |
 | `active_balance` | `Coin` | The staker's active balance. |
-| `inactive_balance` | `Coin` | The staker's inactive balance. Only released inactive balance can be withdrawn. |
+| `inactive_balance` | `Coin` | The staker's inactive balance. Only released inactive balance can be retired. |
 | `inactive_from` | `Option<u32>` | The block number at which the inactive balance was last inactivated (it becomes effectively inactive on the next election block). |
 | `retired_balance` | `Coin` | The staker's retired balance. Retired balance can be withdrawn immediately. |
 | `delegation` | `Option<Address>` | The address of the validator the staker is delegating its stake to. |