Closed jacksondoherty closed 2 weeks ago
Hey @jacksondoherty thanks for the suggestion. This is actually something we'd have to change on the validator - specifically within the transaction processing pipeline - not Web3.js.
RPC's simulate_transaction
will use a Bank instance to run a simulation against the transaction processing pipeline. Sigverify happens before this pipeline is invoked, so it's trivial to disable sigverify using the aptly-named RPC parameter.
Within Bank, this isn't really super configurable (at the moment).
However, the SVM API does allow for quite a bit of customization. I wonder if we can kill two birds with one stone here.
We might be able to make fees completely configurable within the SVM (transaction processing pipeline), similar to rent collection. Then, we could add a handful of new configurations to the RPC's simulate method - one of which could be to disable fee payer checks completely, by configuring fees to be zero.
Alternatively, we can just jam a check_fee_payer
into the SVM API's parameters, similar to your suggestion here.
Side note: I wonder how strongly RPC providers would throw their support behind no-fee program view functions through simulation... 😅
Hm it seems fairly involved to do it the "correct way."
The "hacky" solution makes more sense then since it still fully meets requirements. I imagine it's possible to create some sort of community public key that you can prove is randomly generated and nobody owns – perhaps inside a smart contract – and then send it a little dust. Use that inside the library functions.
Not sure if that's something you'd want in the SPL. Either way, thanks for the thoughts @buffalojoec !
I imagine it's possible to create some sort of community public key that you can prove is randomly generated and nobody owns – perhaps inside a smart contract – and then send it a little dust. Use that inside the library functions.
I really don't think this is something we want to support in Web3.js or SPL, but I can leave this issue open for anyone else to weigh in. Thanks!
Agree with @buffalojoec - we're not going to create that account and hardcode it into the library. But you're right that simulating a transaction with sigVerify: false
means that you can just use an arbitrary funded account as the fee payer.
If you want to propose an RPC change that would allow skipping the fee payer check then please open an issue against https://github.com/anza-xyz/agave. If such a change is made to the RPC then we would support that field in web3js, but it's out of scope for this repo to discuss RPC changes.
Because there has been no activity on this issue for 7 days since it was closed, it has been automatically locked. Please open a new issue if it requires a follow up.
Motivation
Returning account data using an
emit
instruction is a growing pattern on Solana that enhances composability by abstracting internal data layouts. For example, the TokenMetadata extension has an emit function.Clients are expected to simulate
emit
and deserialize the return data. To do so, they need to provide a payer for the transaction, which must have enough lamports to process as if it were submitted. This payer requirement makes it difficult to create libraries that use the simulation workflow. For example, here is a utility function that extracts TokenMetadata usingemit
– we're required to add a payer parameter:Here's how this might look if we had a
feePayerVerify
param:Optionally, we could use some sort of secure community public key as a payer, but this seems hacky.