CODEWITHSUNDEEP
solana
Carles Mitjans
Carles Mitjans

Reputation: 4866

Solana Program Executable Data Account

I'm currently learning Solana development with Rust.

I'm trying to understand why do we have a Program Account and a Program Executable Data Account. I already know that the Program Account contains a reference to a Program Executable Data Account, and that the latter contains the actual code.

My question is why do we have to split the actual code from the Program Account into a separate account? My initial thoughts were:

  1. Maybe this has to do with being able to upgrade your program code. Maybe when you upgrade your program, a new Executable Data Account is created and the reference in the Program Account is updated.

That is not the case, since after upgrading a program, the reference (the address) to the Executable Data Account is the same.

  1. Maybe this has to do with ownership of accounts. Maybe one account is owned by the developer and the other by the BPF Program.

That is neither the case because both accounts are owned by the BPF Program, and the developer is just the Upgrade Authority

Why do we need 2 accounts for a program? Why not store the actual code in the data slot of the Program Account?

I hope this makes sense.

Upvotes: 1

Views: 1841

Answers (2)

Frank C.
Frank C.

Reputation: 8098

A Program account (key) is the address of the Program executable. The Program executable is where the BPF code is and it is immutable unless the owner deployed with the upgradable BPF loader:

solana program deploy ... The owner can upgrade the program using the same address

vs

solana deploy ... When you upgrade you are using a different address. This means that the original program still exists. I believe this deployment approach is being considered for removal

Whatever way you deploy, the Program does not contain any other data and of course it can't modify its own program byte code. However; Programs can operate on the data of user accounts when the user account was created with the Program ID'd as the "owner"

Upvotes: 0

Jon C
Jon C

Reputation: 8472

I'm not 100% sure if this is the reason, but it may have to do with immutability of program accounts. The runtime enforces that program accounts are totally immutable, but when you upgrade a program, the data changes, of course. By putting it all in a separate account that is updated, you can get around that restriction.

If the original account pointed to a different data account, and we swapped data accounts on upgrade, then the runtime enforcement would break, since the public key would be modified.

Upvotes: 0

Related Questions