The library has many points of improvements at the system/networking level:
Observations:
rocket facilitates code writing for web apps by abstracting low-level networking functionality at the level of Http server/client with routes points but seems too heavy for the needs of a two-party protocol.
Communication is blocking and synchronous per client.
json ser/de can be deprecated with a binary encoding format for MPC protocol specific messages.
There is no need to build the networking stack over http.
Possible directions:
[Gotham 2.0]
Keeping the same communication model: server/client over http; rocket can be deprecated with a lighter framework wrapped around tokio async runtime with hyper or tower (to investigate: https://crates.io/crates/ntex). As both hyper and tower act as wrappers of tokio that would allow better low level flexibility:
framing the communicated bytestream to follow the application logic for better handling the message dispatcher
1-1 map to the underlying tokio runtime for taking advantage of concurrent execution at different levels: client is not blocked when expecting something from the server, server is not blocking when performing a task for a specific response.
[Gotham 3.0]
Once the Gotham 2.0 is stable by keeping the same communication model and deprecating rocket, a possible transition to an agnostic in the number of nodes protocol not relying to HTTP, just using sockets over a tcp stream will be easier since the new Gotham 2.0 codebase will be based on low-level tokio primitives for framing/sockets/bin serde/async IO. The required logic to handle multiple parties over sockets without requiring http endpoints will be minimal leading to a possibly faster Gotham 3.
The library has many points of improvements at the system/networking level: Observations:
Possible directions: [Gotham 2.0]
[Gotham 3.0]