Add module limits explainer

docs/architecture/stack/trace-expansion-proving/prover-limits.mdx

@@ -0,0 +1,37 @@
+---
+title: Module limits
+description: How module limits ensure the prover can generate proofs.
+sidebar_position: 3
+---
+
+Linea has a built-in mechanism for ensuring that the prover can continue to generate proofs
+without increasing proof complexity to such a level that current infrastructure cannot process them. 
+This mechanism involves module limits. 
+
+Modules are the sections into which Linea's arithmetization specification is divided. Each module 
+represents a collection of operations (opcodes) at the EVM level, or corresponds to a specific 
+function of Linea's zkEVM. Some of the modules process transaction data; some manage zkEVM memory; 
+others coordinate interactions between modules.
+
+Regardless of its purpose, each module has a specific limit to the amount of lines of data that 
+its operations can generate. You can view each module's limits in the [Linea source code](https://github.com/Consensys/linea-monorepo/blob/main/config/common/traces-limits-besu-v2.toml).
+Every time unique instructions are provided to one of the operations in a module, additional lines
+are generated (repeat calls with the same arguments do not generate new lines).
+
+Transactions with a high complexity—using a large volume of operations repeatedly—may generate too 
+many lines of data, and exceed that module's limit. Transactions that reach this point are 
+rejected by the [sequencer](../sequencer/index.mdx) to ensure that the trace data passed to the 
+prover is of a manageable scope, and that a proof can be generated.
+
+Transaction rejections caused by module limits can be identified through three different methods:
+1. [`linea_estimateGas`](../../../developers/reference/api/linea-estimategas.mdx), which simulates
+a transaction using given parameters. Transactions that exceed module limits cause an error.
+2. [`eth_sendRawTransaction`](../../../developers/reference/api/eth-sendrawtransaction.mdx). 
+Similarly, `eth_sendRawTransaction` simulates the transaction before it is submitted, and 
+returns an error if module limits would be exceeded.
+3. Finally, if the transaction was sent and doesn't get rejected directly, nor included in a block, 
+the [`linea_getTransactionExclusionStatusV1`](../../../developers/reference/api/linea-gettransactionexclusionstatusv1.mdx)
+API method can be used to query the reason for transaction rejection in edge cases where 
+`linea_estimateGas` or `eth_sendRawTransaction` did not return an error. `linea_getTransactionExclusionStatusV1`
+is only available for Infura nodes via request. View its [reference page](../../../developers/reference/api/linea-gettransactionexclusionstatusv1.mdx) 
+for more information on requesting it.

docs/developers/reference/api/eth-sendrawtransaction.mdx

@@ -31,7 +31,7 @@ On Linea, each transaction is represented by a sequence of lines representing th
 happening at the EVM level. These lines are grouped by modules and are used as inputs to the prover. 
 In order to limit the resources required to generate proofs, limits are enforced on the maximum 
 number of lines each module can have. Hence, when a transaction is considered for inclusion in a 
-block, a line count check is perform to ensure it conforms to the requirements.
+block, a line count check is perform to ensure it conforms to the requirements. [Read more](../../../architecture/stack/trace-expansion-proving/prover-limits.mdx).
 
 ## Parameters
 

project-words.txt

@@ -301,6 +301,7 @@ gcsize
 gctime
 genkey
 getopts
+gettransactionexclusionstatusv
 gitgraph
 gitpod
 Gizathon

sidebars.js

@@ -523,6 +523,7 @@ const sidebars = {
           items: [
             "architecture/stack/trace-expansion-proving/proving",
             "architecture/stack/trace-expansion-proving/trace-expansion",
+            "architecture/stack/trace-expansion-proving/prover-limits"
           ],
         },
       ],