The Solana runtime allows programs to call each other via a mechanism called cross-program invocation. Calling between programs is achieved by one program invoking an instruction of the other. The invoking program is halted until the invoked program finishes processing the instruction.
For example, a client could create a transaction that modifies two accounts, each owned by separate on-chain programs:
A client may instead allow the
acme program to conveniently invoke
instructions on the client's behalf:
Given two on-chain programs,
acme, each implementing instructions
acme can be implemented with a
call to a function defined in the
token module by issuing a cross-program
invoke() is built into Solana's runtime and is responsible for routing the
given instruction to the
token program via the instruction's
invoke requires the caller to pass all the accounts required by the
instruction being invoked, except for the executable account (the
pay(), the runtime must ensure that
acme didn't modify any
accounts owned by
token. It does this by applying the runtime's policy to the
current state of the accounts at the time
invoke vs. the initial
state of the accounts at the beginning of the
acme's instruction. After
pay() completes, the runtime must again ensure that
token didn't modify any
accounts owned by
acme by again applying the runtime's policy, but this time
token program ID. Lastly, after
completes, the runtime must apply the runtime policy one more time where it
normally would, but using all updated
pre_* variables. If executing
pay_and_launch_missiles() up to
pay() made no invalid account changes,
pay() made no invalid changes, and executing from
pay_and_launch_missiles() returns made no invalid changes, then the runtime
can transitively assume
pay_and_launch_missiles() as a whole made no invalid
account changes, and therefore commit all these account modifications.
The runtime uses the privileges granted to the caller program to determine what privileges can be extended to the callee. Privileges in this context refer to signers and writable accounts. For example, if the instruction the caller is processing contains a signer or writable account, then the caller can invoke an instruction that also contains that signer and/or writable account.
This privilege extension relies on the fact that programs are immutable, except during the special case of program upgrades.
In the case of the
acme program, the runtime can safely treat the transaction's
signature as a signature of a
token instruction. When the runtime sees the
token instruction references
alice_pubkey, it looks up the key in the
instruction to see if that key corresponds to a signed account. In this case, it
does and thereby authorizes the
token program to modify Alice's account.
Programs can issue instructions that contain signed accounts that were not signed in the original transaction by using Program derived addresses.
To sign an account with program derived addresses, a program may
Cross-program invocations allow programs to invoke other programs directly, but the depth is constrained currently to 4.
Reentrancy is currently limited to direct self recursion, capped at a fixed depth. This restriction prevents situations where a program might invoke another from an intermediary state without the knowledge that it might later be called back into. Direct recursion gives the program full control of its state at the point that it gets called back.
Program derived addresses allow programmatically generated signatures to be used when calling between programs.
Using a program derived address, a program may be given the authority over an account and later transfer that authority to another. This is possible because the program can act as the signer in the transaction that gives authority.
For example, if two users want to make a wager on the outcome of a game in Solana, they must each transfer their wager's assets to some intermediary that will honor their agreement. Currently, there is no way to implement this intermediary as a program in Solana because the intermediary program cannot transfer the assets to the winner.
This capability is necessary for many DeFi applications since they require assets to be transferred to an escrow agent until some event occurs that determines the new owner.
Decentralized Exchanges that transfer assets between matching bid and ask orders.
Auctions that transfer assets to the winner.
Games or prediction markets that collect and redistribute prizes to the winners.
Program derived address:
Allow programs to control specific addresses, called program addresses, in such a way that no external user can generate valid transactions with signatures for those addresses.
Allow programs to programmatically sign for program addresses that are present in instructions invoked via Cross-Program Invocations.
Given the two conditions, users can securely transfer or assign the authority of on-chain assets to program addresses, and the program can then assign that authority elsewhere at its discretion.
A program address does not lie on the ed25519 curve and therefore has no valid private key associated with it, and thus generating a signature for it is impossible. While it has no private key of its own, it can be used by a program to issue an instruction that includes the program address as a signer.
Program addresses are deterministically derived from a collection of seeds and a program id using a 256-bit pre-image resistant hash function. Program address must not lie on the ed25519 curve to ensure there is no associated private key. During generation, an error will be returned if the address is found to lie on the curve. There is about a 50/50 chance of this happening for a given collection of seeds and program id. If this occurs a different set of seeds or a seed bump (additional 8 bit seed) can be used to find a valid program address off the curve.
Deterministic program addresses for programs follow a similar derivation path as
Accounts created with
SystemInstruction::CreateAccountWithSeed which is
For reference, that implementation is as follows:
Programs can deterministically derive any number of addresses by using seeds. These seeds can symbolically identify how the addresses are used.
Clients can use the
create_program_address function to generate a destination
address. In this example, we assume that
create_program_address(&[&["escrow"]], &escrow_program_id) generates a valid
program address that is off the curve.
Programs can use the same function to generate the same address. In the function
below the program issues a
token_instruction::transfer from a program address
as if it had the private key to sign the transaction.
Note that the address generated using
create_program_address is not guaranteed
to be a valid program address off the curve. For example, let's assume that the
"escrow2" does not generate a valid program address.
To generate a valid program address using
"escrow2" as a seed, use
find_program_address, iterating through possible bump seeds until a valid
combination is found. The preceding example becomes:
Within the program, this becomes:
find_program_address requires iterating over a number of calls to
create_program_address, it may use more
compute budget when
used on-chain. To reduce the compute cost, use
and pass the resulting bump seed to the program.
The addresses generated with
are indistinguishable from any other public key. The only way for the runtime to
verify that the address belongs to a program is for the program to supply the
seeds used to generate the address.
The runtime will internally call
create_program_address, and compare the
result against the addresses supplied in the instruction.