Cure Obtuse Solana RPC Interfaces with More Anchor

[mmjp-rusty]

I've been ruminating on why Solana Program interfaces feel heavy. I think Anchor can solve this.

The Problem:

"Sensible Defaults are Impossible" with native Solana.

I think it comes down to state allocation. Solana programs either can't or don't allocate new accounts from what I can tell. Any state that the program needs created, has to be created in advance., and then passed in via the context arg as "accounts".

This forces all callers to be aware not only of the interface of a function they want to call, but also its inner implementation detail, because you have to be aware of any state that it may need to "create".

You cant then have useful overloads, wrappers or abstractions that "create all the things' For you with sensible defaults. Said another way, you can't have "simple" or "low barrier to entry" interfaces. Callers must intimately understand not just the function interface, but also its implementation, to invoke it. This steepens the learning curve and increases cognitive load/complexity.

If Sensible defaults are the cure to obtuse contracts, and sensible defaults are impossible, because state allocation is impossible, then you will have obtuse contracts.

Proposal:

This could possibly be further abstracted away by the Anchor framework. It would require you to annotate your methods, so that sensible defaults for account creation could be derived deterministically.

These derived account defaults could either be annotated with static values as their default "initial" value, or with strategies for contextually deriving defaults from other invocation args or context state. Then if the account is provided at invocation time, the provided account is used, else a default is generated using the described strategy.

e.g.

createMultisig(
      owners,
      threshold,
      nonce,
      {
        accounts: {
          multisig: multisig.publicKey,
          rent: SYSVAR_RENT_PUBKEY,
        },
        signers: [multisig],
        instructions: [
          multisigClient.account.multisig.createInstruction(
            multisig,
            size
          ),
        ],
      }
    );

Ideally this would be just

createMultisig(owners, threshold, nonce)

Accomplished by annotating

#[derive(Accounts)]
pub struct CreateMultisig<'info> {
   #[account(zero, signer)]
   multisig: Box<Account<'info, Multisig>>,
}

#[account]
pub struct Multisig {
   pub owners: Vec<Pubkey>,
   pub threshold: u64,
   pub nonce: u8,
   pub owner_set_seqno: u32,
}


pub fn create_multisig(
   ctx: Context<CreateMultisig>,
   owners: Vec<Pubkey>,
   threshold: u64,
   nonce: u8,
)

As maybe

#[derive(Accounts)]
pub struct CreateMultisig<'info> {
   #[account(zero, signer)]
   multisig: Box<Account<'info, Multisig>>,
}

#[account]
pub struct Multisig {
   pub owners: Vec<Pubkey>,
   pub threshold: u64,
   pub nonce: u8,
   pub owner_set_seqno: u32,
}

 + // Something like this: ( rough pseudo code for an example 'expression' that derives default state from args )
 + #[defaults(multisig: RentExemptAccount(@vec(@param(owners).type,@param(owners).count+2,@param(owners)),@param(threshold),@param(nonce),@empty(u32)]
pub fn create_multisig(
   ctx: Context<CreateMultisig>,
   owners: Vec<Pubkey>,
   threshold: u64,
   nonce: u8,
)

The idea is that then the anchor client code, generates an overload of "createMultisig" that requires only the the non "context" input args, but spits out multiple instructions instead of just one, to issue both the pre-allocation of the account, and the subsequent create multisig call. It also also generates a keypair for the accounts it generated, and includes that with a result wrapper in it's promise output.

[mmjp-rusty]

Another good example is candy machine.

All of this length information should be declared in the IDL. If it were declared as an expression, derived from params and compile time known constants, then the pre-allocation of the account can be auto generated.

const MAX_NAME_LENGTH = 32;
const MAX_URI_LENGTH = 200;
const MAX_SYMBOL_LENGTH = 10;
const MAX_CREATOR_LEN = 32 + 1 + 1;
const MAX_CREATOR_LIMIT = 5;

    const size =
     8 + // key
  32 + // authority
  32 + //wallet
  33 + // token mint
  4 +
  6 + // uuid
  8 + // price
  8 + // items available
  9 + // go live
  10 + // end settings
  4 +
  MAX_SYMBOL_LENGTH + // u32 len + symbol
  2 + // seller fee basis points
  4 +
  MAX_CREATOR_LIMIT * MAX_CREATOR_LEN + // optional + u32 len + actual vec
  8 + //max supply
  1 + // is mutable
  1 + // retain authority
  1 + // option for hidden setting
  4 +
  MAX_NAME_LENGTH + // name length,
  4 +
  MAX_URI_LENGTH + // uri length,
  32 + // hash
  4 + // max number of lines;
  8 + // items redeemed
  1 + // whitelist option
  1 + // whitelist mint mode
  1 + // allow presale
  9 + // discount price
  32 + // mint key for whitelist
  1 +
  32 +
  1; // gatekeeper +
      4 +
      @params(candyData.itemsAvailable.toNumber()) * (4 + 32 + 4 + 200) +
      8 +
      2 * (Math.floor(@params(candyData.itemsAvailable.toNumber()) / 8) + 1);