Description

In the SendKeyshare function, each keyshare transaction triggers two calls to this function. The first call occurs during the simulate stage, where SendKeyshare is called to precheck the transaction's validity without affecting the blockchain state. The second call happens during the execution stage when the transaction is actually applied to the blockchain state within a block.

The issue arises if the block height coincides with an Epoch switch. In this case, the Epoch data used during the checkTx stage and the execution stage may be inconsistent, causing the checkTx stage to use outdated commitments data to verify a new Epoch's keyshare. This discrepancy results in misleading error logs.

Consider two Epochs: Epoch A ends at block 70, and Epoch B starts at block 71. At block 70, fairyringclient submits a keyshare transaction intended for block 71, meaning it should use Epoch B's commitments for verification.

During the checkTx stage. At block 70, the checkTx stage is still using Epoch A's commitments in SendKeyshare. When it verifies this keyshare transaction against Epoch B's keyshare, it fails to match and generates an error log indicating keyshare verification failed.

During the executions stage. At block 71, the transaction is included in a block and applied to the blockchain state. By this time, BeginBlock has switched the Epoch to Epoch B and updated the keyshare module's data. In this stage, SendKeyshare is called again, this time correctly using Epoch B's commitments, so no error log is generated.

Impact

This issue generates misleading error logs during the checkTx stage, suggesting keyshare verification failures even for valid transactions, which complicates debugging and consumes resources.

Recommendations

Enhance the logic in the checkTx stage to ensure that if the keyshare transaction height belongs to the next Epoch, the queued commitments are used for verification.

Remediation

This issue has been acknowledged by Fairblock Inc., and a fix was implemented in commit 5b830510↗.