Demonstrate program upgrades

solana-labs / solana

Web-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.

https://solanalabs.com

Apache License 2.0

13.35k stars 4.35k forks source link

Demonstrate program upgrades #1530

Closed garious closed 3 years ago

garious commented 6 years ago

[ ] Distinguish bpf-based upgrades from native-based upgrades. Do we want to migrate all programs to bpf or add a governance model around trusting upgrades to native programs?
[ ] Demonstrate voluntary upgrade where a client uses its signature to authorize a program_id re-assignment of an account it controls, such as an erc20 account.

garious commented 6 years ago

@jackcmay, looking in your general direction for this one.

mvines commented 6 years ago

I realized that right now a program can be "upgraded"/"replaced" by allowing it to self-destruct by forcing the program account's tokens to 0, and then re-loading a new program into the account. Still thinking about whether this is something nice or not.

But in either case, this kind of "upgrade" wouldn't be atomic and program users would see transaction failures during this time (and at the moment be charged the transaction fee if I'm reading bank.rs right). If we like this kind of an "upgrade", then we should at least ensure transactions that are rejected during this window do not take the fee.

mvines commented 6 years ago

So I think the “feature” discussed in previous comment should be considered harmful and prohibited. If the loader of the program can yank and replace it at any time, they essentially have full access to all tokens that have ever been assigned to that program. This means that whenever an executable account hits zero tokens, that program_id probably should be blacklisted. Unfortunately this would mean that tokens in accounts owned by that program_id are unrecoverable. This doesn’t seem great. Alternatively an executable account lives forever?

garious commented 6 years ago

I don't think we want executable accounts to live forever. They're probably the ones we least want to live forever, since they are very useless one a program's been upgraded. Also, they're likely going to be some of the largest accounts.

garious commented 6 years ago

I think we can optimize for blacklisted account keys. It's not a route I'm really excited about, but feels least bad at the moment.

mvines commented 5 years ago

(302 to v0.12, I'm quite sure I won't have bandwidth to complete this issue in the next couple days)

stale[bot] commented 4 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

jackcmay commented 3 years ago

Stale given upgradeable loader was released in v1.4.23