1

I am following the following tutorial:

https://dev.to/findiglay/building-a-blog-on-solana-2pg8

But in the code below it is creating seeds using the value from blog_account. I want to pass some instructions here from RPC Client side (like: id = 1)

#[instruction(post_account_bump: u8, title: String, body: String)]
pub struct CreatePost<'info> {
    #[account(mut, has_one = authority)]
    pub blog_account: Account<'info, Blog>,
    #[account(
        init,
        seeds = [
            b"post".as_ref(),
            blog_account.key().as_ref(),
            &[blog_account.post_count as u8].as_ref()   // here in place of blog_account.post_count I want to use my custom variable 
        ],
        bump = post_account_bump,
        payer = authority,
        space = 10000
    )]
    pub post_account: Account<'info, Post>,
    pub authority: Signer<'info>,
    pub system_program: Program<'info, System>
}

i have tried passing u64 value in instruction but it give me following error:

Error: failed to send transaction: Transaction simulation failed: Error processing Instruction 0: Cross-program invocation with unauthorized signer or writable account

code i used:

#[instruction(post_account_bump: u8, title: String, body: String, id: u64)]
pub struct CreatePost<'info> {
    #[account(mut, has_one = authority)]
    pub blog_account: Account<'info, Blog>,
    #[account(
        init,
        seeds = [
            b"post".as_ref(),
            blog_account.key().as_ref(),
            &[id as u8].as_ref()   // passing id in arguments from RPC call using new anchor.BN(2) 
        ],
        bump = post_account_bump,
        payer = authority,
        space = 10000
    )]
    pub post_account: Account<'info, Post>,
    pub authority: Signer<'info>,
    pub system_program: Program<'info, System>
}
3
  • Can you included the transaction logs in the description? It will narrow down which of "signer or writable" is the being erroneously escalated
    – trent.sol
    Jul 22, 2022 at 20:07
  • At the very least this the id cast from u64 to u8 sounds like a bad idea, since it would lead to the a collision (same PDA for different arguments) every 256 accounts.
    – man0s
    Jul 26, 2022 at 4:20
  • Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.
    – Community Bot
    Aug 1, 2022 at 1:44

2 Answers 2

1

With any PDA, it is important that the findProgramAddress you do on the JS side will yield exactly the same address as the Rust/Anchor does using your seeds specification:

        seeds = [
            b"post".as_ref(),
            blog_account.key().as_ref(),
            &[id as u8].as_ref()   // passing id in arguments from RPC call using new anchor.BN(2) 
        ]

Even though you haven't posted your JS code (please do), it seems unlikely the Rust and JS code come to the same address here just because of data types.

You picked u64 for the actual parameter, but are only using u8 in the seeds.

u64 is quite unwieldy to handle on the JS side because normal JS numbers are limited to u32, and you would have to use bigNum's in JS in order to pass a u64.

I recommend just using u8 for the parameter, or, if that is not possible in your case for some reason, use a u32.

And triple check that the parameters of your findProgramAddress exactly matches the seeds you specified on the Rust side.

0

Use u64 for the number seeds. It's way easier to convert to a Buffer in ts/js and will make your life easier. To get the equivalent seed on the front-end it'd just be new anchor.BN(id).toBuffer('le', 8) where id's type is a javascript number.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.