Skip to content

SIMD-0186: Clarify program/loader validation #311

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions proposals/0186-loaded-transaction-data-size-specification.md
Original file line number Diff line number Diff line change
Expand Up @@ -114,6 +114,39 @@ Account size for programs owned by LoaderV4 is left undefined. This SIMD should
be amended to define the required semantics before LoaderV4 is enabled on any
network.

### Sidebar: Program ID and Loader Validation

After all accounts are loaded, if the transaction's size comes at or under its
loaded accounts data size limit, the program IDs of each instruction, along with
their program owners, are validated. This process is not part of determining
loaded transaction data size, but it is part of account loading (and consensus),
and it is not explicitly defined elsewhere. So we define it here.

The process is as follows; for each instruction's program ID:

* Verify the account exists. Otherwise, return `ProgramAccountNotFound`.
* Verify the program account's owner is one of:
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here, can you add the expected error if this check fails? (InvalidProgramForExecution)

Copy link
Member Author

Choose a reason for hiding this comment

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

* `NativeLoader1111111111111111111111111111111`
* `BPFLoader1111111111111111111111111111111111`
* `BPFLoader2111111111111111111111111111111111`
* `BPFLoaderUpgradeab1e11111111111111111111111`
* `LoaderV411111111111111111111111111111111111`

Otherwise, return `InvalidProgramForExecution`.

If either of these conditions are violated, loading is aborted and the
transaction pays fees.

Previously, instead of a hardcoded list of valid loaders, the program owner was
loaded and verified to be executable and itself owned by
`NativeLoader1111111111111111111111111111111`. This is undesirable because there
are many programs which match this criteria but are in fact not program loaders.

Previously, all checks were skipped if the program ID was
`NativeLoader1111111111111111111111111111111` itself. This special case has been
removed, and `NativeLoader1111111111111111111111111111111` behaves like any
other account.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think we should also say that previously the program id's owner was validated by checking if it was equal to the native loader or, if not, was loaded and validated by checking that it was executable and that the owner's owner == native loader.

## Alternatives Considered

* Transaction data size accounting is already enabled, so the null option is to
Expand Down
Loading