ICS for BandChain oracle packet

[songwongtp]

Hello,

As our team has mentioned before, we are looking to standardize our oracle packet into ICS.
Here is some of the code: https://github.com/bandprotocol/chain/blob/master/x/oracle/types/oracle.pb.go#L594

We also have a rough draft which is based on ICS20, but currently our doc is split into two parts due to different roles between BandChain and other chains.
https://github.com/bandprotocol/chain/tree/nat/oracle-adr-docs/spec/app/icsxx-oracle-packet

We are wondering what is the process to make this happen. Thanks!

[colin-axner]

Since the the topic of this discussion is creating an ICS spec, I'm going to transfer this discussion to cosmos/ibc since that repository contains the correct audience

[zmanian]

I looked draft ADRs.

A few comments.

1. What is an OBI encoding ? A link would be nice.

2. I think there two possible client architectures.

3. Any application that expects to support a band application should be expecting to open a band specific port to the module. The other application would be to have band client module that handles all band packets to the chain and the other modules get the state by accessing the band client module keeper. Do you have preference?

[songwongtp]

1. OBI encoding is an encoding scheme we used to encode input and output to our oracle. Here is the link for more information: https://github.com/bandprotocol/bandchain/wiki/Oracle-Binary-Encoding-(OBI)
2. Consumer architectures are not specific for us. Currently the oracle module in our BandChain is just to provide results to any incoming requests. The consumer architectures can be in forms of modules, contract, and etc. The implementations of these depend on the consumer chains. We only give template.

[ethanfrey]

Thank you for the OBI link and nice to see there are functioning Golang and JS implementations.

However, I have strong reservations about adding yet another encoding later into ibc apps. We currently have ICS applications using JSON for packet data (ICS20) and protobuf for packet data (ICS27). Do we need to add another one?

The encoding format probably deserves a separate discussion and maybe the core sdk devs would like to join in. In theory would it be possible for the band contracts to return OBI and then have the Go Oracle ICS logic convert that into protobuf/JSON?

[ethanfrey]

Looking more, I see this is just passed as opaque bytes to your contracts, so you assume whoever calls the oracle either directly on band chain or remotely via ibc use this format.

That does make sense, but does make this a band-specific protocol. It would be nice to see a generic oracle service (maybe even one that would let me get a time-weighted average of token exchange rate off the gravity dex). But I am good to focus on one concrete use case to get started.

[colin-axner]

Read through the linked specifications. Some things that come to mind:

I think it'd be worth while to avoid using "client", there is already a strong notion of "client" in core IBC and it can be confusing to understand the context. "consumer" is a nice substitute

What is the reasoning of using a 2 packet send/receive? Asynchronous acknowledgements are supported. OracleResponsePacketData could be the acknowledgement. This would cut IBC traffic in half and avoid issues with constructing a timeout on-chain. This is a good use case for acknowledgements. Note, there is a separate "receipt" flag in core IBC which will indicate the request was received

The escrow address construction is modeled off of ICS20. This construction came from informal's audit of ICS20. Very careful care, was done to ensure the uniqueness of each escrow address (we brute force checked address collisions since we can deterministically construct them before hand). The request key in the escrow address creation seems to draw up these concerns once more. While a very edge case scenario, certainly worth some attention

As I understand it, a consumer is expected to pre-create the escrow address using their request key, send tokens to that address on the bandchain and then send their request with that request key. Is this correct? If so, it seems like sub-optimal solution to the fee collection problem as it requires funding new addresses for each request that are also non-redeemable.

There is current discussion about how to implement fees for IBC applications which aren't ICS20. This discussion is primarily focused on incentivizing relayers, but there is conceptual overlap here. Using that discussion as a guideline will likely prove worthwhile

My initial thought is that this would be cleaner using ICS27. This way a consumer could prefill their ICS27 account and then use that account to execute oracle requests. I'll give this some more thought since I think fees on the service side of IBC seems like it'll be a reoccurring problem

Could you document some use cases? Who do you anticipate the consumers to be? Users? Modules? Chains?

[hxrts]

For reference:

• ICS20-2 initial relayer incentivisation thread
• ICS27 Interchain Accounts thread

[songwongtp]

• For now, we decide to send an acknowledgement first so that users (on the consumer chain) can at least know that their requests are registered in BandChain while waiting for the results. There can be cases where requests fail before they are registered in BandChain.
• How request keys are generated solely depend on counter-party chains. They might have an algorithm to generate a unique key for each of their users or they can have a single key used by all users. Counter-party chains have to make this decision. Moreover, since different chains communicating with oracle module have different channels, so the collision of accounts from two different chains are unlike in our opinion. Nevertheless, the edge case you mentioned does exist. We will keep that in mind and try to come up with a better solution.
• Another method we have in mind is to have a payer account, and tie it to addresses on counter-party chains. Then this account can be used as the escrow address instead.
• ICS27 does sound interesting. This can substitute current method in the future.
• Consumers depend on the implementations of counter-party chains. For examples, a counter-party chain that wants to know a real-time exchange rate whenever there is an exchange occurring in that chain, or a chain that requires its users to query some prices at any time. Consumers can even be smart contracts like Wasmd.

Thanks for the suggestions and references. I am looking into them.

[ethanfrey]

Nice ideas on fee payments and I think it would be very helpful if you could join a general conversation that just started on cross-chain incentivizations. It should idealy be able to handle your use case as well: #578

I was also confused by #578 and what fees got to what address where and how they are passed over the wire. But this is just because that is my focus in IBC now.