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

Migrate internal storage of trace string to array of trace info #6221

Open
3 tasks
colin-axner opened this issue Apr 24, 2024 · 0 comments
Open
3 tasks

Migrate internal storage of trace string to array of trace info #6221

colin-axner opened this issue Apr 24, 2024 · 0 comments
Assignees
Labels
20-transfer type: refactor Architecture, code or CI improvements that may or may not tackle technical debt.
Milestone

Comments

@colin-axner
Copy link
Contributor

Summary

Migrate internal trace information of ics20 token to store individual trace hop pairs, []string, to match ics20-v2 updates

Problem Definition

In maintaining backwards compatibility, there's an unnecessary amount of parsing, joining occurring which would be largely simplified by performing this migration.

Upon SendPacket:

  1. ibc token lookup occurs from hash to trace info
  2. full joined path is returned
  3. the full path is then re-parsed (despite its denom, path being cached)
  4. in this re-parsing, we parse out the denom trace (despite it being available in step 1)
  5. and then we reparse the path again (second time in this stack trace) to format the []trace pair which is set in the packet, but not internal state

In the expected flow:

  1. ibc token lookup occurs from hash, returns ibc token info (denom, []trace)
  2. any usage which needs full denom path (v1 compat) can do a basic strings.join on []trace

Use cases

Mostly simplifies maintenance and optimizes the code. In the long run, it would remove the possibility for a minor issue (once support for ics20-v1 is dropped)

Proposal

Perform an in-place migration which migrates the stored denom trace info from being a single string to an array of trace info. This makes internal storage compatible with the v2 approach rather than trying to reconstruct the v2 info based on v1 storage. Not essential, but likely worth the effort.

In practice we could remove/replace the DenomTrace type, ideally with a better named type


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged/assigned
@crodriguezvega crodriguezvega added the type: refactor Architecture, code or CI improvements that may or may not tackle technical debt. label May 13, 2024
@colin-axner colin-axner mentioned this issue May 23, 2024
10 tasks
@crodriguezvega crodriguezvega added this to the v9.0.0 milestone May 24, 2024
@colin-axner colin-axner self-assigned this May 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
20-transfer type: refactor Architecture, code or CI improvements that may or may not tackle technical debt.
Projects
Status: Todo 🏃
Development

Successfully merging a pull request may close this issue.

2 participants