Feedback from using op-rbuilder to build the credible layer

[makemake-kbo]

hey! we're using op-rbuilder to build the credible layer block builder, using a fork of op-rbuilder. I summarized our experience using it below. Thanks for building such a solid foundation!

Enhanced Documentation

The documentation that exists is good! Some things like how testing works, how builders are structured and why they're structured the way they are only become clear after diving into the code. An architecture doc would help as both a reference and for those diving into the code for the first time.

Easier Implementation of New Builders

Creating a new builder is relatively straightforward when using the standard and flashblocks builders as reference. I did run into friction when having to satisfy trait bounds for both the service and payload builder.

For an SDK solution, I would suggest a template builder approach where you implement traits for ordering and execution. For example, if I wanted to build a new builder that modifies the EVM execution loop, I would have to implement a builder that implements execute_best_transactions and ideally only have to worry about satisfying the trait fn signature for execute_best_transactions.

In the example above, it would likely require the execute_best_transactions signature to be changed, but IMO architecting it so that we just have to implement &self-less functions would provide good UX for an SDK.

Local Development

Something like a script to send transactions while running the builder locally would be very useful for development, debugging and monitoring. Contender can be used for this but the friction to instantiate it is too much for a quick test. Builder playground is a fine tool for local testing, but does not work on Linux.

The testing framework is spectacular and incredibly useful for verifying core functionality(especially so because it automatically impls test for additional builders), but it doesn't work if you want to observe the builder for a while.

[odyslam]

To add to this, supporting the EXT trait pattern like it's used extensively in reth, would enable people to build custom builder logic, without having to fork op-rbuilder, but by simply using it as a library.

[SozinM]

Hi!

Builder playground is a fine tool for local testing, but does not work on Linux.

It works on linux, if you encounter any issues please feel free to report them in builder-playground repo
Also we have support for sending transaction out of the box (--contender flag)

[SozinM]

Also right now we have builder extension in developement (release date soon) that will address your issue with implementation!
@karim-agha it working on it and could give more info!

[zeroXbrock]

hey @makemake-kbo, thanks for your feedback on contender! Super helpful; now we have a much cleaner API for devs to use.

With the new API, a simple contender setup might only use ~10-15 lines (excluding use statements), something like this:

// create a custom scenario config
let config = TestConfig::new().with_spam(vec![SpamRequest::new_tx(
    &FunctionCallDefinition::new("{_sender}") // send tx to self
        .with_from_pool("spammers"),
)]);

// setup contender w/ default settings
let ctx = ContenderCtx::builder_simple(config.to_owned(), "http://localhost:8545").build();
let mut contender = Contender::new(ctx);

// run a timed spammer w/ no-op callback
contender
    .spam(
        TimedSpammer::new(Duration::from_secs(1)),
        NilCallback.into(),
        RunOpts::new().txs_per_period(100).periods(4),
    )
    .await?;

I wrote a forum post with all the details if you wanna learn more. I also wrote a demo repo -- it's a good reference to get started with the new API.

Would love for you to give it another shot and let us know how it feels!

[makemake-kbo]

thank you all for being so responsive! Ill definitely be checking the new api!! It looks good