SIMD-0433: Loader V3: Set Program Data to ELF Length

[buffalojoec]

No description provided.

[simd-bot]

Hello buffalojoec! Welcome to the SIMD process. By opening this PR you are affirming that your SIMD has been thoroughly discussed and vetted in the SIMD discussion section. The SIMD PR section should only be used to submit a final technical specification for review. If your design / idea still needs discussion, please close this PR and create a new discussion here.

This PR requires the following approvals before it can be merged:

• At least one approval from a Anza team member: t-nelson, sakridge, or bw-solana
• At least one approval from an Firedancer team member: ptaffet-jump, topointon-jump, 0x0ece, lidatong, or ripatel-fd

Once all requirements are met, you can merge this PR by commenting /merge.

[Lichtso]

How does this interact with #164? Or rather, why require an ExtendProgram instruction at all and not have that be automatic in Upgrade instead of failing if the account is too small? Obviously the required funds would still have to be deposited before hand.

[Lichtso]

IIRC Breakpoint we discussed the alternative workflow in which programs which want to self upgrade to a larger ELF would reassign their authority to a TX fee payer temporarily, then upgrade at top-level (to avoid the 10 KiB CPI account growth limit of ABI v1) and reassign back to the original authority, all with the atomicity of a single TX.

[buffalojoec]

This proposal is just simply the lightest lift to solve the issue of excess space and lamports. It's trivial: existing workflows already resize the account to be large enough for the ELF, but there's no way to reclaim excess if you overshoot it.

If we want to go all the way we can. My main concern would be what happens to any existing workflows that use ExtendProgram. Would we continue to support the instruction, perhaps post-#431, so as to not break anyone's flows? Or, since #431 is already breaking, do we just close #431 and make all resizing part of the upgrade?

[Lichtso]

we just close #431 and make all resizing part of the upgrade

That is what I was saying: "have that be automatic in Upgrade".

[buffalojoec]

In my opinion, we should keep this SIMD focused on addressing the core issue, which is the inability to reclaim lamports for an oversized programdata account. I don't think we should bloat the change with more complexity at this time. If we want to add another step to enable more automation within the upgrade workflow and move away from Extend*, it's pretty trivial to do so in the future. However, nobody has asked for this afaik.

IIRC Breakpoint we discussed the alternative workflow in which programs which want to self upgrade to a larger ELF would reassign their authority to a TX fee payer temporarily, then upgrade at top-level (to avoid the 10 KiB CPI account growth limit of ABI v1) and reassign back to the original authority, all with the atomicity of a single TX.

This sounds a little more hacky than it's worth just to avoid having to best-guess a size increase before running an upgrade. If we bake in resizing, you'll still have to best-guess the new size anyway, in order to top up rent. Seems like a small marginal benefit overall IMO.

[Lichtso]

This sounds a little more hacky than it's worth just to avoid having to best-guess a size increase before running an upgrade.

This was not about guessing the size at all. It was about not being able to upgrade to larger programs in a single instruction, no matter if it is done in Extend or Upgrade, both are limited to +10 KiB in CPI of ABI v1.

[buffalojoec]

This sounds a little more hacky than it's worth just to avoid having to best-guess a size increase before running an upgrade.

This was not about guessing the size at all. It was about not being able to upgrade to larger programs in a single instruction, no matter if it is done in Extend or Upgrade, both are limited to +10 KiB in CPI of ABI v1.

I think you misunderstood my comment. I'm not implying you were describing the act of guessing the size. I'm saying the workflow you outlined would be required if we decided to handle both resizing events automatically via Upgrade. The goal of doing such a thing would be to avoid the extra step whereby developers must know their new program size ahead of time. My point is that - even if we get rid of ExtendProgram completely - devs will always have to know the new size of their program in order to top up rent, so the point is moot IMO.

[Lichtso]

Yes, we are on the same page and I understood your comment as such: "even if we get rid of ExtendProgram completely - devs will always have to know the new size of their program in order to top up rent, so the point is moot IMO" agreed, and I did not bring it up as a reason.

The reasons (for handling the size changes in Upgrade) are:

• To avoid having to deal with changes to ExtendProgram (such as SIMD-0431) which has been controversial in the past (see SIMD-0164).
• To have both size increases and decreases handled in a unified matter, instead of having one be implicit and the other explicit.
• To have only one instruction change the size, so that the CPI account size increase limit of ABI v1 only needs to be dealt with once per TX.

[buffalojoec]

I'm willing to adjust the proposal to support bidirectional resizing, but I don't think we should eliminate ExtendProgram/ExtendProgramChecked in this proposal.

We should seek more opinions from stakeholders on the solution you described earlier in this thread - temporarily changing the authority to avoid the 10KiB CPI limit in ABI v1 - and route the feedback into SIMD-0431 or SIMD-0164.

[mjain-jump]

lgtm!