Skip to content

Conversation

@Reinis-FRP
Copy link
Contributor

OZ identified following issue:

The handle_v3_across_message function within multicall_handler relies on find_program_address to derive the public key of a PDA and its canonical bump value, using a seed and the program ID. The find_program_address function computes a valid PDA by calling create_program_address iteratively, starting with a bump of 255 and decrementing the bump until a valid address is found. While this ensures that a valid PDA is derived, the iterative process is computationally expensive, which is problematic, particularly in functions like handle_v3_across_message that may execute multiple instructions. If not optimized, this approach risks exceeding the compute budget.

To mitigate this issue, consider storing the derived bump value in an account's data field upon initialization. This approach enables subsequent instructions to reuse the stored bump, eliminating the need for repeated calls to find_program_address.

Storing the bump would require passing additional state account with HandleV3AcrossMessage. The depositor should then encode the message by prepending this state account to all other accounts required for all inner CPIs, but that would not be compatible with lamports value transfers to the first account when value > 0. To resolve that would require extending the AcrossPlusMessage struct to distinguish between static accounts that are passed to handle_v3_across_message (currently we have none) from all remaining accounts that are used in inner CPIs. This would mean longer message size and more complexity for both the depositors and fillers.

As an alternative measure, it is proposed for the deployer to choose such handler program ID so to minimize the resulting computational cost of finding the PDA for the handler_signer making sure that its bump is the maximum value of 255. This PR adds a comment on program ID on this consideration.

Signed-off-by: Reinis Martinsons <reinis@umaproject.org>
@linear
Copy link

linear bot commented Jan 8, 2025

@Reinis-FRP Reinis-FRP merged commit 011f69e into master Jan 23, 2025
9 checks passed
@Reinis-FRP Reinis-FRP deleted the reinis/acx-3585-l-05-inefficient-pda-derivation-in-handle_v3_across_message branch January 23, 2025 16:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants