Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(svm): L-05 comment on efficient handler_signer PDA derivation #846

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

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.

Copy link

linear bot commented Jan 8, 2025

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.

3 participants