From 83dadcfe5c566202b9e0277abdc53f5ea2ff43e6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9rgio=20Seco?= <52105707+SurgeCode@users.noreply.github.com> Date: Mon, 2 Sep 2024 11:54:13 +0100 Subject: [PATCH] Relayer nonce collisions (#2157) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Relayer nonce collisions * Update docs/2.build/1.chain-abstraction/meta-transactions.md Co-authored-by: Damián Parrino * Update docs/2.build/1.chain-abstraction/meta-transactions.md Co-authored-by: Damián Parrino * Update meta-transactions.md * Update docs/2.build/1.chain-abstraction/meta-transactions.md --------- Co-authored-by: Damián Parrino Co-authored-by: Guille --- .../1.chain-abstraction/meta-transactions.md | 20 +++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/docs/2.build/1.chain-abstraction/meta-transactions.md b/docs/2.build/1.chain-abstraction/meta-transactions.md index 5816879abc..1de26a8831 100644 --- a/docs/2.build/1.chain-abstraction/meta-transactions.md +++ b/docs/2.build/1.chain-abstraction/meta-transactions.md @@ -106,6 +106,26 @@ 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, 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. + +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 delays, or a node picks `Tx3` first), then `Tx3` will execute, but `Tx1` and `Tx2` will fail, because they have smaller nonce! + +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. + +
+ Adding keys + +```js +const keyPair = nearAPI.KeyPair.fromRandom("ed25519"); + +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. + +
### Gating the relayer