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

Technical Debt Tracker #145

Closed
6 tasks done
AdityaSripal opened this issue Apr 28, 2021 · 4 comments
Closed
6 tasks done

Technical Debt Tracker #145

AdityaSripal opened this issue Apr 28, 2021 · 4 comments

Comments

@AdityaSripal
Copy link
Member

AdityaSripal commented Apr 28, 2021

This issue is a tracker for technical debt accumulated after IBC 1.0 for the purpose of maintaining backward compatibility.

@colin-axner
Copy link
Contributor

tendermint#6403 may influence which attribute should be deprecated between packet_data and packet_data_hex. We can discuss with relayers which is preferred when the time comes

@crodriguezvega
Copy link
Contributor

All the PRs mentioned above haven been merged and I believe the upgrade keeper is already used to set client/consensus states. Thus I will close the issue now.

@colin-axner
Copy link
Contributor

colin-axner commented Mar 30, 2023

I believe the upgrade keeper is already used to set client/consensus states.

This is correct. The original issue is a bit hard to follow, but the intention was to note technical debt, so the fact that the client/consensus states being set by the upgrade keeper is actually a problem. Ideally they would exist under the client keeper.

I think a couple of the other issues mentioned are not addressed:

  • frozen height is still maintained in the client state (it should be a boolean)
  • duplicate event emission for packet_data is still maintained (should be removed)
  • Indirect Iteration Keys needed for efficient iteration while not breaking ICS-24 paths which are inefficient for iteration (we should upgrade connections to allow for efficient iteration of consensus keys, thus making the indirect iteration keys useless)

@colin-axner
Copy link
Contributor

I think we should actually move this issue to a document. I do think it is useful to document areas of the code which have been deprecated and should be fixed/removed when possible

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants