Transaction Introspection

[soundsonacid]

Motivation

as of SIMD-0385 activation (txv1), it is now possible to express compute budget params outside of instructions in the TransactionConfig. this means that priority fee, etc. are no longer introspect-able via the instructions sysvar.

as such, we would like a way to introspect the TransactionConfig. while we are making introspection changes, it would also be great to see blockhash/nonce + transaction signature.

Proposal

the most unopinionated and future-proof way to enable smart contract devs to introspect transactions is to give them the whole txn byte buffer. we propose creating a new TransactionSysvar11111.... sysvar or sol_get_transaction_bytes syscall allowing this instead of extending the current instructions sysvar.

[bw-solana]

@buffalojoec would be interested in your take here.

also seems like something to comprehend in the context of ABIv2

[bw-solana]

@soundsonacid would be cool if you could provide some examples of why introspection of these different fields (PF, blockhash, tx sig, etc.) would be useful.

The PF one seems more obvious to me, and if we're going to map some non-ix/account data in, seems good to think about how to do it for everything. But I personally find it helpful to document some concrete use cases to help understand the why, urgency, and make sure any design preserves the initial intent

[buffalojoec]

I'm against a new sysvar here. In SIMD-0558, we could have done a sysvar because it was small and it was updated only once per slot. However, this one would need to be created fresh with every transaction, like the Instructions sysvar. It's a bad design and we should get away from it.

A syscall works okay here if you scope it to sol_get_priority_fee. You only need 24 bytes of information for the immediate ask. A sol_get_transaction_bytes syscall returning the whole transaction payload is clunky (transactions can be any size) and also unnecessarily expensive for callers who need only minimal info.

In ABIv2 we will expose more information about the transaction to programs. However, the current proposal offers what's now called (in the implementation) a "Transaction Frame". It is not the same information as what's in the serialized transaction.

If we really want to address the issue of transaction visibility, since it has been asked for before, I think we should include a new readonly region in ABIv2 for the transaction payload itself, and upstream it to ABIv1 right now.

---

@LucasSte @febo even if we go with sol_get_priority_fee here, I think transaction payload visibility needs to be a hard requirement for ABIv2.