Light-client concurrency model

[gterzian]

Place to discuss "how we want to run" the light-client.

Currently it seems like we use a single thread, and then use a Tokio basic-scheduler to block on results for futures via

https://github.com/interchainio/tendermint-rs/blob/5c3aff6ab1835f0e4db6215c9deaad6a12c10062/tendermint-lite/src/main.rs#L22

Discussion started at #125 (review)

[liamsi]

ref #172, #171, #173

[gterzian]

It looks like a single-threaded tokio runtime is a good idea for now? Then we can use a threaded runtime later if there is a need for parallellism somewhere, and spawn additional tasks, as opposed to using await in the "current task" everywhere?

[liamsi]

Sounds reasonable to me. There might be some need for parallellism in what requests headers and what verifies those. These could be separate tasks. And there are likely a few other tasks that could be parallelised.

[brapse]

I have some suggestions coming by weeks end sorry for the delay! 🙏

[tarcieri]

It seems like there's a lot of potential for parallelization. If you'd like some inspiration, check out how Zebrad implements batch verification for Ed25519 signatures.

Here's a plot of the performance improvements they saw:

[ebuchman]

For the initial version of this ala https://github.com/informalsystems/tendermint-rs/milestone/1 we will do everything synchronously and revisit concurrency and batch verification down the road.

[brapse]

Will close for now and create issues for specific component concurrency concerns.