Improving ABIv1 invoke syscall

[febo]

Motivation

Currently, configuring CPI parameters in ABIv1 programs is unnecessarily cumbersome:

1. It requires passing two account slices: &[AccountMeta] and &[AccountInfo].
2. It requires converting account information received as program input into a different layout, even though the runtime subsequently converts it into yet another layout.

Both requirements force programs to allocate and copy more memory than strictly necessary. This overhead could be avoided without negatively affecting runtime performance. An AccountMeta occupies 34 bytes, while an AccountInfo occupies 56 bytes. Therefore, a program must manipulate 90 bytes per account for each CPI. This often requires heap allocation because the total size can exceed the maximum stack size of 4096 bytes, particularly given that a CPI can accept up to 255 accounts.

Proposed Solution

To address the first issue, we can eliminate one of the account slices by combining the information contained in AccountMeta and AccountInfo. The purpose of AccountMeta is to associate the writable and signer flags with an account, while AccountInfo contains the actual account information.

The second issue can be mitigated by allowing programs to simply pass a pointer to the account rather than requiring them to copy the account information into a different layout.

These two changes can be combined by defining a type that associates an account pointer with the writable/signer flags:

/// Representation of an account used in a CPI.
#[repr(C)]
pub struct CpiAccount {
    /// Pointer to the account.
    ///
    /// This is the address of the account from the program input.
    pub account_addr: *const RuntimeAccount,

    /// Indicates whether the account is writable.
    pub is_writable: bool,

    /// Indicates whether the account signed the instruction.
    pub is_signer: bool,
}

The program can then create a new CpiInstruction containing a single slice of the accounts expected by the invoked program:

/// Information about an instruction for a CPI.
#[repr(C)]
pub struct CpiInstruction {
    /// Address of the program to invoke.
    program_id: *const Address,

    /// Accounts expected by the program instruction.
    accounts: *const CpiAccount,

    /// Number of accounts expected by the program instruction.
    accounts_len: u64,

    /// Data expected by the program instruction.
    data: *const u8,

    /// Length of the data expected by the program instruction.
    data_len: u64,
}

Finally, the CpiInstruction is used as a parameter to a new invoke syscall:

pub fn sol_invoke_signed_v2(
    instruction_addr: u64,
    signers_seeds_addr: u64,
    signers_seeds_len: u64,
);

By using a CpiAccount to represent accounts, the memory requirement is reduced from 90 to 16 bytes per account, including 6 bytes of padding. The program itself copies only 10 bytes per account.

These modifications eliminate only the type conversions performed on the program side. The CPI logic in the runtime remains unchanged, apart from reading the account information through the account pointer during account translation.

Alternatives Considered

We investigated two other alternatives for simplifying CPI setup in programs. Here we present them and discuss their drawbacks.

A) Use a slice of account pointers

Account information received by an entrypoint is represented by a RuntimeAccount, which is wrapped in an AccountView, and programs written with Pinocchio receive a slice of AccountViews at their entrypoint. Rather than allocating and copying 56 bytes for each AccountInfo, a program could pass a slice of AccountViews, requiring only 8 bytes per account. This would reduce the per-account memory requirement for a CPI from 90 bytes to 42 bytes (34 + 8 bytes).

The new invoke v2 syscall would then expect accounts_addr and accounts_len to describe a slice of AccountViews:

pub fn sol_invoke_signed_v2(
    instruction_addr: u64,
    accounts_addr: u64,
    accounts_len: u64,
    signers_seeds_addr: u64,
    signers_seeds_len: u64,
);

However, this alternative does not address one of the issues described above: programs would still need to pass two account slices.

B) Use account indices instead of pointers

Another alternative is to use each account’s index in the instruction rather than a reference to the account. This would reduce the memory requirement to 4 bytes per account. To support this approach, the CpiAccount definition would use the account index and the writable and signer flags. The definitions of CpiInstruction and sol_invoke_signed_v2 would remain the same as in the proposed solution.

/// Representation of an account used in a CPI.
#[repr(C)]
pub struct CpiAccount {
    /// Index of the account in the current instruction.
    pub account_index: u16,

    /// Indicates whether the account is writable.
    pub is_writable: bool,

    /// Indicates whether the account signed the instruction.
    pub is_signer: bool,
}

The implementation could instead define this as the tuple struct CpiAccount(u32) to improve the generated bytecode.

In addition to reducing memory usage, this approach allows the CPI account list to be constructed statically at compile time when the program’s account list is deterministic. Otherwise, the program can construct it dynamically.

However, this approach would make it more difficult for helper functions to ensure that an account is not currently borrowed before a CPI. The index is not stored in an AccountView, and mapping an index to the corresponding AccountView is not straightforward. To preserve the current behavior, helper functions would need to accept both the account index and a reference to the account.

Another consideration is that, although this approach resembles ABIv2, it could cause confusion during migration because ABIv2 expects transaction account indices, while this alternative uses instruction account indices.

Benchmark

Below is a benchmark showing reductions in CU usage when setting up CPI parameters in a Pinocchio program that performs a CPI to a simple program that logs the number of accounts received. The purpose is to show the improvements during the setup of CPI parameters. All others costs of a CPI remain the same.

	CPI (8)	CPI (16)	CPI (32)	CPI (64)
invoke	1,376	1,592	1,999	2,813
invoke v2 (proposed)	1,228	1,300	1,419	1,657
A	1,257	1,337	1,472	1,742
B*	1,174	1,198	1,221	1,267
Change invoke v2 vs invoke	−11%	−18%	−29%	−41%

* Alternative B tested with static indices. When using dynamic indices, CU consumption is the
same as the proposed alternative.

In addition to reducing CU consumption, this change simplifies the API that programs use to perform CPIs.

[joncinque]

The proposed solution sounds best to me, the usability of invoke_signed has been rough since the start, so this simplification will be a huge win

[deanmlittle]

Love it. I've wanted this for years. I personally think using the account index idea is a much better approach. It can be statically allocated, results in cleaner assembly, consumes fewer CUs, and disincentivizes the anti-pattern of having variable accounts. Users will already be using indexes to pull the AccountView out of the direct account pointers once that feature goes live anyway. This also matches the behavior of instruction accounts in ABIv2. I don't see this as a major DX lift at all, especially when nothing about the existing CPI changes or breaks.