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

Rename EIP191 Sign Mode #11833

Closed
4 tasks
sunnya97 opened this issue Apr 29, 2022 · 7 comments · Fixed by #17740
Closed
4 tasks

Rename EIP191 Sign Mode #11833

sunnya97 opened this issue Apr 29, 2022 · 7 comments · Fixed by #17740
Labels
C:Keys Keybase, KMS and HSMs T:feature-request

Comments

@sunnya97
Copy link
Member

sunnya97 commented Apr 29, 2022

#11533 introduced a new SignMode enum variant called simply EIP191. However, this name is not precise enough. EIP 191 simply refers to a method of encoding a string data to be signed.

However, the Sign Mode concept in Cosmos SDK also refers to how to encode a tx into a string in the first place.

For this reason, in the osmosis-labs version of this, we specifically call this "EIP191LegacyJSON" to signal that it is the EIP191 re-encoded version of the Amino JSON string.

In the future, we will probably want more EIP191 sign modes, such as an EIP191Textual which wraps SignModeTextual.

I think any new sign modes should have an associated ADR for them. For example, in the case of EIP191LegacyJSON, we would also need to standardize how to format the amino json (such as adding new lines and indents) before putting it through the EIP191 conversion.

For this reason, the current sign mode called EIP191 needs to be renamed to avoid confusion. If renaming it is not possible, then it should be deprecated and replaced with a properly named variant.

@AmauryM @fedekunze @alexanderbez


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@sunnya97
Copy link
Member Author

@fedekunze what tx encoding are you using for this 191 sign mode? We should rename EIP191 sign mode to be properly named to be more specific and precise.

@alexanderbez
Copy link
Contributor

Agreed. @fedekunze would you or anyone from your team be willing to make amendments to #11533?

@fedekunze
Copy link
Collaborator

I'm fine renaming it, I won't be able to look into it until EOW most likely so happy if someone can give me a hand here.

@amaury1093
Copy link
Contributor

I don't think we can rename it though, since it would be a proto-breaking change. We can simply deprecate the existing enum option, and add new ones.

@sunnya97
Copy link
Member Author

sunnya97 commented May 2, 2022

Enum names are proto-breaking?

@amaury1093
Copy link
Contributor

amaury1093 commented May 2, 2022

Yes.

Changing field/enum names is also breaking for clients (e.g. CosmJS) when they generate code or use the proto JSON representation. We decided in adr-044 to simply just never allow renames.

@tac0turtle tac0turtle added C:Keys Keybase, KMS and HSMs T:feature-request labels Mar 6, 2023
@JulianToledano
Copy link
Contributor

JulianToledano commented Sep 12, 2023

I can work on this, but I have a few questions:

  • Is "EIP_191_LEGACY_JSON" the desired name?
  • What should be the enum value assigned to it? 192?
  • Has any zone already implemented this signMode?
  • is allow_alias option in enums allowed in the sdk?

@amaury1729 @tac0turtle

@JulianToledano JulianToledano linked a pull request Sep 14, 2023 that will close this issue
20 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C:Keys Keybase, KMS and HSMs T:feature-request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants