update formatting for the protocol section (#806)

* update formatting for the protocol section

* update formatting

* Update polkadot-protocol/parachain-basics/data-encoding.md

Co-authored-by: Copilot <[email protected]>

* Update polkadot-protocol/parachain-basics/accounts.md

Co-authored-by: Copilot <[email protected]>

* formatting fix

---------

Co-authored-by: Copilot <[email protected]>

Author: eshaben

llms.txt

@@ -12,11 +12,11 @@ Explore Polkadot's architecture, including the relay chain, parachains, and syst
 
 The following provides a brief overview of the role of each chain:
 
-- [**Polkadot relay chain**](/polkadot-protocol/architecture/polkadot-chain/) - the central hub and main chain responsible for the overall security, consensus, and interoperability between all connected chains
+- **[Polkadot relay chain](/polkadot-protocol/architecture/polkadot-chain/)**: The central hub and main chain responsible for the overall security, consensus, and interoperability between all connected chains.
 
-- [**System chains**](/polkadot-protocol/architecture/system-chains/) - specialized chains that provide essential services to the ecosystem, like the Asset Hub, Bridge Hub, and Coretime chain
+- **[System chains](/polkadot-protocol/architecture/system-chains/)**: Specialized chains that provide essential services to the ecosystem, like the Asset Hub, Bridge Hub, and Coretime chain.
 
-- [**Parachains**](/polkadot-protocol/architecture/parachains/) -  individual, specialized blockchains that run parallel to the relay chain and are connected to it
+- **[Parachains](/polkadot-protocol/architecture/parachains/)**: Individual, specialized blockchains that run parallel to the relay chain and are connected to it.
 
 Learn more about these components by checking out the articles in this section.
 

polkadot-protocol/architecture/index.md

@@ -19,18 +19,18 @@ Collators are responsible for sequencing end-user transactions into blocks and m
 
 Key responsibilities include:
 
-- **Transaction sequencing** - organizing transactions into [Proof of Validity (PoV)](https://wiki.polkadot.network/general/glossary/){target=\_blank} blocks
-- **State management** - maintaining parachain states without burdening the relay chain validators
-- **Consensus participation** - sending PoV blocks to relay chain validators for approval
+- **Transaction sequencing**: Organizing transactions into [Proof of Validity (PoV)](https://wiki.polkadot.network/general/glossary/){target=\_blank} blocks.
+- **State management**: Maintaining parachain states without burdening the relay chain validators.
+- **Consensus participation**: Sending PoV blocks to relay chain validators for approval.
 
 ## Consensus and Validation
 
 Parachain consensus operates in tandem with the relay chain, leveraging Nominated Proof of Stake (NPoS) for shared security. The process ensures parachain transactions achieve finality through the following steps:
 
-1. **Packaging transactions** - collators bundle transactions into PoV blocks (parablocks)
-2. **Submission to validator** - parablocks are submitted to a randomly selected subset of relay chain validators, known as paravalidators
-3. **Validation of PoV Blocks** - paravalidators use the parachain’s state transition function (already available on the relay chain) to verify transaction validity
-4. **Backing and inclusion** - if a sufficient number of positive validations are received, the parablock is backed and included via a para-header on the relay chain
+1. **Packaging transactions**: Collators bundle transactions into PoV blocks (parablocks).
+2. **Submission to validator**: Parablocks are submitted to a randomly selected subset of relay chain validators, known as paravalidators.
+3. **Validation of PoV Blocks**: Paravalidators use the parachain’s state transition function (already available on the relay chain) to verify transaction validity.
+4. **Backing and inclusion**: If a sufficient number of positive validations are received, the parablock is backed and included via a para-header on the relay chain.
 
 The following sections describe the actions taking place during each stage of the process. 
 
@@ -40,11 +40,11 @@ Polkadot achieves scalability through execution sharding, where each parachain o
 
 The journey parachain transactions follow to reach consensus and finality can be described as follows:
 
-- **Collators and parablocks:**
+- Collators and parablocks:
 
-    - Collators, specialized nodes on parachains, package network transactions into Proof of Validity (PoV) blocks, also called parablocks
-    - These parablocks are sent to a subset of relay chain validators, known as paravalidators, for validation
-    - The parachain's state transition function (Wasm blob) is not re-sent, as it is already stored on the relay chain
+    - Collators, specialized nodes on parachains, package network transactions into Proof of Validity (PoV) blocks, also called parablocks.
+    - These parablocks are sent to a subset of relay chain validators, known as paravalidators, for validation.
+    - The parachain's state transition function (Wasm blob) is not re-sent, as it is already stored on the relay chain.
 
 ```mermaid
 flowchart TB
@@ -66,17 +66,17 @@ flowchart TB
     Parachain -->|Submit To| Relay
 ```
 
-- **Validation by paravalidators:**
+- Validation by paravalidators:
 
-    - Paravalidators are groups of approximately five relay chain validators, randomly assigned to parachains and shuffled every minute
-    - Each paravalidator downloads the parachain's Wasm blob and validates the parablock by ensuring all transactions comply with the parachain’s state transition rules
-    - Paravalidators sign positive or negative validation statements based on the block’s validity
+    - Paravalidators are groups of approximately five relay chain validators, randomly assigned to parachains and shuffled every minute.
+    - Each paravalidator downloads the parachain's Wasm blob and validates the parablock by ensuring all transactions comply with the parachain’s state transition rules.
+    - Paravalidators sign positive or negative validation statements based on the block’s validity.
 
-- **Backing and approval:**
+- Backing and approval:
 
-    - If a parablock receives sufficient positive validation statements, it is backed and included on the relay chain as a para-header
-    - An additional approval process resolves disputes. If a parablock contains invalid transactions, additional validators are tasked with verification
-    - Validators who back invalid parablocks are penalized through slashing, creating strong incentives for honest behavior
+    - If a parablock receives sufficient positive validation statements, it is backed and included on the relay chain as a para-header.
+    - An additional approval process resolves disputes. If a parablock contains invalid transactions, additional validators are tasked with verification.
+    - Validators who back invalid parablocks are penalized through slashing, creating strong incentives for honest behavior.
 
 ```mermaid
 flowchart
@@ -113,4 +113,4 @@ It is important to understand that relay chain blocks do not store full parachai
 
 For more technical details, refer to the:
 
-- [Parachain Wiki](https://wiki.polkadot.network/learn/learn-parachains/){target=\_blank} page
+- [Parachain Wiki](https://wiki.polkadot.network/learn/learn-parachains/){target=\_blank} page

polkadot-protocol/architecture/parachains/consensus.md

@@ -19,14 +19,14 @@ Elastic scaling enables parachains to process multiple blocks in parallel by uti
 
 Consider a parachain that needs to process four consecutive parablocks. With traditional single-core allocation, the validation process follows a strictly sequential pattern. Each parablock undergoes a two-phase process on the relay chain:
 
-1. **Backing phase** - validators create and distribute validity statements
-2. **Inclusion phase** - the parablock is included in the relay chain after availability verification
+1. **Backing phase**: Validators create and distribute validity statements.
+2. **Inclusion phase**: The parablock is included in the relay chain after availability verification.
 
 Throughout the following diagrams, specific notation is used to represent different components of the system:
 
-- R1, R2, ... - relay chain blocks (produced at ~6-second intervals)
-- P1, P2, ... - parachain blocks that need validation and inclusion
-- C1, C2, ... - cores on the relay chain
+- **R1, R2, ...**: Relay chain blocks (produced at ~6-second intervals).
+- **P1, P2, ...**: Parachain blocks that need validation and inclusion.
+- **C1, C2, ...**: Cores on the relay chain.
 
 In the single-core scenario (assuming a 6-second relay chain block time), processing four parablocks requires approximately 30 seconds:
 
@@ -84,33 +84,33 @@ sequenceDiagram
 
 To help interpret the sequence diagrams above, note the following key elements:
 
-- The horizontal axis represents time progression through relay chain blocks (R1-R5)
-- Each colored rectangle shows processing on a specific core (C1 or C2)
-- In the single-core scenario, all blocks must be processed sequentially on one core
-- In the multi-core scenario, blocks are processed in parallel across multiple cores, reducing total time
+- The horizontal axis represents time progression through relay chain blocks (R1-R5).
+- Each colored rectangle shows processing on a specific core (C1 or C2).
+- In the single-core scenario, all blocks must be processed sequentially on one core.
+- In the multi-core scenario, blocks are processed in parallel across multiple cores, reducing total time.
 
 The relay chain processes these multiple parablocks as independent validation units during the backing, availability, and approval phases. However, during inclusion, it verifies that their state roots align properly to maintain chain consistency.
 
 From an implementation perspective:
 
-- **Parachain side** - collators must increase their block production rate to utilize multiple cores fully
-- **Validation process** - each core operates independently, but with coordinated state verification
-- **Resource management** - cores are dynamically allocated based on parachain requirements
-- **State consistency** - while backed and processed in parallel, the parablocks maintain sequential state transitions
+- **Parachain side**: Collators must increase their block production rate to utilize multiple cores fully.
+- **Validation process**: Each core operates independently, but with coordinated state verification.
+- **Resource management**: Cores are dynamically allocated based on parachain requirements.
+- **State consistency**: While backed and processed in parallel, the parablocks maintain sequential state transitions.
 
 ## Benefits of Elastic Scaling
 
-- **Increased throughput** - multiple concurrent cores enable parachains to process transactions at multiples of their previous capacity. By allowing multiple parachain blocks to be validated within each relay chain block cycle, applications can achieve significantly higher transaction volumes
+- **Increased throughput**: Multiple concurrent cores enable parachains to process transactions at multiples of their previous capacity. By allowing multiple parachain blocks to be validated within each relay chain block cycle, applications can achieve significantly higher transaction volumes.
 
-- **Lower latency** - transaction finality improves substantially with multi-core processing. Parachains currently achieve 2-second latency with three cores, with projected improvements to 500ms using 12 cores, enabling near-real-time application responsiveness
+- **Lower latency**: Transaction finality improves substantially with multi-core processing. Parachains currently achieve 2-second latency with three cores, with projected improvements to 500ms using 12 cores, enabling near-real-time application responsiveness.
 
-- **Resource efficiency** - applications acquire computational resources precisely matched to their needs, eliminating wasteful over-provisioning. Coretime can be purchased at granular intervals (blocks, hours, days), creating cost-effective operations, particularly for applications with variable transaction patterns
+- **Resource efficiency**: Applications acquire computational resources precisely matched to their needs, eliminating wasteful over-provisioning. Coretime can be purchased at granular intervals (blocks, hours, days), creating cost-effective operations, particularly for applications with variable transaction patterns.
 
-- **Scalable growth** - new applications can launch with minimal initial resource commitment and scale dynamically as adoption increases. This eliminates the traditional paradox of either over-allocating resources (increasing costs) or under-allocating (degrading performance) during growth phases
+- **Scalable growth**: New applications can launch with minimal initial resource commitment and scale dynamically as adoption increases. This eliminates the traditional paradox of either over-allocating resources (increasing costs) or under-allocating (degrading performance) during growth phases.
 
-- **Workload distribution** - parachains intelligently distribute workloads across cores during peak demand periods and release resources when traffic subsides. Paired with secondary coretime markets, this ensures maximum resource utilization across the entire network ecosystem
+- **Workload distribution**: Parachains intelligently distribute workloads across cores during peak demand periods and release resources when traffic subsides. Paired with secondary coretime markets, this ensures maximum resource utilization across the entire network ecosystem.
 
-- **Reliable performance** - end-users experience reliable application performance regardless of network congestion levels. Applications maintain responsiveness even during traffic spikes, eliminating performance degradation that commonly impacts blockchain applications during high-demand periods
+- **Reliable performance**: End-users experience reliable application performance regardless of network congestion levels. Applications maintain responsiveness even during traffic spikes, eliminating performance degradation that commonly impacts blockchain applications during high-demand periods.
 
 ## Use Cases