Consider mapping sysvars to syscalls

[mvines]

Sysvars are read-only accounts the the user must remember to pass into each instruction that needs access. This has produced problems:

1. such as https://github.com/solana-labs/solana/pull/15497, where the runtime now must mitigate transactions that incorrectly acquire a write-lock on the read-only sysvars, and
2. at more basic level, sysvars clog up the transaction with extra addresses

Consider mapping them to syscalls, such as clock() or rent(), which could enable direct access to sysvars from programs without going through the accounts database

[ryoqun]

Oh, this sounds better approach, a bit related, partly due to the burden to pass the rent sysvar, I think wormhole is currently incorrectly referring to Rent::default() inside the program: https://github.com/certusone/wormhole/search?q=Rent%3A%3Adefault

https://discord.com/channels/428295358100013066/476811830145318912/816945036599099413:

[5:07 PM ] ryoqun: btw, show about deprecating Rent::default() and their public some constants? iirc, the right thing to read the rent sysvar, right? For example, there is hard-coded references to them on-chain in the wild: https://github.com/certusone/wormhole/search?q=Rent%3A%3Adefault

As said above, I think we should deprecate Rent::default() and related constants or discourage of use of it in some way. (If this sounds right, I'll create just an issue)

If we chase this path, I think we should strictly prohibit updating (future) sysvars while processing transactions. So they're updated only before and after around the new Bank creation. Otherwise, we can't guarantee deterministic, I think.

Also, this maybe makes SysvarInstructions works as more intuitively for CPI, currently it's always referring to the root instruction. (As a context, this was yet another my failed attempt to attack solana...)