Need lighter flags for build

[JKearnsl]

Is your feature request related to a problem? Please describe.
I always get frustrated when I have to compile additional lib-rocksdb when I use penumbra sdk packages as a component 🤔🤔🤔

Describe the solution you'd like
I would like to see more flags for penumbra-sdk-* libraries! I'm tired of building libraries I don't need! I would like to see complex and demanding resources (ex rocksdb) split into separate flags 😢😢😢

Describe alternatives you've considered
I tried playing with flags, but the main and almost the only flag component encapsulates the modules I need and also unnecessary ones like snidarium which depends on rocksdb (for example from penumbra-sdk-app I only need the action handler)

Probably the simplest solution would be something like leaving the component flag but including heavy modules like dependency on snidarium etc. 🤔🤔🤔

Additional context
I would like to see penumbra components more reusable! Thanks for your work

[conorsch]

Thanks for taking the time to write this up! It's a definite pain point, that a lot of the Penumbra crates were initially written with a specific use case in mind, and only later were modified to be more generally applicable. Some crates like cnidarium we've broken out of the workspace entirely, to make it easier to maintain separation. For the bulk of the workspace crates, though, there's still a long road to full modularity.

Can you provide more detail on the use case you mention?

for example from penumbra-sdk-app I only need the action handler

I don't disagree with you, just trying to get a complete picture of the downstream implementation, to inform prioritization of adding flags.

I have to compile additional lib-rocksdb when I use penumbra sdk packages as a component

If you're seeing frequent mention of rocksdb in compilation messages, you might want to check out the dev docs on caching the rocksdb compilation: https://guide.penumbra.zone/dev/build#linking-against-rocksdb-optional I recognize that's a workaround, though, and doesn't address the specific problem you're having, which is avoiding the rocksdb build altogether.

[JKearnsl]

At the moment I use check_stateless method of AppActionHandler impl for Transaction described in penumbra-sdk-app-1.1.0/src/action_handler/transaction.rs

I need this to verify the transaction. Right now this is probably the only thing I need from penumbra-sdk-app however the action_handler module is only available under the component flag (maybe this is done because in action_handler there are handlers that write something to snidarium(ex check_and_execute), but I don't need it)

[features]
component = [
  "dep:cnidarium",
  "dep:cnidarium-component",
...

source

pub mod genesis;
pub mod params;

cfg_if::cfg_if! {
    if #[cfg(feature="component")] {
        pub mod app;
        pub mod metrics;
        pub mod rpc;
        pub mod server;

        mod action_handler;
        mod community_pool_ext;
        mod penumbra_host_chain;

        pub use crate::{
            action_handler::AppActionHandler, app::StateWriteExt,
            community_pool_ext::CommunityPoolStateReadExt, metrics::register_metrics,
            penumbra_host_chain::PenumbraHost,
        };

        /// Temporary compat wrapper for duplicate trait impls
        pub struct Compat<'a, T>(&'a T);
    }
}

source

Here we need to somehow split AppActionHandler into two separate traits:

• one with check_stateless etc. - available to everyone for reuse (remove it from the component flag)
• two check_and_execute etc. - which is used by penumbra node only (probably during transaction verification by the validator)

[cronokirby]

I think this is a bit tricky, because the validity of a transaction really is inextricably linked from the current state of the chain. The stateless checks are really only a small subset of what makes a transaction valid.

Perhaps another (albeit pie-in-the-sky) approach would be to try and make it so that the cnidarium interface can be depended upon without actually pulling in rocksdb.