Produce an RFC that discusses how programs are loaded on-chain

[mvines]

Rough stetch:

we need to break up the elf into packets, push them into the chain
so, i think that is a contract as well
1. user allocates memory
2. user assigns memory to loader contract
3. user submits tx's with user_data that gets written to memory
4. user calls execute, we do the mmap entry point magic

[jackcmay]

To load and call a program we could follow a similar approach as the wallet does when performing budget transactions:

1. Create a new program account that will be used to store the program's bits
2. Create a new instance account and populate it with the program's state (e.g., tic tac toe Game)
3. Interact with the program by sending Call transactions referencing the program and state accounts by key and with program inputs as the transaction's userdata (instruction).

• Call data (new inputs) might also need to be chunked. The below example assumes that the program and instance would be broken up and sent to the network in chunks.

Flow could look like this:

tx = Transaction::system_create (
  my_pubkey,
  program_pubkey,
  last_id,
  tokens,
  size_of_program,
  fee,
};
send_tx(tx);

tx = Transaction::program_load (
  my_pubkey,
  program_pubkey,
  last_id,
  offset_of_chunk,
  size_of_chunk,
  chunk,
};
sent_tx(tx);

// repeat until program fully loaded

At this point, the program is fully loaded. The user would then create a new instance (account) that contains the program state. Program state would typically start with an initial state (empty tic tac toe game, etc...), but that's not required, a user could use whatever state they wanted (prior game state for example)

tx = Transaction::system_create (
    my_pubkey,
    instance_pubkey,
    last_id,
    tokens,
    size_of_state,
    fee,
);
send_tx(tx);

tx = Transaction::program_load_instance (
    my_pubkey,
    instance_pubkey,
    last_id,
    offset_of_chunk,
    size_of_chunk,
    chunk,
);
send_tx(tx);

// repeat until instance data is fully populated

At this point, the program is fully loaded, and a fully populated instance has been created. The users then send transactions with inputs.

tx = Transaction::program_call (
    my_pubkey,
    program_pubkey,
    instance_pubkey,
    last_id,
    size_of_input,
    input,
);
send_tx(tx);

// repeat until program completes

When the program_call transaction is handled, Solana will load the program into an instance of the VM and then send it the instance account and the input data from the transaction. The program would run, modify instance state, and return, at which time Solana would update the instance account with the resulting new state.

Any combination of multiple programs and multiple instances could be supported. For example, an existing program might be loaded and have multiple running instances. A new version of the program could be loaded, and multiple instances could be started concurrently.

Some outstanding questions:

• Do we care to enforce compatibility between program and state?
• This proposal does not cover lifetimes of programs, instances, etc... which would need to be tied to an economics proposal.
• We don't want to remove the program account until all instance accounts have been removed. How do we tie the lifetime of the program to the lifetime of the instances? Might need some budget operation to handle this?
• Need to establish details of how chunking would work (concepts like retry, flow control, etc...)
• This proposal does not include anything about how users discover already running programs, how those programs are versions, etc...

[mvines]

Effectively done