Transaction V1 with Explicit Resource Requests

[blockiosaurus]

Summary

Add explicit resource requests to the VersionedTransaction type rather than to the ComputeBudget Program. No longer force inclusion of the ComputeBudget instruction in all transactions and remove it from signed data entirely.

Motivation

Core devs have expressed a desire to better define transaction resource constraints by including explicit resource requests in a transaction. Currently this is done by overloading the ComputeBudget Program. However, this has several drawbacks such as transaction size, overhead, and difficulty building transactions. This data would be better represented and more efficient as native fields in the VersionedTransaction object.

Additionally, most transactions originating from frontend wallets contain a ComputeBudgetInstruction injected via the wallet provider. For the sake of clarity and DevEx, these resource request fields should be removed from the signed data entirely to clearly indicate that these fields have no guaranteed originator.

Alternatives Considered

• Further Extension of the ComputeBudgetInstruction - Not the optimal representation of the data.

New Terminology

ResourceRequest - An enum type for the different resources that can be requested for a transaction's execution.

Resources - Part of the V1 VersionedTransaction variant. An array of the ResourceRequests that can are requested for a transaction.

Detailed Design

pub enum ResourceRequest {
    HeapFrame(u32),
    ComputeUnitLimit(u32),
    ComputeUnitPrice(u64),
    LoadedAccountsDataSizeLimit(u32),
    ...
    ChilliPeppers(u32),
    MeowMeowBeenz(u32),
}

pub enum VersionedMessage {
    Legacy(Message),
    V0(Message),
    V1{message: Message, resources: ResourceRequest[]}
}

impl VersionedTransaction {
  ...

  /// Return the message containing all data that should be signed.
  pub fn message(&self) -> &Message {
      match (&self.message) {
        VersionedMessage::V1{message, resources} => message,
        Legacy(message) | V0(message) => message,
      }
  }

  ...
}

Impact

• Requires Transaction parsing to happen on VersionTransaction instead of converting it to legacy transactions
• Additional SDK work to support a new transaction format

Security Considerations

• A more in depth discussion should occur on removing the resource requests from the signed data in case it case there are attack vectors not foreseen in this proposal.

[4lve]

If the resource requests aren't in the signed data, couldn't an MEV validator set max piority fees for all incoming transactions?

[blockiosaurus]

Yeah, realized this like 30 seconds after I posted, haha. I guess the question is if that part of the transaction is under consensus and could be subject to slashing. Maybe it does make more sense in the MessageHeader.