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-0163: Lift the CPI caller restriction #163

Merged
merged 2 commits into from
Nov 25, 2024
Merged
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
103 changes: 103 additions & 0 deletions proposals/0163-lift-cpi-caller-restriction.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,103 @@
---
simd: '0163'
title: Lift the CPI caller restriction
authors:
- Alexander Meißner
category: Standard
type: Core
status: Draft
created: 2024-07-16
feature: TBD
---

## Summary

Remove the check which forces CPI callers to have the program account of the
callee available to them as an instruction account.

## Motivation

The restriction is purely historical and not necessary for the protocol or its
implementations.

Removing it would improve composability and reduce transaction building
complexity because program accounts would no longer be passed all the way from
transaction level instructions to the inner most CPI instructions.

Additionally, not passing these program accounts is a significant reduction in
data copied during serialization as program accounts of loader v1, v2 and v4
contain the entire 10 MB ELF. This massively reduces the CU cost for nested CPI
and disincentivizes programs from accessing program accounts, which could later
allow us to remove program loading from transaction loading.

### Example transaction

- Accounts:
- Fee payer
- Caller Program
- Callee Program
- Token
- Transaction-level instruction:
- Program Account: Caller Program
- Instruction Accounts:
- **Callee Program** (this could be removed)
- Token
- CPI:
- Program Account: Callee Program
- Instruction Accounts:
- Token

Currently, in order to be used as a program account for a nested instruction
the callee program must be passed as an instruction account to all outer
instructions recursively.
buffalojoec marked this conversation as resolved.
Show resolved Hide resolved

## New Terminology

None.

## Detailed Design

In CPI a feature gate must switch the search for the program id of the callee
from the instruction accounts of the caller to the account list of the
transaction.

Invoking a program in CPI which was un/re/deployed in the same transaction is
prevented by the "delay visibility" feature and thus unproblematic.
buffalojoec marked this conversation as resolved.
Show resolved Hide resolved

## Alternatives Considered

None.

## Impact

See motivation.

Dapp developers who wish to benefit from the lifting of the restriction shall:

- Hard-code the callee address in the CPI call, in case they want a static
dispatch
- Use the instruction **data**, not instruction **accounts**, to receive the
callee address as a parameter, in case they want a dynamic dispatch

Transaction building should append the required program accounts, which are not
passed as instruction accounts, at the end of the transaction accounts list.
How the dapps describe which callee prorgams they require to be present in the
transaction is explicitly left unspecified.

## Security Considerations

None.

## Backwards Compatibility

Programs remain unaffected the way they are, unless they want to profit from
this change. In that case they can do one of the following:

Existing programs, which have hard-coded the callee statically and only need it
as any instruction account to satisfy the constraint imposed by the runtime,
can be fed a placeholder like `NativeLoader1111111111111111111111111111111`, in
buffalojoec marked this conversation as resolved.
Show resolved Hide resolved
order not to shift the indices of the other instruction accounts.

All other existing programs, which dynamically call whatever is passed in a
specific instruction account will have to be updated and redeployed to benefit
from the lifting of the restriction.
Loading