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
TLDR - separate the relayer into a library and create a new binary on top of those types that can be used to interact with union-ibc-enabled chains in a similar way to uniond.
Rationale
uniond works great when communicating with cosmos chains, but calling evm smart contracts is much more difficult. There are dozens of CLIs and libraries for calling smart contracts, with most of them being specific to a framework or set of tooling (notably OpenZeppelin and Foundry (cast)). The main issue with these libraries and CLIs is that they work per-contract, which means that an end-user would need to know the address and abi of the smart contract they want to call, along with the semantics of said contract and its methods, in order to be able to call it.
Proposal
Separate the chain interfaces out of the relayer (i.e. Union and Evm<C>, and their respective config types)
Create a new binary that consumes these types, and provides a generic interface for interacting with both cosmos and evm (and any other chains we may support)
Move (most) existing chain-agnostic functionality out of the relayer and into this new binary (i.e. submitting packets)
Profit
This has the added benefit of keeping the relayer small and simple - it just relays.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
TLDR - separate the relayer into a library and create a new binary on top of those types that can be used to interact with union-ibc-enabled chains in a similar way to
uniond
.Rationale
uniond
works great when communicating with cosmos chains, but calling evm smart contracts is much more difficult. There are dozens of CLIs and libraries for calling smart contracts, with most of them being specific to a framework or set of tooling (notably OpenZeppelin and Foundry (cast)). The main issue with these libraries and CLIs is that they work per-contract, which means that an end-user would need to know the address and abi of the smart contract they want to call, along with the semantics of said contract and its methods, in order to be able to call it.Proposal
Union
andEvm<C>
, and their respective config types)This has the added benefit of keeping the relayer small and simple - it just relays.
Beta Was this translation helpful? Give feedback.
All reactions