2-second receipt wait plus nonce cancel-on-timeout in blockchain publisher causes spurious publish errors and retry churn

[neekolas]

Severity: Low | Likelihood: Medium | Impact: Low | Type: Vulnerability

Details

The blockchain publisher waits only 2 seconds for transaction receipts and cancels the reserved nonce on any wait error, leading to spurious client errors, a one-time nonce reuse that triggers a replacement-underpriced send, and short backoffs while waiting for the earlier tx to confirm.

All publish paths use a hardcoded 2-second WaitForTransaction timeout. If the receipt is not available within 2 seconds, the publisher treats it as an error and cancels the reserved nonce, returning it to the pool. A subsequent attempt can reuse that nonce while the first tx remains pending, producing a "replacement transaction underpriced" or "nonce too low" error, after which the nonce is consumed and the publisher advances to the next nonce (which cannot be accepted until the earlier one confirms). The payer API returns an error to the client on the 2-second timeout, even if the transaction is mined shortly afterward.

Exploitation

Scenario 1

Natural slow confirmation: A client publishes a commit. The tx broadcasts successfully, but the chain/provider does not return a receipt within 2 seconds. The publisher cancels the nonce and returns an error to the client. A quick retry reuses the nonce once, triggers a replacement-underpriced error, consumes that nonce, and advances to the next while short backoffs continue until the first tx confirms.

Preconditions / Assumptions:

• (a) Gateway runs with publisher using a 2-second receipt wait and cancel-on-wait-error behavior
• (b) AppChain or RPC provider occasionally takes more than 2 seconds to return a receipt
• (c) Client publishes a commit that routes to on-chain publishing

Scenario 2

Flaky or adversarial RPC provider: The gateway's RPC provider accepts broadcasts but consistently delays or drops receipt queries beyond 2 seconds. Each publish returns an error, clients retry, and the publisher repeatedly handles nonce reuse and short backoffs while earlier txs confirm, resulting in significant perceived unavailability.

Preconditions / Assumptions:

• (a) Gateway uses a single flaky or adversarial RPC provider
• (b) Provider accepts broadcasts but delays or drops TransactionReceipt responses beyond 2 seconds
• (c) Clients submit on-chain publishes via the gateway

Scenario 3

Underpriced first transaction plus short wait: The oracle underestimates gas or the network is congested, so the first tx remains pending beyond 2 seconds. The publisher returns an error and cancels the nonce. Subsequent publishes encounter one-time underpriced replacement, consume the nonce, and then back off until the first tx is mined.

Preconditions / Assumptions:

• (a) Gas oracle underestimates gas or network is congested leading to a long-pending first tx
• (b) Publisher uses a 2-second receipt wait and cancels nonce on wait error
• (c) Multiple commits arrive while the first tx is still pending

Files impacted

• pkg/blockchain/blockchain_publisher.go

Lines 188-192 (hardcoded 2-second timeout):

m.logger, m.client,
2*time.Second,
250*time.Millisecond, transaction.Hash(),