docs: move blob capacity to rust code

Author: MarcosNicolau

aggregation_mode/src/backend/mod.rs

@@ -187,6 +187,32 @@ impl ProofAggregator {
             .map_err(AggregatedProofSubmissionError::ReceiptError)
     }
 
+    /// ### Blob capacity
+    ///
+    /// As dictated in [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), each blob can hold:
+    ///
+    /// - `FIELD_ELEMENTS_PER_BLOB = 4096`
+    /// - `BYTES_PER_FIELD_ELEMENT = 32`
+    ///
+    /// This gives a total theoretical capacity of:
+    ///
+    /// `FIELD_ELEMENTS_PER_BLOB * BYTES_PER_FIELD_ELEMENT = 4096 * 32 = 131072 bytes`
+    ///
+    /// However, this full capacity isn't usable due to the encoding of KZG commitments to elliptic curve points.
+    /// Specifically:
+    ///
+    /// - Ethereum uses the BLS12-381 curve, whose scalar field modulus is slightly less than `2^256`
+    ///   (closer to `2^255`).
+    /// - Therefore, 32-byte field elements can't represent all 256-bit values.
+    /// - To ensure values are within the field modulus, we **pad with a leading `0x00` byte**,
+    ///   effectively capping values below the modulus.
+    /// - This reduces the usable payload to **31 bytes per field element**.
+    ///
+    /// So, the _actual usable capacity_ per blob is:
+    ///
+    /// `4096 * 31 = 126976 bytes`
+    ///
+    /// Meaning that we can send as much as 126976 / 32 = 3968 proofs per blob
     async fn construct_blob(
         &self,
         leaves: Vec<[u8; 32]>,

docs/2_architecture/agg_mode_components/1_deep_dive.md

@@ -89,43 +89,3 @@ When submitting the aggregated proof to Ethereum, we include a **blob** that con
 -   It allows users to:
     -   Inspect which proofs were aggregated
     -   Get a Merkle proof to verify that their proof is included in the aggregated proof
-
-### Blob capacity
-
-As dictated in the [eip-4844](https://eips.ethereum.org/EIPS/eip-4844) Each blob can hold:
-
--   `FIELD_ELEMENTS_PER_BLOB = 4096`
--   `BYTES_PER_FIELD_ELEMENT = 32`
-
-Which results in a total theoretical capacity of:
-
-`FIELD_ELEMENTS_PER_BLOB * BYTES_PER_FIELD_ELEMENT` = `4096 * 32` = `131.072 bytes`
-
-However, this full capacity can't be used due to how KZG bytes to elliptic curve points are encoded. Specifically:
-
--   Ethereum uses the BLS12-381 curve, whose scalar field modulus is slightly less than `2^256`, in fact, it's closer to `2^255`.
--   That means the 32-byte field elements can't represent arbitrary 256-bit values.
--   To stay within the field modulus, we **pad the value with a leading `0x00` byte**, ensuring it's below the modulus.
--   This reduces the usable payload to **31 bytes per field element**.
-
-So the _actual usable capacity_ per blob becomes:
-
-`4096 * 31` = `126.976 bytes`
-
-### Current Bottleneck
-
-Since each [proof commitment](#proof-commitment) is exactly **32 bytes**, the maximum number of proof commitments that can fit in a single blob is:
-
-`126.976 / 32` = `3968 proofs`
-
-This is the **current upper limit** on how many proofs we can include in a single aggregation run.
-
-## Scaling Beyond Current Limits
-
-To increase throughput we can:
-
-1. **Send Multiple Blobs per Transaction**  
-   Up to **6 blobs** can be included per transaction, supporting up to **23,808 proofs per run**, which is more than we can aggregate in one day.
-
-2. **Run Aggregation More Frequently**  
-   Reducing the interval between aggregation runs.