Generic processing pipeline

[apfitzge]

Problem

• To allow new transaction type, we need to switch types (or make generic) in our processing pipeline

Summary of Changes

• Make (as much as reasonably possible at this time) the processing pipeline generic

Fixes #

[apfitzge]

From here, block-verification (replay) and block-production (banking) can be made generic independently.

[jstarry]

Is it necessary to have SVMTransactionAdapter? Can't we add those methods to SVMTransaction instead?

[apfitzge]

Is it necessary to have SVMTransactionAdapter? Can't we add those methods to SVMTransaction instead?

SVMTransaction is meant to be stuff necessary for svm. converting into our legacy formats for our internal/plugin interfaces elsewhere isn't necessary for that.

The goal is for SVMTransactionAdapter to go away eventually, as our interfaces become better. It just needs to exist until those change, but changing the interfaces involves breaking geyser plugins - so it will not happen immediately.

[tao-stones]

The goal is for SVMTransactionAdapter to go away eventually

What will the interfaces taks SVMTransaction when Adapter goes away? If so, can the adapter's methods be added to SVMTransaction as @jstarry suggested, then remove them when time comes?

[apfitzge]

What will the interfaces taks SVMTransaction when Adapter goes away? If so, can the adapter's methods be added to SVMTransaction as @jstarry suggested, then remove them when time comes?

Yeah they will take SVMTransaction when the time comes. BUT SVMTransaction is part of the public interface of svm. We need to be careful with what we're adding to that interface, and shouldn't add things in that aren't necessary. (cc @buffalojoec)

[buffalojoec]

Yeah they will take SVMTransaction when the time comes. BUT SVMTransaction is part of the public interface of svm. We need to be careful with what we're adding to that interface, and shouldn't add things in that aren't necessary. (cc @buffalojoec)

Yeah it gets a little hairy when you have methods on SVMTransaction that are never used within SVM. I really only skimmed this PR, but something like trait RuntimeTransaction: SVMTransaction could help.

[apfitzge]

Yeah it gets a little hairy when you have methods on SVMTransaction that are never used within SVM. I really only skimmed this PR, but something like trait RuntimeTransaction: SVMTransaction could help.

Yeah not opposed to an approach like this; think naming can't be RuntimeTransaction since that's a concrete type (at least rn 😉 )

Something like

pub trait RuntimeTransactionTrait: StaticMeta + SVMTransaction {
    // temporary conversion fns we need
}

Then for many of our processing functions we don't even need RuntimeTransaction<TRAIT> we can just do impl RuntimeTransactionTrait 🤔

@tao-stones / @jstarry any thoughts on a name here, do you like this approach more?

[tao-stones]

Then for many of our processing functions we don't even need RuntimeTransaction<TRAIT> we can just do impl RuntimeTransactionTrait

I like this approach - taking trait instead of concrete RuntimeTransaction or SVMTransactionAdapter.

As for naming, I feel RuntimeTransactionTrait isn't descriptive enough, is it? but I can't come up better one 🤔

[buffalojoec]

As for naming, I feel RuntimeTransactionTrait isn't descriptive enough, is it? but I can't come up better one

How about ExecutableRuntimeTransaction?

I just completely made up the executable bit.

[apfitzge]

CI still running, but I'll check w/ you now. @tao-stones @buffalojoec is this kind of what you had in mind?

[apfitzge]

Eventually these trait fns go away and TransactionWithMeta will be a glorified alias

[buffalojoec]

Yessir, that's basically what I was thinking. Looks good to me, and keeps things clean at the SVM level. As long as you don't mind carrying this alias around for a bit :)

[jstarry]

Sorry I still don't really understand why we need TransactionWithMeta. Why don't we just use RuntimeTransaction<SanitizedTransaction>?

[jstarry]

Sorry I still don't really understand why we need TransactionWithMeta. Why don't we just use RuntimeTransaction<SanitizedTransaction>?

Chatted with @apfitzge and I think I'm understanding things better now. Kinda spaced on the goal of being able to pass the upcoming RuntimeTransaction<ResolvedTransactionView> through the tx pipeline. So rather than using RuntimeTransaction<Tx> where Tx: SVMTransactionAdapter everywhere we are going with Tx: TransactionWithMeta which is nice because then when we need to convert to geyser / block entry tx types we can make use of the static metadata rather than needing to compute that metadata from the types that impl SVMTransactionAdapter.

[jstarry]

this approach looks good to me

[buffalojoec]

Lgtm!