-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
Conversation
Codecov Report
@@ Coverage Diff @@
## master #6031 +/- ##
=======================================
Coverage 54.69% 54.69%
=======================================
Files 424 424
Lines 25790 25790
=======================================
Hits 14107 14107
Misses 10708 10708
Partials 975 975 |
Co-Authored-By: Alexander Bezobchuk <[email protected]>
A good stress test, have as many people review this as possible and see if the proposed changes make sense 👍 |
```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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
@@ -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. |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
conceptACK
Closed in favor of #6081 |
ref: #6030
For contributor use:
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerFor admin use:
WIP
,R4R
,docs
, etc)