Shared Logic #249
Replies: 1 comment
-
It depends on what the point of having multiple implementations is as well. Having two client implementations increases bug surface due to inconsistencies between the two, but also drives spec work and reduces the impact of client-specific bugs. However, client specific bugs are going to be problematic until theres at least > 3 clients with uniform adoption from the validators. (as we can't tolerate > 1/3 of validators having faults) If the goal is to get better formal verification properties, memory safety properties, concurrent safety properties, etc. of a single implementation, and then have multiple language wrappers on top of that for convenience, then I think it makes complete sense personally to go with the above suggestion. |
Beta Was this translation helpful? Give feedback.
-
There is work being done for a second implementation of Tendermint in rust. This begs the question should both implementations share the same core logic? This sounds absurd but hear my out.
The core idea is we have the logic of a component in rust. Let's use evidence for this example. Evidence is core to tendermint and will be written twice. Why not write it once and use it in two places. The core logic would be written in rust, used in the tendermint-rs natively, for the tendermint-go repo it would be compiled to wasm and used within tendermint-go with wasmer or other wasm based environments. The interaction with p2p layer would be written in the native language.
This was a thought on how to minimize duplication of work and to align both teams on work being done.
Because the interaction with wasm in go is going through cgo there can be a degradation of performance. There should be a exploratory investigation before this is considered.
Beta Was this translation helpful? Give feedback.
All reactions