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

Simplify Acknowledgement structure #7555

Merged
merged 4 commits into from
Nov 13, 2024
Merged

Conversation

AdityaSripal
Copy link
Member

Description

This is a proposal that follows the current spec and I believe is cleaner than the current approach.
closes: #XXXX


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against the correct branch (see CONTRIBUTING.md).
  • Linked to GitHub issue with discussion and accepted design, OR link to spec that describes this work.
  • Code follows the module structure standards and Go style guide.
  • Wrote unit and integration tests.
  • Updated relevant documentation (docs/).
  • Added relevant godoc comments.
  • Provide a conventional commit message to follow the repository standards.
  • Include a descriptive changelog entry when appropriate. This may be left to the discretion of the PR reviewers. (e.g. chores should be omitted from changelog)
  • Re-reviewed Files changed in the GitHub PR explorer.
  • Review SonarCloud Report in the comment section below once CI passes.

@AdityaSripal AdityaSripal changed the base branch from main to feat/ibc-eureka November 12, 2024 13:24
Copy link
Member Author

@AdityaSripal AdityaSripal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use RecvPacketResult purely as a type internal to the ibc-go implementation to package the app acknowledgement with other useful information for the receiver chain.

However, when packaging the acknowledgement to send over the wire; the protocol only needs the list of app acknowledgements. Thus I've simplified the types here.

isAsync = true
// Return error if there is more than 1 payload
// TODO: Handle case where there are multiple payloads
if len(msg.Packet.Payloads) > 1 {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently just error for multipayload in async ack case

@@ -203,14 +206,10 @@ func (k *Keeper) Acknowledgement(ctx context.Context, msg *types.MsgAcknowledgem
return nil, errorsmod.Wrap(err, "acknowledge packet verification failed")
}

recvResults := make(map[string]types.RecvPacketResult)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This puts the list into a map which will remove any subsequent acknowledgements from the same app. This is an error since we want to support sending multiple packets with the same portIDs.

Moreover it is unnecessary, the acknowledgement list is meant to match 1-1 to the list of payloads so we can associate each individual acknowledgement to the correct payload by looking at the portIDs in the matching payload in the payload list

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch, and yeah makes sense that we can just use the index.

Comment on lines +211 to +212
ack := msg.Acknowledgement.AppAcknowledgements[i]
err := cbs.OnAcknowledgementPacket(ctx, msg.Packet.SourceChannel, msg.Packet.DestinationChannel, pd, ack, relayer)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See here: We just match using the index

}

// AcknowledgementResult of identified acknowledgement. Correlating IBC application name to opaque ack bytes.
message AcknowledgementResult {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unnecessary struct since the acknowledgment side only ever uses the Acknowledgement bytes inside the RecvPacketResult.

The status in RecvPacketResult is only used on the receive side. Thus we do not need to transmit it over the wire back to the sending chain. Instead we can just package each individual opaque app acknowledgement into the Acknowledgment struct and send it over.

Moreover, the commitment isn't using the status so it isn't even secure to use it on the sending side (which we don't)

Copy link
Contributor

@chatton chatton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, changes make sense! Thanks for putting together this PR, clears things up a bit.

@@ -203,14 +206,10 @@ func (k *Keeper) Acknowledgement(ctx context.Context, msg *types.MsgAcknowledgem
return nil, errorsmod.Wrap(err, "acknowledge packet verification failed")
}

recvResults := make(map[string]types.RecvPacketResult)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch, and yeah makes sense that we can just use the index.

@AdityaSripal AdityaSripal marked this pull request as ready for review November 12, 2024 14:13
@AdityaSripal AdityaSripal changed the title DRAFT: Simplify Acknowledgement structure Simplify Acknowledgement structure Nov 12, 2024
Copy link

sonarcloud bot commented Nov 12, 2024

Copy link
Contributor

@DimitrisJim DimitrisJim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm too, appears this also unblocks #7472 now

@AdityaSripal AdityaSripal merged commit 595e98b into feat/ibc-eureka Nov 13, 2024
67 checks passed
@AdityaSripal AdityaSripal deleted the aditya/simplify-ack branch November 13, 2024 15:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants