You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 22, 2024. It is now read-only.
Create spec on how dynamic backend loading will work with nargo
Think through different systems and produce system specific work items as needed
Blaine:
Rust dynamic linking looks really difficult. They have dylib and cdylib but dylib is extremely unstable and only should be used by the Rust compiler team (it will likely break between even the smallest Rust version changes). So the only real option is to generate a cdylib which has a stable ABI, but restricts the types to things C can handle.
There is a utility library (https://github.com/rodrimati1992/abi_stable_crates) for producing and working with "stable ABIs" but it very macro heavy and relies on specific layout knowledge. It also seems that you also have to wrap Enums into their NonExhaustive enum so variants can be added without disrupting their stable ABI.
Once all that is sorted, a library like dlopen or libloading could be used to dynamically load the backend.
Alternatively, the backends could all be WebAssembly, but I don't think that's a viable solution because it becomes too slow for larger circuits.
Koby:
What if we would go IPC route instead?
Available options would be:
Simple Process Invocations w/ passing Command Line Params
Pipes - works locally only
TCP (ie. gRPC or ZeroMQ + ProtoBuf, better yet libp2p) which would allow for remote invocations, would support more commercially friendly patterns
The route depends on what Use Cases we see before Nargo. Is it just supporting development process? Or is it potentially useful in production environments?
The text was updated successfully, but these errors were encountered:
Create spec on how dynamic backend loading will work with nargo
Think through different systems and produce system specific work items as needed
Blaine:
Rust dynamic linking looks really difficult. They have
dylib
andcdylib
butdylib
is extremely unstable and only should be used by the Rust compiler team (it will likely break between even the smallest Rust version changes). So the only real option is to generate acdylib
which has a stable ABI, but restricts the types to things C can handle.There is a utility library (https://github.com/rodrimati1992/abi_stable_crates) for producing and working with "stable ABIs" but it very macro heavy and relies on specific layout knowledge. It also seems that you also have to wrap Enums into their
NonExhaustive
enum so variants can be added without disrupting their stable ABI.Once all that is sorted, a library like dlopen or libloading could be used to dynamically load the backend.
Additional resources:
Alternatively, the backends could all be WebAssembly, but I don't think that's a viable solution because it becomes too slow for larger circuits.
Koby:
What if we would go IPC route instead?
Available options would be:
The route depends on what Use Cases we see before Nargo. Is it just supporting development process? Or is it potentially useful in production environments?
The text was updated successfully, but these errors were encountered: