Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add SendPacket rpc and OnSendPacket callback #7012

Open
3 tasks
colin-axner opened this issue Aug 1, 2024 · 0 comments
Open
3 tasks

Add SendPacket rpc and OnSendPacket callback #7012

colin-axner opened this issue Aug 1, 2024 · 0 comments
Assignees
Labels
04-channel 05-port Issues concerns the 05-port submodule needs discussion Issues that need discussion before they can be worked on

Comments

@colin-axner
Copy link
Contributor

Summary

With #6941, we will add a SendPacket rpc which can be called by users/actors in the same fashion that relayers invoke other ibc messages. This will result in a OnSendPacket callback which will replace the ics4wrapper interface function. This will allow middleware applications to provide their own packet data.

Problem Definition

See #6941 and #7008 for reasoning

Proposal

Both #6941 and #6985 require this, so I am opening an issue to agree on the api.

Currently we have the following:

service Msg {
  ...
  // SendPacket defines a rpc handler method for MsgSendPacket.
  rpc SendPacket(MsgSendPacket) returns (MsgSendPacketResponse);
  ...
}
// MsgSendPacket sends an outgoing IBC packet
message MsgSendPacket {
  option (cosmos.msg.v1.signer) = "signer";

  option (gogoproto.goproto_getters) = false;

  string                    port_id           = 1;
  string                    channel_id        = 2;
  ibc.core.client.v1.Height timeout_height    = 3 [(gogoproto.nullable) = false];
  uint64                    timeout_timestamp = 4;
  bytes                     data              = 5;
  string                    signer            = 6;
}

// MsgSendPacketReponse defines the Msg/SendPacket response type.
message MsgSendPacketResponse {
  option (gogoproto.goproto_getters) = false;

  uint64 sequence = 1;
}

But given that Eureka is breaking the correlation between src_channel, src_port <> dest_channel, dest_port, all the packet information (except the sequence) should be provided.

Thus we can start with MsgSendPacket:

// MsgSendPacket sends an outgoing IBC packet
message MsgSendPacket {
  option (cosmos.msg.v1.signer) = "signer";

  option (gogoproto.goproto_getters) = false;

  string                    source_channel    = 1;
  string                    source_port       = 2;
  string                    dest_channel      = 3;
  string                    dest_port         = 4;
  ibc.core.client.v1.Height timeout_height    = 5;
  uint64                    timeout_timestamp = 6;
  bytes                     data              = 7;
  string                    signer            = 8;
}

The decision of #7008 will also decide the type for data.

In addition we will need to add a OnSendPacket callback. We have started with:

type IBCModule interface {
...
OnSendPacket(
		ctx sdk.Context,
		portID string,
		channelID string,
		sequence uint64,
		timeoutHeight clienttypes.Height,
		timeoutTimestamp uint64,
		data []byte,
		signer sdk.AccAddress,
	) error
...
}

I believe we could simplify this to:

type IBCModule interface {
...
OnSendPacket(
		ctx sdk.Context,
		packetID types.PacketID,
		data []byte,
		signer sdk.AccAddress,
	) error
...
}

This should likely mirror the api decided in #7008


Now I am going off the deep end a little and hypothesizing what the MsgSendPacketV2 could look like after #7008 and #6985 adoption and no concern for backwards compatibility 😄

// MsgSendPacket sends an outgoing IBC packet
message MsgSendPacketV2 {
  option (cosmos.msg.v1.signer) = "signer";

  option (gogoproto.goproto_getters) = false;

  string                    source_client     = 1; // GetCounterparty would fill in dest_client in packet
  repeated PacketData       data              = 2; // port routing information included in packet data
  string                    timeout           = 3;
  string                    signer            = 4;
}

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged/assigned
@colin-axner colin-axner added needs discussion Issues that need discussion before they can be worked on 04-channel 05-port Issues concerns the 05-port submodule labels Aug 1, 2024
@colin-axner colin-axner added this to the 05-port refactor alpha milestone Aug 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
04-channel 05-port Issues concerns the 05-port submodule needs discussion Issues that need discussion before they can be worked on
Projects
Status: In progress 👷
Development

No branches or pull requests

3 participants