SIMD-0162: Remove Accounts is_executable Flag Checks
#162
Conversation
|
|
||
| Error codes of these conditions, which are rarely triggered, will change. | ||
|
|
||
| The only consensus relevant change is that it will become possible (for |
There was a problem hiding this comment.
Will this change open doors for user to withdraw funds from program accounts?
There was a problem hiding this comment.
Also, it seems that this change will open doors for modifying data on executable account, and reset executable flag itself on executable account. Are there any concerns about this for consensus? Should we document the impact of these changes in the SIMD?
There was a problem hiding this comment.
Users will remain unable to: Withdraw funds from program accounts, reset the is_executable flag, or change the data directly without going through the loaders program managements instructions. That is because for that you need to be the owner, but programs are owned by a loader. Thus, the loader decides what happens to program accounts.
There was a problem hiding this comment.
Looks good. I'm just curious how buffer accounts will be handled going forward. I'm assuming that it will simply be the header of the account data UpgradeableLoaderState::Buffer, but maybe mentioning how loaders v3 and v4 distinguish between buffer accounts and programs might be useful, even if unchanged, with this flag removed.
| flag can be addressed in a subsequent proposal. Thus, the following must remain | ||
| unaffected for now: | ||
|
|
||
| - Setting of the `is_executable` flag during program deployment |
There was a problem hiding this comment.
Can we specify that this is for both loaders - v3 and v4?
There was a problem hiding this comment.
Loader-v4 will get its own SIMD explaining it in full detail.
| These checks of the `is_executable` flag are irrelevant to consensus as | ||
| transactions which try to invoke accounts, which do not contain programs, | ||
| continue to fail without them. They should still be removed because all | ||
| implementations should aim to produce the same error codes: |
There was a problem hiding this comment.
Might be worth mentioning that changing these error codes is non-consensus-breaking. It's implied here, but could be good to be specific.
No description provided.