v2alpha1: Add LayerService with transaction and block definition #319
Conversation
spacemesh/v2alpha1/layer.proto
Outdated
|
|
||
|
|
||
| service LayerService { | ||
| rpc Get(LayerRequest) returns (Layer); |
There was a problem hiding this comment.
i suggest to add proper List/Stream api like you did for several other services and drop this not so useful Get
| message BlockV1 { | ||
| bytes id = 1; // block hash | ||
| repeated Transaction transactions = 2; // block transactions, in canonical order | ||
| } |
There was a problem hiding this comment.
i think this is also not so useful, would be better to report block hash and provide List/Stream apis for rewards and transactions
kacpersaw
force-pushed
the
v2alpha1-layer
branch
from
8196258
to
341403c
Compare
Bumps [google.golang.org/grpc](https://github.com/grpc/grpc-go) from 1.62.1 to 1.63.0. - [Release notes](https://github.com/grpc/grpc-go/releases) - [Commits](grpc/grpc-go@v1.62.1...v1.63.0) --- updated-dependencies: - dependency-name: google.golang.org/grpc dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]>
|
@kacpersaw just a couple of clarifications from #287: Can you confirm that we intend API v2 to only return the canonical block for a layer, same as API v1? (#287 (comment)) How do we intend the API to reveal tx status and validity? Is the plan to add this later? (#287 (comment)) How do we intend the API to report reorg events? Thanks. |
Yes, only applied block will be returned.
This PR is about LayerService, we can discuss this in TransactionService PR when it'll be created.
How do you want it to look like? |
There was some discussion of this in #38 but it was inconclusive. I think as a next step it would be good to see how APIs for other projects handle this case. For the purposes of this PR let's just do something simple and reasonable; we can continue the discussion in #38 to decide how we want to handle this more correctly and completely (ideally, API v2 should include this). I don't see any issue with I don't think this issue should block merging of this PR. Let's sort this out in #38. |
API v2 spec #300
Add new layer service for v2alpha1 based on API v2 spec.