Purpose of the bump when pda initialization in anchor

Viewed 789

I'm trying to write a simple Solana Program using Rust/Anchor which uses a PDA.

Here is the Program code:

use anchor_lang::prelude::*;

declare_id!("51v31qHaEQniLoYuvvtXByZcfiyvog3R2EKC39EPD52p");

#[program]
pub mod solana_sandbox {
  use super::*;
  pub fn initialize(ctx: Context<Initialize>, bump: u8) -> ProgramResult {
    ctx.accounts.sandbox_account.bump = bump;
    Ok(())
  }
}

#[derive(Accounts)]
#[instruction(bump: u8)]
pub struct Initialize<'info> {
  #[account(mut)]
  pub signer: Signer<'info>,
  #[account(
    init,
    seeds = [b"seed".as_ref()],
    bump,
    payer = signer,
  )]
  pub sandbox_account: Account<'info, SandboxAccount>,
  pub system_program: Program<'info, System>,
}

#[account]
#[derive(Default)]
pub struct SandboxAccount {
  pub bump: u8,
}

Here is the client code:

const [sandboxPda, sandboxBump] = await PublicKey.findProgramAddress([Buffer.from('seed')], this.program.programId);

  await program.rpc.initialize(
    sandboxBump,
    {
      accounts: {
        signer: keypair.publicKey,
        sandboxAccount: sandboxPda,
        systemProgram: anchor.web3.SystemProgram.programId,
      },
      signers: [keypair],
      instructions: []
    });

It works correctly, but I have a doubt. I get sandboxBump from findProgramAddress and input this but it isn't used.

If I set bump when init like this :

#[account(
  init,
  seeds = [b"seed".as_ref()],
  bump = bump,
  payer = signer,
)]

Error occurred. So I delete the instruction macro from the program code but it still works correctly. So is bump value no need when PDA initialization or does anchor system use it automatically?

Appreciate any help!

2 Answers

For enhanced security Solana makes sure all the Program Address will not lie on the ed25519 curve. As the address is not on the curve there will no be associated private key hence no risk.

For generating program address solana uses 256-bit pre-image resistant hash function using collection of seeds and a program id as input, as it's output can't be predicted in advance and can't be controlled in any manner there is 50% chance of newly generated address will lie on ed25519 curve. In such case where generated address is on curve, which is prohibited by solana. Solana will use a different set of seeds or a seed bump to find a valid address (address off the curve).

In short bump will be used only in case where provided input doesn't generate a valid program address.

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.

references:

PDA's are used to sign transactions in Solana. when you sign a transaction you need to have a secret key to prove that you own the associated address. But for a program to hold the private key is not ideal because the program lives on-chain and everybody can look on-chain. so storing the private key on-chain is not a good idea because everyone else can steal the private key. that is why we need those PDAs. Because with Pda, the program can prove that it is allowed to sign the transaction. when do you need PDA? let's say you have a treasury of tokens and you want to send some tokens from that treasury to another address. the program can approve this by signing with seed and bump seed and system program id to tell the system program to transfer the sol.

enter image description here

  • WE ARE ACTUALLY LOOKING FOR A PUBLIC KEY THAT CANNOT BE DERIVED FROM A SECRET KEY

  • PDAs ensure that no external user could also generate a valid signature for the same address

Our pda's should not be on the elliptic curve. If it is, then we use bump seeds. so our smart contract will try I think upto 20 times to create a unique hash using a new bump seed each time.

It starts with bump = 255 and simply iterate down through bump = 254, bump = 253, etc. until we get an address that is not on the elliptic curve. T

Related