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

SIMD-0167: Loader-v4 #167

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Conversation

Lichtso
Copy link
Contributor

@Lichtso Lichtso commented Aug 20, 2024

No description provided.

Copy link

@nickfrosty nickfrosty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also noticed there are several typos on the word "throw"

otherwise throw `UnsupportedProgramId`
- the program account is at least as long enough for the header,
otherwise throw `AccountDataTooSmall`
- the status stored in the program account is not retracted,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why would status of deployed or finalized throw an error?
should this be when the status is retracted?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The check asserts that the status is not retracted, thus only retracted throws the error.

Copy link

@topointon-jump topointon-jump left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice to see this well-written, well-specified SIMD!

Would be great to get more detail on the migration path from v3 to v4.


- loader-v3 clears the program proxy account (setting its size to zero)
- loader-v3 transfers all funds from the programdata to the proxy account
- loader-v3 gifts the program proxy account to loader-v4

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would the gifting work? Do we need to add a new instruction to the v3 loader? Will this upgrade mechanism be specified in a future SIMD?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see three options here:

  1. A migrate instruction for loader-v3 which the dApp devs trigger themselves
  2. A migrate instruction for loader-v3 which we the protocol engineers trigger
  3. A feature gate which scans the accounts DB and migrates all loader-v3 programs

I would prefer the second option as that allows us to keep the gathering of the loader-v3 program list and then slowly working through it off-chain and still makes sure that all loader-v3 programs get migrated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants