Filip B. Gotten (Feb 06 2025 at 22:15): Filip B. Gotten (Feb 06 2025 at 22:15):Hi, I currently have a master thesis where the goal is to investigate the new wasm component model, and specifically how it would work with a distributed algorithm like Paxos.
Are there any tips you guys could give me to achieve this? I know we could wrap the wasm component implementations of the Paxos elements in their own host with a grpc server. But is there a way to make it work while keeping as much of the implementation as possible inside the wasm components themselves?
I have looked into wrpc already, but is it possible to use it like I want? By having the Paxos wash components communicate with each other directly? Ensuring that for example the proposer wasm component talk to all acceptor wasm components?
Are there any other options? Or any other general tips on how to approach this? Thanks.
Chris Fallin (Feb 06 2025 at 22:22):Can you clarify in more detail what your goal is? "how the component model would work with Paxos" is quite broad, and these are two different categories of things (as I'm sure you know!) -- a software module framework and a consensus protocol.
Do you mean that you want to run Wasm components as logic within a state machine that is the subject of the distributed consensus? Or you want to have distributed consensus (e.g., a strongly-consistent key value store) as an API available to components? Or something else? Both are possible, neither strike me as much more than the "sum of parts": for the first, a deterministic Wasm component is as good a deterministic function as any to put inside a replicated state machine, and folks have done this in e.g. blockchain applications; for the second, there are proposed key-value store APIs already, and it's reasonable to put something like etcd underneath it.
Filip B. Gotten (Feb 06 2025 at 23:11):Hi, thanks for the answer :)
The goal of the thesis was by definition quite open when we chose it, so it's up to us what direction we take it.
But for now, what we focus on is trying to do this from the task:
"The goal for this thesis is to investigate how WebAssembly components can be used to compartmentalize implementations of distributed algorithms."
And...
"The goal of this thesis is to create a compartmentalized version of Paxos, where proposer, acceptor, learner and state machine application are different modules. Research questions include how best to combine, test, and run the modules."
So we want to have wasm components for all the logical parts of the algorithm and the state machine. But the struggle we're having is how to coordinate the communication between these wasm components when they are on different servers.
Specifically is there a recommended way to embed the communication logic inside the wasm components themselves, making them self reliant and able to potentially just run them directly on a wasmtime? Or is there not any point of doing that and instead just use a wrapper rust host around each wasm component that would handle the network communication?
Sorry for the long text, but any tips or recommendations would be appreciated.
Chris Fallin (Feb 06 2025 at 23:23):The goal of this thesis is to create a compartmentalized version of Paxos, where proposer, acceptor, learner and state machine application are different modules
OK, I see. I guess part of my initial confusion was that this seems to not have much to do with the Wasm component model in general -- compartmentalization of a consensus algorithm will lead to questions about finding the right abstractions, and yes a module system of some sort will be useful to ensure modules stick to the abstraction boundaries, but any module system will do.
Usually, also, a consensus algorithm like Paxos or Raft will specify the actual proposer/acceptor flow pretty tightly -- the exact message exchange protocol and rules are essential for algorithm correctness and are not pluggable or "user-serviceable" components -- while the state machine being replicated is the part that one wants to be generic over. So I guess I'm somewhat unsure how you're going to leverage components or module boundaries here, still. But, that's for you to decide I guess.
Specifically is there a recommended way to embed the communication logic inside the wasm components themselves, making them self reliant and able to potentially just run them directly on a wasmtime?
If you want components on different machines to be able to call each other, I think the right factoring here would be to build an RPC mechanism that proxies wit-defined interfaces. Be aware that the Wasm component model was explicitly designed to assume that network failures do not happen on calls -- in opposition to earlier component models like CORBA or DCOM -- because failure/recovery and all the partial states that result breaks everything. So you'll need to reason through how you handle all that, and get it right in the presence of node failures, dropped messages, and all that (which is the core domain that consensus protocols handle!).
Filip B. Gotten (Feb 07 2025 at 11:29):That makes sense. Thanks for taking the time to answer!
One last clarification question though. Do you think it is a reasonable goal to have all logic inside the wasm components? For instance also having the RPC mechanism inside wasm components, which can run directly using wasmtime (or another wasm runtime). Or do you think we will always have need for a host program that embeds the wasm components?
The might seem like a weird thing to focus on, but it does have a large affect on how we consider the roadmap of entire master thesis.
Thanks again.
Chris Fallin (Feb 07 2025 at 16:55):One last clarification question though. Do you think it is a reasonable goal to have all logic inside the wasm components? For instance also having the RPC mechanism inside wasm components, which can run directly using wasmtime (or another wasm runtime). Or do you think we will always have need for a host program that embeds the wasm components?
To the second question -- "will we always have need for a program that embeds the components" -- yes by definition, because Wasm currently always runs in the context of a host program. (So do "native" binaries, it's just that the "host program" is the operating system -- so if one had a Wasm-native OS, one might say that the components are no longer embedded in a host, but that's just semantics.)
To have all logic inside the components: I'm not sure exactly what that would mean -- pull an RPC library inside and use raw TCP sockets or HTTP requests? Sure, that's technically possible. I'm not sure whether it's a good idea or not -- most of the work you would do would be uninteresting platform porting work rather than anything that focuses on modularization, security boundaries, isolation, determinism, or any of the other bits that make Wasm interesting. That's why I suggested building an RPC system outside the components -- it at least leads to an interesting contribution, namely, adapting the existing wit IDL system to work across a network boundary
Last updated: Feb 28 2025 at 02:27 UTC