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

docs: ADR-066 Keyring plugin system #16637

Closed
wants to merge 9 commits into from
Closed

Conversation

bizk
Copy link
Contributor

@bizk bizk commented Jun 21, 2023

Description

Closes: #14940

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • followed the guidelines for building modules
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

@bizk bizk marked this pull request as ready for review June 21, 2023 15:44
@bizk bizk requested a review from a team as a code owner June 21, 2023 15:44
@github-prbot github-prbot requested review from a team, kocubinski and likhita-809 and removed request for a team June 21, 2023 15:44
@ainhoa-a ainhoa-a mentioned this pull request Jun 22, 2023
25 tasks
@JulianToledano
Copy link
Contributor

@tac0turtle @alexanderbez updated with definitions!

@facundomedica
Copy link
Member

facundomedica commented Jul 13, 2023

Hello! I think we need (or I need lol) a bit more of context, what's the main reason for developing this? The ADR only mentions that 99designs/keyring is not maintained, but seems a bit orthogonal to a keyring plugin system. So I think it would be good to include in the context section what you've been talking in other discussions and issues.

That's my only comment, it looks great 💯

@JulianToledano
Copy link
Contributor

Hello! I think we need (or I need lol) a bit more of context, what's the main reason for developing this? The ADR only mentions that 99designs/keyring is not maintained, but seems a bit orthogonal to a keyring plugin system. So I think it would be good to include in the context section what you've been talking in other discussions and issues.

That's my only comment, it looks great 💯

Hi! 👋
This work is part of the keyring refactor epic in #14940

The idea behind this is:

  1. Provide teams with the possibility of develop new backends in any language. This open the doors to key types defined in other languages rather than go.
  2. Remove 99designs/keyring dependency as it is not really under maintenance.

The plugin system will let anyone develop a keyring by fulfilling the gRPC service with all its perks associated and as mentioned in the ADR this is compatible with the current keyring as the main interface has not been modified.

Comment on lines +64 to +67
rpc ExportPubKeyArmor(ExportPubKeyArmorRequest) returns (ExportPubKeyArmorReturns);
rpc ExportPubKeyArmorByAddress(ExportPubKeyArmorByAddressRequest) returns (ExportPubKeyArmorByAddressReturns);
rpc ExportPrivKeyArmor(ExportPrivKeyArmorRequest) returns (ExportPrivKeyArmorReturns);
rpc ExportPrivKeyArmorByAddress(ExportPrivKeyArmorByAddressRequest) returns (ExportPrivKeyArmorByAddressReturns);
Copy link
Member

Choose a reason for hiding this comment

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

is there anyway to merge these four functions, it seems a bit odd to have the api be this big

Copy link
Contributor

Choose a reason for hiding this comment

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

The idea is to create an RPC endpoint for each existing keyring method. Alternatively, we can simplify this by having a single method that accepts a message containing all the necessary information to determine the user's intent. For example, we can define the following protobuf message:

message KeyringRequest {
	bool exportPubKey = 1;
	string uid = 2;
	bytes address = 3;
}

Then, within the implementation, we can check if the uid field is empty. If it is, we can search for the record associated with the given address.

Copy link
Member

Choose a reason for hiding this comment

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

I think we should aim to come up with a simple api. The current api either good or bad is fairly large and increases the maintenance burden. Let's try to reduce it to a simplified api. If we need to create a larger struct that is passed that is okay as well.

Comment on lines +50 to +53
rpc Key(KeyRequest ) returns (KeyReturns);
rpc KeyByAddress(KeyByAddressRequest ) returns (KeyByAddressReturns);
rpc Delete(DeleteRequest ) returns (DeleteReturns);
rpc DeleteByAddress(DeleteByAddressRequest ) returns (DeleteByAddressReturns);
Copy link
Member

Choose a reason for hiding this comment

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

can these be deduplicated?

Key and Delete seem enough?

Copy link
Contributor

Choose a reason for hiding this comment

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

Same as the comment above.

#### Service Definition
```protobuf
service KeyringService {
rpc Backend(BackendRequest) returns (BackendResponse);
Copy link
Member

Choose a reason for hiding this comment

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

why does backend need to be part of this api?

Copy link
Contributor

Choose a reason for hiding this comment

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

This method is meant to return the plugins' name and version.

Copy link
Member

Choose a reason for hiding this comment

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

why does the node need to know what backend is being used?

@bizk bizk requested a review from tac0turtle July 25, 2023 12:06
Copy link
Member

Choose a reason for hiding this comment

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

could you markdownlint this file?

Teams can easily develop plugins to meet their specific requirements,
which opens the door to new functionalities in key management.

### Negative
Copy link
Member

Choose a reason for hiding this comment

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

What is the overhead compared to the current implementation? In terms of latency.

Copy link
Contributor

Choose a reason for hiding this comment

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

The methods affected by this are those related to key creation and retrieval. Ultimately, it adds one more call to the codec. I'm not sure about the exact latency impact.

The idea is to define a service method for each method already present in the keyring interface.
Similarly, a request/response message will be defined for each service method.

#### Service Definition
Copy link
Member

Choose a reason for hiding this comment

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

Can you precise what is running the service (client or node) and if it is a node, what can is the increased load on the node?

Copy link
Contributor

@JulianToledano JulianToledano Aug 2, 2023

Choose a reason for hiding this comment

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

The service will be instantiated whenever a keyring call is required and terminated afterward. I believe this can be managed either by the client or the node.

I think that the overall load won't be significantly impacted, considering that plugins are lightweight and are terminated when they're no longer needed.

Choose a reason for hiding this comment

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

hey @tac0turtle do you have any other comments for us or can we close this?

@bizk bizk requested a review from julienrbrt August 7, 2023 11:52
@JulianToledano JulianToledano mentioned this pull request Aug 15, 2023
11 tasks
@tac0turtle
Copy link
Member

should we close this and merge it into the other adr?

@bizk
Copy link
Contributor Author

bizk commented Aug 29, 2023

We had great discussions over this ADR and implemented everything that was requested. Since this is ready, merging it instead of incorporating it as part of the bigger ADR should keep the complexity and scope reduced and allow the rest of the team to focus on other topics that will require more attention.

In the other hand. It could be part of the Crypto ADR since it is aligned with the plans, but personally I don't see more benefits than having everything at one place.

Copy link
Member

@tac0turtle tac0turtle left a comment

Choose a reason for hiding this comment

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

i think it makes sense to have a call about this ADR, i still think the API should be 70% less. The API proposed is the current API, for native it makes sense, but exposing so much will make it harder for users to integrate. What is the minimal API needed to funciton?

@ainhoa-a ainhoa-a mentioned this pull request Sep 6, 2023
13 tasks
@JulianToledano
Copy link
Contributor

What is the minimal API needed to funciton?

I think this would be the minimal API.

service KeyringService {
  rpc Backend(BackendRequest) returns (BackendResponse);
  rpc List(ListRequest) returns (stream ListResponse);
  rpc SupportedAlgorithms(SupportedAlgorithmsRequest) returns (SupportedAlgorithmsReturns);
  rpc Key(KeyRequest ) returns (KeyReturns);
  rpc Delete(DeleteRequest ) returns (DeleteReturns);
  rpc Rename(RenameRequest) returns (RenameReturns);
  rpc NewAccount(NewAccountRequest) returns (NewAccountReturns);
  rpc SaveLedgerKey(SaveLedgerKeyRequest) returns (SaveLedgerKeyReturns);
  rpc SaveOfflineKey(SaveOfflineKeyRequest)returns (SaveOfflineKeyReturns);
  rpc SaveMultisig(SaveMultisigRequest) returns (SaveMultisigReturns);
  rpc Sign(SignRequest) returns (SignReturns);
  rpc ImportKey(ImportKeyRequest) returns (ImportKeyReturns);
  rpc ExportKeyArmor(ExportKeyArmorRequest) returns (ExportKeyArmorReturns);
}

The messages will hold all the information needed to determine the user's intent. Like retrieving a key from an address or an id.

@tac0turtle
Copy link
Member

I'm starting to think this is overkill for cli support. keyring is meant for cli, which cosmos is still one of the few frameworks that have native cli. I believe this is because of a lack of client support for anything else. Id propose we rewrite the current keyring to be better maintainable and easier to integrate with autocli. This way it keeps the design simple and pushes users to use a client based frontend which will have better support for signing.

@JulianToledano
Copy link
Contributor

I agree, I think we can close this. The scope of the upcoming crypto ADR will make this one deprecated, as there will be the possibility of a gRPC keyring in the new one.

@bizk bizk deleted the zondax/adr/keybase branch October 10, 2023 21:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

EPIC: Keyring refactor
7 participants