Test IBC relaying between Penumbra and any Cosmos testnet #2284
Comments
|
Some notes documenting the setup. At a high level, I created a keypair, documented its seed phrase in the usual place, tapped the Babylon testnet faucet for some test tokens, and confirmed the balance is reflected in my local wallet. The |
|
The relayer code we've been working with doesn't support Babylon. Instead, Babylon has its own version of the relayer: https://github.com/babylonchain/babylon-relayer Will try to get Penumbra support working in the latter, rather than Babylon support in the former. |
|
Ah, hmm, that might be a good signal to pause, then — I think we might be overrunning our headlights if we try to combine features from two different forks of the Go relayer. |
|
We're optimistic we can get Babylon support working as a
Edited the config
Haven't debugged further why that account key is unrecognized. |
|
Tried setting up links between some other, non-Babylon Cosmos testnets, and those messages failed with a similar error: Note the "key not found" error, same as above for Babylon. Because the src and dest chains were not Penumbra and not Babylon, the error indicates that we're not configuring the relayer correctly. I'm going to pause on this spike for now to pivot and get a relayer integration from penumbra-preview <-> penumbra-testnet, as described in #465. When I pick this back up, I plan to pull in someone from SL to pair on the relayer configs, because I suspect I've misconfigured something. |
conorsch
changed the title
|
Updated to make this ticket more general: it doesn't need to be Babylon, it just needs to be a Cosmos testchain that we test against. |
|
I'm picking up this ticket for next sprint. Goal is to test, via a manual local deployment, relaying between a Penumbra test chain and a Cosmos testchain, then report results. If results positive, let's update the relayer deployment we run—else, open tickets to address blockers. |
|
Trying to IBC from Osmos testnet -> Penumbra preview fails with an unsupported address error: The The If we assume that Cosmos chains default to using the |
|
We shouldn't plan to add Penumbra address support, we need to ensure that counterparty chains can work with Penumbra addresses without changes. |
|
Looking at the func AccAddressFromBech32(address string) (addr AccAddress, err error) {
if len(strings.TrimSpace(address)) == 0 {
return AccAddress{}, errors.New("empty address string is not allowed")
}
bech32PrefixAccAddr := GetConfig().GetBech32AccountAddrPrefix()
bz, err := GetFromBech32(address, bech32PrefixAccAddr)
if err != nil {
return nil, err
}
err = VerifyAddressFormat(bz)
if err != nil {
return nil, err
}
return AccAddress(bz), nil
}The error string Do we know what value is being passed in as |
|
Oh, wait!
I was looking inside, at the definition of _, err := sdk.AccAddressFromBech32(msg.Signer)
if err != nil {
return errorsmod.Wrapf(ibcerrors.ErrInvalidAddress, "string could not be parsed as address: %v", err)
}So what's being parsed isn't the destination address inside the packet, but the "signer" field on the relaying transaction. The only purpose of the signer field is to attribute the relaying operations. On the Penumbra chain, we allow the signer to be the empty string, and that's fine, because it's our chain and we make the rules. On Osmosis, maybe the rules are different. But it seems more likely to be a configuration issue. |
|
If penumbra addresses are valid bech32, they should parse correctly (from what I can tell looking at the Osmosis impl). So I think this is correct, we need to configure a |
|
We should also double check where the error is actually coming from -- I think there's something inconsistent between
and
since the linked code is for validation for the |
This isn't what's happening at all. To check, replace the Penumbra address with the same osmosis address, and see that the error reoccurs. The Osmosis command line tooling is just very bad at reporting errors and managing keys. |
|
Current status is written up here: #3043 (comment) |
|
#3043 has landed, and will ship in Testnet 61. There are a number of follow-up tasks we'll track in the IBC tracking issue. Closing this issue. |
github-project-automation
bot
moved this from Next (Steal from here)
to Testnet 61: Dione
in Testnets
Part of #465. Let's attempt to relay between the Penumbra Pasiphae 49 (#2255) and the Babylon testnet. Relevant docs:
We'll need to implement a relayer config for the Babylon testnet, similar to the approach in #2166. Then we'll need to confirm that
rly transact link <path>works without errors.The text was updated successfully, but these errors were encountered: