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

Update ADR 020 to address client-side tx UX #6031

Closed
wants to merge 14 commits into from

Conversation

aaronc
Copy link
Member

@aaronc aaronc commented Apr 20, 2020

ref: #6030


For contributor use:

  • Targeted PR against 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.
  • Wrote unit and integration tests
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/)
  • Added relevant godoc comments.
  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer

For admin use:

  • Added appropriate labels to PR (ex. WIP, R4R, docs, etc)
  • Reviewers assigned
  • Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

@codecov
Copy link

codecov bot commented Apr 20, 2020

Codecov Report

Merging #6031 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #6031   +/-   ##
=======================================
  Coverage   54.69%   54.69%           
=======================================
  Files         424      424           
  Lines       25790    25790           
=======================================
  Hits        14107    14107           
  Misses      10708    10708           
  Partials      975      975           

@alexanderbez alexanderbez added T: ADR An issue or PR relating to an architectural decision record R4R labels Apr 21, 2020
@alexanderbez
Copy link
Contributor

A good stress test, have as many people review this as possible and see if the proposed changes make sense 👍

docs/architecture/adr-020-protobuf-transaction-encoding.md Outdated Show resolved Hide resolved
docs/architecture/adr-020-protobuf-transaction-encoding.md Outdated Show resolved Hide resolved
```Protobuf
// app/codec/codec.proto
Because signing and encoding are separated and apps will know how to encode
a signing messages, we can provide a gRPC/REST endpoint that allows for generic
Copy link
Contributor

Choose a reason for hiding this comment

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

we can provide a gRPC/REST endpoint that allows for generic
app-independent transaction submission. 

I don't understand what this means. Are you referring to a type to be used to generate a JSON blob which when provided to /tx/broadcast will be JSON decoded and then re-encoded using the app-specific tx encoding scheme?

Copy link
Member Author

Choose a reason for hiding this comment

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

It's not json, it's protobuf via gRPC. Basically this AnyTransaction type which is not app dependent

Copy link
Member Author

Choose a reason for hiding this comment

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

And yes, the rpc endpoint would re-encode this in the app level transaction that uses a oneof

Copy link
Member

Choose a reason for hiding this comment

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

It's not json, it's protobuf via gRPC

This makes sense. But in this case, isn't the term "REST" in "we can provide a gRPC/REST endpoint" misleading in this paragraph? I mean RPC and REST are entirely different API concepts and when creating a bridge from REST to gRPC, it would require more explanation.

Copy link
Contributor

Choose a reason for hiding this comment

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

I still don't follow this @aaronc. I think it can be made more clear or explicit.

Copy link
Member Author

Choose a reason for hiding this comment

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

I will remove the part about REST here and just say gRPC because REST refers to grpc-gateway and that's a separate topic.

StdSignDocBase base = 1;
repeated Message msgs = 2;
```proto
message AnyTransaction {
Copy link
Contributor

Choose a reason for hiding this comment

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

It's not clear to me what purpose AnyTransaction serves apart from being used during tx signing. How does this fit into tx generation and broadcasting?

Are you stating that module tx endpoints will generate tx JSON blobs using AnyTransaction. Will these JSON blobs then be fed to /tx/broadcast, where they're JSON decoded and then Proto re-encoded?

Please make this very clear.

Copy link
Member

Choose a reason for hiding this comment

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

This should be SignDoc+signatures, i.e. a signed transaction in an application agnostic container.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes AnyTransaction can be used for tx broadcasting. It is related to SignDoc but not quite the same. This is basically the same exact design that we currently have with amino. It just involves a re-encoding step to translate Any to the oneof's

docs/architecture/adr-020-protobuf-transaction-encoding.md Outdated Show resolved Hide resolved
@@ -73,27 +74,57 @@ and includes all the core field members that are common across all transaction t
Developers do not have to include `StdTxBase` if they wish, so it is meant to be
used as an auxiliary type.
Copy link
Member

Choose a reason for hiding this comment

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

What would be the alternative to using StdTxBase? Signatures need to go somewhere. Even slightly changing this type probably has a lot of consequences. Right now the sentence sounds like you can just drop StdTxBase.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think this is intended to imply that apps can override the std behavior

StdSignDocBase base = 1;
repeated Message msgs = 2;
```proto
message AnyTransaction {
Copy link
Member

Choose a reason for hiding this comment

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

This should be SignDoc+signatures, i.e. a signed transaction in an application agnostic container.

docs/architecture/adr-020-protobuf-transaction-encoding.md Outdated Show resolved Hide resolved
docs/architecture/adr-020-protobuf-transaction-encoding.md Outdated Show resolved Hide resolved
Copy link
Contributor

@alexanderbez alexanderbez left a comment

Choose a reason for hiding this comment

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

conceptACK

@aaronc aaronc marked this pull request as draft April 27, 2020 14:41
@aaronc aaronc changed the title Update ADR 020 to address client-side tx UX Update ADR 019 and 020 to reflect usage of Any Apr 27, 2020
@aaronc aaronc changed the title Update ADR 019 and 020 to reflect usage of Any Update ADRs 019 and 020 to reflect usage of Any Apr 27, 2020
@aaronc aaronc changed the title Update ADRs 019 and 020 to reflect usage of Any Update ADR 019 to reflect usage of Any Apr 27, 2020
@aaronc aaronc changed the title Update ADR 019 to reflect usage of Any Update ADR 020 to reflect usage of Any Apr 27, 2020
@aaronc aaronc changed the title Update ADR 020 to reflect usage of Any Update ADR 020 to address client-side tx UX Apr 27, 2020
@aaronc
Copy link
Member Author

aaronc commented Apr 27, 2020

Closed in favor of #6081

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T: ADR An issue or PR relating to an architectural decision record
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants