doc: update witness size (#12530)

Update docs to reflect #11997.

docs/misc/state_witness_size_limits.md

@@ -1,7 +1,7 @@
 ## State witness size limits
 
 Some limits were introduced to keep the size of `ChunkStateWitness` reasonable.
-`ChunkStateWitness` contains all the incoming transactions and receipts that will be processed during chunk application and in theory a single receipt could be tens of megabytes in size. Distributing a `ChunkStateWitness` this large would be troublesome, so we limit the size and number of transactions, receipts, etc. The limits aim to keep the total uncompressed size of `ChunkStateWitness` under 16MiB.
+`ChunkStateWitness` contains all the incoming transactions and receipts that will be processed during chunk application and in theory a single receipt could be tens of megabytes in size. Distributing a `ChunkStateWitness` this large would be troublesome, so we limit the size and number of transactions, receipts, etc. The limits aim to keep the total uncompressed size of `ChunkStateWitness` under 17MiB.
 
 There are two types of size limits:
 * Hard limit - the size must be below this limit, anything else is considered invalid
@@ -20,9 +20,9 @@ The limits are:
     * Validating new transactions generates storage proof (recorded trie nodes), which has to be limited. Once transaction validation generates more storage proof than this limit, the chunk producer stops adding new transactions to the chunk.
 * `per_receipt_storage_proof_size_limit - 4 MB`
     * Executing a receipt generates storage proof. A single receipt is allowed to generate at most 4MB of storage proof. This is a hard limit, receipts which generate more than that will fail.
-* `main_storage_proof_size_soft_limit - 3 MB`
+* `main_storage_proof_size_soft_limit - 4 MB`
     * This is a limit on the total size of storage proof generated by receipts in one chunk. Once receipts generate more storage proof than this limit, the chunk producer stops processing receipts and moves the rest to the delayed queue.
-    * It's a soft limit, which means that the total size of storage proof could reach 7 MB (2.99MB + one receipt which generates 4MB of storage proof)
+    * It's a soft limit, which means that the total size of storage proof could reach 8 MB (3.99MB + one receipt which generates 4MB of storage proof)
     * Due to implementation details it's hard to find the exact amount of storage proof generated by a receipt, so an upper bound estimation is used instead. This upper bound assumes that every removal generates additional 2000 bytes of storage proof, so receipts which perform a lot of trie removals might be limited more than theoretically applicable.
 * `outgoing_receipts_usual_size_limit - 100 KiB`
     * Limit on the size of outgoing receipts to another shard. Needed to keep the size of `source_receipt_proofs` small.
@@ -31,7 +31,7 @@ The limits are:
     * On every block height there's one special "allowed shard" which is allowed to send larger receipts, up to 4.5 MiB in total.
     * A receiving shard will receive receipts from `num_shards - 1` shards using the usual limit and one shard using the big limit.
 
-In total that gives 4 MiB + 500 KiB + 7MB + 5*100 KiB + 4.5 MiB ~= 16 MiB of maximum witness size. Possibly a little more on missing chunks.
+In total that gives 4 MiB + 500 KiB + 8MB + 5*100 KiB + 4.5 MiB ~= 17 MiB of maximum witness size. Possibly a little more on missing chunks.
 
 ### Validating the limits