Deprecate SysvarRecentBlockhashes

[jackcmay]

Problem

SysvarRecentBlockhashes exposes the fee structure internals and thus locks the Solana blockchain down to the current fee structure.

Summary of Changes

This sysvar is mostly used by Nonce accounts (only as far as I can tell) and Nonce accounts don't even need it since they could get the information from InvokeContext. Deprecate the sysvar so no new developers start to use it.

Next step is to switch nonce handling over to getting the blockhash/fee calculator from InvokeContext and then hopefully drop fee_calculator altogether and just use the fee calculator available at the time the transaction is submitted for processing.

Fixes #18817

[jackcmay]

@t-nelson Step one in reducing FeeCalculator exposure

[codecov]

Codecov Report

Merging #18875 (91649b2) into master (f51d648) will decrease coverage by 0.0%.
The diff coverage is 42.1%.

❗ Current head 91649b2 differs from pull request most recent head 2c095c3. Consider uploading reports for the commit 2c095c3 to get more accurate results

@@            Coverage Diff            @@
##           master   #18875     +/-   ##
=========================================
- Coverage    82.8%    82.8%   -0.1%     
=========================================
  Files         444      444             
  Lines      126568   126662     +94     
=========================================
+ Hits       104859   104918     +59     
- Misses      21709    21744     +35     

[t-nelson]

lgtm!

let's add an issue to update the deprecation warning strings with the invoke context method once it's ready

[jackcmay]

lgtm!

let's add an issue to update the deprecation warning strings with the invoke context method once it's ready

The invoke_context mechanism will only be available to built-in programs and even there we are planning for it to only return the current blockhash and fee_calculator. RecentBlockhashes will no longer be available to developers.

Pull request has been modified.

[ruuda]

Hi, we are using this sysvar in Lido for Solana. Not in the on-chain program, but to be able to know what the most recent blockhash was when you call getMultipleAccounts through the RPC. Will there be a different way to know which block you read from when calling getMultipleAccounts?

[CriesofCarrots]

Will there be a different way to know which block you read from when calling getMultipleAccounts?

@ruuda , the getMultipleAccounts call is one of a number that return a context object that includes the slot that the data was read from. Eg:

$ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0","id":1,"method":"getMultipleAccounts", "params":[["Bbqg1M4YVVfbhEzwA9SpC9FhsaG83YMTYoR4a8oTDLX"]]}' api.mainnet-beta.solana.com

{
  "jsonrpc": "2.0",
  "result": {
    "context": {
      "slot": 92536948 // <-- HERE
    },
    "value": [
      {
        "data": [
          "",
          "base64"
        ],
        "executable": false,
        "lamports": 629691080,
        "owner": "11111111111111111111111111111111",
        "rentEpoch": 214
      }
    ]
  },
  "id": 1
}

Does that help?

[ruuda]

the getMultipleAccounts call is one of a number that return a context object that includes the slot that the data was read from.
Does that help?

It helps a little; this context is not exposed in the Rust client, but I can see it is available internally, so if we fork solana-client I suppose we could expose it. Then from the slot number we can get the blockhash with get_block(slot).

[Aphoh]

@jackcmay
Is there a reason why we couldn't expose only the recent blockhash on a transaction to a program called in that transaction? The recent blockhashes sysvar gave programs a convenient way to have a checkable nonce in signed messages (like those verified with a KeccakSecp256k1 instruction). Without something like this, program developers have to create their own nonce-handling logic (like this ethereum style one from audius), which involves allocating a separate nonce account that stores incremental nonces. It makes this more complicated and requires more space to be allocated.

[ramizhasan111]

Hi, I see the RecentBlockhashes is still used in the advance_nonce_account() function to create the AdvanceNonceAccount system call in the latest version of the Solana repo. I am confused why the deprecated feature is still used and whether it is safe to use it? I want to create a create a AdvanceNonceAccount SystemInstruction and it looks like using RecentBlockhashes is still the way to do it as per the doc examples in the latest version of the Solana SDK.

[t-nelson]

the sysvar is only queried and used to perform a legacy check. it can be removed. all instances where the blockhash is actually used, query the invoke context