[experimental] Decoding and then re-compiling a transaction invalidates existing signatures

[mcintyre94]

Overview

If we have a transaction that has been partially signed, and we decode it using the new web3js and then call compileMessage, the existing signature may not be compatible with the newly compiled message. This is because of the new more deterministic account ordering used in the experimental web3js

Steps to reproduce

Codesandbox: https://codesandbox.io/p/devbox/web3js-account-ordering-xmxrxm (node index.mjs)

This repro creates and signs a transaction with the legacy web3js. It then decodes + recompiles the transaction message using the new web3js, and verifies the signature before and after

Description of bug

• If we decode a transaction with an existing accounts array then I think we need to keep it the same, to ensure the compiled message.

Suggested fix:

• Add a field to the Transaction model eg orderedAccounts
• There should be no way exposed to set that field, it should only be used when we decode an existing transaction. Also probably only set it if there are existing signatures
• If we do anything that already invalidates signatures (like adding an instruction), we should also strip this field
• When we compile the message, if this field is set then we should use it instead of our deterministic account ordering

[github-actions]

🎉 This issue has been resolved in version 1.91.4 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[mcintyre94]

^ Nope