Wrong URL encoded path used in solomachine client.

[en]

Summary of Bug

ibc-go/modules/light-clients/06-solomachine/client_state.go

Line 139 in db25dc5

Path: []byte(merklePath.String()),

The String() method returns a URL encoded path (like this: "/path%2Fto%2Fleaf"), which is not consistent with spec and other implementations (e.g. ibc-rs)

Expected Behaviour

Should use path.Pretty() here.

Version

Steps to Reproduce

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[crodriguezvega]

Hi @en. Thanks for opening the issue. I just have a couple of questions:

• which is not consistent with spec: do you mean with ICS 06? I briefly checked ICS 06 and also ICS 23 and I cannot find mention of the expected string formatting of a CommimentPath.
• and other implementations (e.g. ibc-rs): As far as I know ibc-rs doesn't have an implementation of ICS 06? Or you mean the solo machine implemented here? The paths used in stag are the standard paths specified in ICS 04, so there shouldn't be any spaces in the them. Those are the paths that ibc-go construct when verifying that the solo machine has commitment the data.
• To understand better your request: why would you need to have a path with spaces or other "unsafe" characters?

[en]

Hi @crodriguezvega,

I mean the paths specified in ICS 04.
These paths are used as storage keys in ICS 07, and as part of the signed data in ICS 06. (

ibc-go/modules/light-clients/06-solomachine/client_state.go

Lines 135 to 140 in db25dc5

	signBytes := &SignBytes{
	Sequence: sequence,
	Timestamp: timestamp,
	Diversifier: cs.ConsensusState.Diversifier,
	Path: []byte(merklePath.String()),
	Data: value,

)

We(Octopus Network) are implementing ICS 06 based on ibc-rs. These paths have to be consistent on both sides so they can be validated by ibc-go. Although there are some definitions of paths in ibc-rs( https://github.com/cosmos/ibc-rs/blob/v0.28.0/crates/ibc/src/core/ics24_host/path.rs#L49-L54 ), we construct them manually into the escaped form(/path%2Fto%2Fleaf) to pass the validation.

So my question is:
Is ibc-go intentionally using the escaped form paths? Or ibc-go used the wrong path.

[DimitrisJim]

I don't think spec specifies this? Either way, I wasn't around for solomachine to hopefully remember something. It might be worth noting that paths appear to be unescaped in the tendermint light client tho.

[colin-axner]

Hi @en, thanks for raising the issue! This is certainly behaviour that slipped our attention.

The side-effect of merklePath.String() is quite confusing. It turns out that the context of this behaviour is that the MerklePath type is meant to hold keys for a multitree structure (multistore). Each key is a key in a different tree and thus needs to be separated in some way in the String() print out (as each key will likely have /). The cometbft implementation separates the keys in this multi merkle path list by using the escaped paths.

The switch to including the merkle path in the sign bytes occurred in v7. It appears at the moment no solo machine users are on v7, so we could retroactively fix the issue.

My recommendation to the team would be to:

• fix solo machine to use the unescaped ics24 path (this would not include the connection prefix)
• remove merklePath.String() function
• remove merklePath.Pretty() function
• update documentation on the merklePath merkle keys documentation to indicate this expected structure

The solo machine does not have a multi tree structure. It should only signs over the ics24 paths expected. The connection prefix is unnecessary as solo machine clients also have a diversifer they sign over (which should logically separate a solo machines private key usage between chains/connections)

Would this match your implementation @en?

[crodriguezvega]

@en we have opened this PR with this change from @colin-axner's proposal above:

• fix solo machine to use the unescaped ics24 path (this would not include the connection prefix)

We are planning to release this change in v7.3.0 (target release date: 1st September).

The other items will be tackled in a follow-up PR.

[en]

Sorry for the late reply.
I just checked it. With the multistore key removed, our program is also simplified a lot.
Thanks!

[crodriguezvega]

Sorry for the late reply.
I just checked it. With the multistore key removed, our program is also simplified a lot.
Thanks!

Great to hear. Thanks for coming back to us!