Roadmap Question about wagyu HOT 8 CLOSED

The plan is to try and funnel all network queries (external requests) to unagi, and have implementations for requests with different service providers (using whatever connection protocol needed - REST, RPC, etc). This way fetching state from the outside world is unagi's responsibility, and with implementations for multiple service providers, we can traitify the service provider and build-in automatic fallbacks (e.g. if one service provider goes down for maintenance) for each functionality in unagi.

This way, for transactions, wagyu will remain strictly a transaction builder. Then unagi, will be an external state fetcher. And then, bento will be a stateful wallet by ingesting wagyu and unagi.

from wagyu.

Thanks! We should definitely add a roadmap on here. There are subsequent repos in the works currently to complement wagyu. One repo (codename unagi) will enable API queries for the supported coins (so one can pull UTXOs/balances/state), and the other repo (codenamed bento) will be a stateful wallet (ingesting unagi + wagyu to enable importing/exporting of keys, lookup of past transactions, and sending of new transactions).

The original plan was to build all of this into wagyu, however it was becoming a monolith that needed some proper abstraction barriers. This way, wagyu can be used solely for stateless operations (e.g. offline operations), while bento can be used as a stateful client (which is more high-level/user-friendly).

from wagyu.

Thanks for the clarification on the roles of the different packages (and interesting nomenclature!).

How much of that functionality would be parallel implementations vs. pulling over implementations from the underlying projects (especially if they are written in rust)?

from wagyu.

Great question, we've gone back and forth on this, and are open to your thoughts (as well as the community's).

For now, we're taking it case by case. For example, Bitcoin, Ethereum, and Monero are currently built as independent implementations. Zcash includes a partial port of the algebraic components and Sapling crypto primitives, which we then map to the Standard and HD wallet models in wagyu.

In some cases it may be difficult to build an independent implementation. For example, most (if not all) Monero transaction builders query a Monero full node to discover the other inputs in crafting a full Monero TX. In this case, it might be overly complicated to implement an independent version.

from wagyu.

In the case of Zcash, we could transition it to a fully independent implementation. For example, I implemented the BLS12-381 and JubJub infra in zexe, and we could in theory port this out (which already has a full array of arithmetic operations, including tests) to build an independent Sapling crypto stack. However, for the time being, we felt doing that would only make sense once the base protocol itself has stabilized (likely over the years).

from wagyu.

Interesting, it seems more straightforward for parallel implementations for the wagyu side of things to keep it lightweight and minimal on the dependencies. It optimizes for "it just works".

Unagi and Bento (or anything stateful) seem tougher especially as you support more wallet operations and currency types. I could imagine a plugin interface that declares dependencies and the operations they support that could then be surfaced to the UI or API of Unagi/Bento.

For instance for Monero, in order to provide operations you would need a monero full node running or an address of one to query as well as a monero cli executable to shell out to (kinda clunky). You could also make it a shared library dependency in the case where a project exposes a nice library api.

One other way to encapsulate and limit the scope of this might be drawing the line at just tx signing and do all tx crafting in the native clients for a particular currency.

from wagyu.

The architecture makes a ton of sense. I like the encapsulation of external data fetching to a single library as that can get messy. Thank you for outlining a bit more of the roadmap here. Feel free to close out the issue.

from wagyu.

No problem and always open to suggestions. The goal is to design a framework that'll be useful for the community and be robust enough to stand the test of time. Thanks for the kind words

from wagyu.