Update meta-transactions.md

docs/2.build/1.chain-abstraction/meta-transactions.md

@@ -108,11 +108,14 @@ Progress is being made to make this possible in the future.
 
 ### High volume parallel processing
 
-When running a relayer that handles a large number of transactions, issues will quickly arise due to each transaction requiring a unique nonce. If multiple transactions are sent from the same access key simultaneously, the process becomes error-prone.
+When running a relayer that handles a large number of transactions, you will quickly run into a `nonce` collision problem. At the protocol level, transactions have a unique number that identifies them (nonce) that helps to mitigate reply attacks. Each key on an account has its own nonce, and the nonce is expected to increase with each signature the key creates.
 
-Fortunately, this is easy to resolve. Adding multiple full access keys to the NEAR account used for relaying (up to 20 keys can make a significant difference) will help. Then, relaying transactions using instances of the Account object created from the various keypairs associated with the account.
+When multiple transactions are sent from the same access key simultaneously, their nonces might collide. Imagine the relayer creates 3 transactions `Tx1`, `Tx2`, `Tx3` and send them in very short distance from each other, and lets assume that Tx3 has the largest nonce. If Tx3 ends up being processed before Tx1 (because of network delay, or simply because a node picks Tx3 before Tx1), then Tx3 will execute, but Tx1 and Tx2 will fail, because they have smaller nonce!
 
-To add a key, generate a new key pair and use the original account object to call the `addKey` method:
+One way to mitigate this is to sign each transaction with a different key. Adding multiple full access keys to the NEAR account used for relaying (up to 20 keys can make a significant difference) will help. 
+
+<details> 
+<summary> Adding keys </summary>
 
 ```js
 const keyPair = nearAPI.KeyPair.fromRandom("ed25519");
@@ -122,6 +125,8 @@ const receipt = await account.addKey(keyPair.getPublicKey().toString())
 
 After saving these keys, its possible to rotate the private keys randomly when instantiating accounts before relaying ensuring you won't create a nonce collision.
 
+</details>
+
 ### Gating the relayer
 
 In most production applications it's expected that you want to be able to gate the relayer to only be used in certain cases.