Embeddable Grandine

[sauliusgrigaitis]

Grandine already has a way to restart itself during the runtime. We need to further extend this into a wrapper that will allow to instantiate it easily from some other process. Likely it's just a wrapper function that accepts full configuration and launches Grandine. This wrapper function likely should be used as the way to launch Grandine regularly (not only externally), so then we do not need extra efforts to maintain it. We also need binding for popular languages. Once this is done, it will be possible to embed Grandine in EL clients.

[mahmudsudo]

can i take on this issue ?

[sauliusgrigaitis]

I know @povi started to work on it. Maybe @povi can push his branch and then in parallel @mahmudsudo can try to complete it. Another way would be for @mahmudsudo to start to work on bindings while @povi tries to finish the function.

For the bindings we need goland for Geth, c# for Nethermind, Java for Besu,

[mahmudsudo]

@povi how do you propose we work together on this ?
Thanks @sauliusgrigaitis

[povi]

Hey @mahmudsudo, my suggestion is that I make a function (or at least provide function signature) that accepts configurations as parameters and initializes all necessary entities that is needed for run_after_genesis (stuff that is now pretty much scattered in grandine/src/main.rs; this is what I'm working currently - it's hard to parallelize this task). Then you can write bindings for that function. Is this OK with you?

[mahmudsudo]

i am okay with what you proposed @povi

[mahmudsudo]

@povi still waiting for the function signature and also the specs for the binding

[povi]

@mahmudsudo I've pushed the code to feature/embeddable-grandine branch, where all runtime is lauched through runtime::run function that accepts GrandineConfig as a single argument. It should be pretty straightforward to build config and run that function from bindings.

As to what should go into GrandineConfig, you can check code in grandine/src/grandine_args.rs where config is built from command line args.

[sauliusgrigaitis]

@ArtiomTr @mahmudsudo so the code is ready thanks to @povi , so now only bindings need to be implemented. C#, Go, Java (later we may add node.js, python, etc) are needed. I suggest both of you to reserve the language you want to work on by leaving here a comment. In this case we avoid the situation when both of you work on the same binding.

[sauliusgrigaitis]

These bindings needs to be tested by embedding Grandine in corresponding client (Nethermind for C#, Geth for Go, Besu for Java). I think at this point it makes sense to test by simply passing a static pre-configuration (instead of fancy config that is passed throught EL config params) that demonstrates basic interaction between embeded Grandine and host EL.

[ArtiomTr]

Okay, I'll take geth/go bindings then

[sauliusgrigaitis]

Okay, I'll take geth/go bindings then

Great, feel free to take the next binding once you are finished with Go.

[sauliusgrigaitis]

@ArtiomTr an important note on Go bindings. The way Go bindings are done in rust-kzg is not the right way that is done in Go world, we just ship the compiled binary there. I suggest to check how other projects did that (only rust-eth-kzg and c-kzg-4844 comes to my mind right now, but there obviously must be a lot of great examples in the wild) and do the right thing from the begining.

[ArtiomTr]

Okay, will look into it 👍

[mahmudsudo]

Okay, I'll take geth/go bindings then

i will take java