Variable seeds for PDA

Question

I am trying to initialize a PDA using the u64 value stored in another account. The idea is that the stored counter increments and the value determines the seed.

My code:

#[derive(Accounts)]
pub struct PdaInit<'info> {
    /// CHECK: Just testing
    #[account(mut)]
    pub payer: Signer<'info>,
    pub rent: Sysvar<'info, Rent>,
    pub system_program: Program<'info, System>,

    #[account(init, seeds = [b"seeds".as_ref(), stored_counter_pda.counter.to_be_bytes().as_ref()], bump, payer=payer, space = 100)]
    init_pda: Account<'info, SomeStruct>,

    #[account(mut, seeds = [b"seeds".as_ref()], bump)]
    stored_counter_pda: Account<'info, StoredCounter>,
}

#[account]
#[derive(Default)]
pub struct StoredCounter{
    pub counter: u64,
}

The problem is that I also have to pass the init_pda from the Client, so I need the seed, and I don't know if fetching the stored value of the other PDA is the correct way to deal with this. Supposing that several users on the client side send the instruction to initialize the pda at the same time, if I fetch the counter, I will get the same value for every user and only one user will get a succesfull result on the transaction.

Any help will be appreciated. Thanks.

Answer 1

Your design as proposed just fundamentally has that race condition in it. If another user beats you to instantiating Account #123, your attempt to do so will fail and you'll have to try again with #124.

There's no way around the fact that you'll need to know all the needed addresses (and surely an address you're initializing is one you need) before you construct and sign the transaction. This is a hard fact about how Solana works.

And given that you're basing your PDA derivation off of an on-chain mutable value, any mutation of that blockchain state necessarily changes the PDA. And your client can never know just if or when another client is out there about to mutate state...

Answer 2

The only possible way I can think is to divide the init_pda creation into two transactions.

The first transaction will do the following things:

1. It will increment the counter in 'stored_counter_pda' account.
2. creates a separate account, let's say, 'user_info' with two fields - counter and publickey.
3. saves the incremented counter value in the counter field and the key of the signer in the publickey field.

The second transaction will do the following things:

1. checks if the signer of the transaction is same as publickey in user_info account.
2. if yes, allows the creation of 'init_pda' account with the value of the counter saved in user_info account.

If you want to allow the user to create only one init_pda account then assign user_info account to the PDA derived using user's public key. In that way, he can make the first and second transactions only once. Conversely, if the users can create more than one init_pda then simply assign user_info account to a newly generated keypair.

The drawback of the above method is that a user can run the first transaction without running the second transaction which will increment the counter but won't create the adjacent init_pda account. But this drawback can easily be handled in the front-end depending upon the need of your dApp.

On the brighter side, the above method ensures that every user will get unique counter value. Furthermore, any number of users can concurrently call the first transaction and each will go successful and the second transaction can be called anytime without effecting the counter value received by the other users.