-
Notifications
You must be signed in to change notification settings - Fork 26
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
non-node clients grpc api proposal #560
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
[package] | ||
name = "chain-watch" | ||
version = "0.1.0" | ||
authors = ["Enzo Cioppettini <[email protected]>"] | ||
edition = "2018" | ||
|
||
[dependencies] | ||
prost = "0.7" | ||
|
||
[dependencies.tonic] | ||
version = "0.4" | ||
default-features = false | ||
features = ["codegen", "prost"] | ||
|
||
[build-dependencies.tonic-build] | ||
version = "0.4" | ||
default-features = false | ||
features = ["prost"] | ||
|
||
[features] | ||
default = ["tonic/transport", "tonic-build/transport"] | ||
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
fn main() { | ||
tonic_build::compile_protos("proto/watch.proto").unwrap(); | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,60 @@ | ||
syntax = "proto3"; | ||
|
||
package iohk.chain.watch; | ||
|
||
|
||
message Block { | ||
bytes content = 1; | ||
} | ||
|
||
message BlockSubscriptionRequest {} | ||
|
||
message TipSubscriptionRequest {} | ||
|
||
message MempoolSubscriptionRequest {} | ||
|
||
message SyncMultiverseRequest { | ||
// send blocks with this chain_length or greater | ||
uint32 from = 1; | ||
} | ||
|
||
message BlockId { | ||
bytes content = 1; | ||
} | ||
|
||
message MempoolEvent { | ||
bytes fragment_id = 1; | ||
oneof event { | ||
MempoolFragmentInserted inserted = 2; | ||
MempoolFragmentRejected rejected = 3; | ||
MempoolFragmentInABlock in_a_block = 4; | ||
}; | ||
} | ||
|
||
|
||
message MempoolFragmentInserted {} | ||
|
||
message MempoolFragmentRejected { | ||
string reason = 1; | ||
} | ||
|
||
message MempoolFragmentInABlock { | ||
BlockId block = 1; | ||
} | ||
|
||
|
||
service SubscriptionService { | ||
// get a stream of blocks succesfully processed by the node, this means they | ||
// are already validated. | ||
// the parent of a block will always be streamed before the block itself. | ||
rpc BlockSubscription(BlockSubscriptionRequest) returns (stream Block); | ||
|
||
// get tip updates | ||
rpc TipSubscription(TipSubscriptionRequest) returns (stream BlockId); | ||
|
||
rpc MempoolSubscription(MempoolSubscriptionRequest) returns (stream MempoolEvent); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And now I am not sure that this should belong to chain-libs. We usually did not introduce the concept of mempool at the chain-libs level. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, current plan is to move it to chain-network, actually. If we put this in jormungandr... And we want to re-use from a different repository, then we would have to include jormungandr there somehow? Although, @mzabaluev motivation to put it in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah, mostly that I think.
Not a huge problem, we are doing that for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd rather disentangle protocol things from jormungandr. And yes, I would prefer to move this into chain-network as a separate module. |
||
|
||
// fetch all blocks from the given initial chainlength to the tip, from all | ||
// possible branches and in increasing order | ||
rpc SyncMultiverse(SyncMultiverseRequest) returns (stream Block); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There might be consistency issues, e.g. branches starting from different roots. But I guess we just let the client to deal with that. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm curious about when that can happen, you mean branches with different genesis? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, I meant something like that:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There should be more documentation on how the blocks will be ordered in presence of multiple branches. Perhaps the service needs only to guarantee the order of parent-child relationships, i.e. never send a child before its parent. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's clarify how would a client use this API. If I run an explorer and have several branches with different chain lengths in storage, should I request sync with the shortest length I have? Or should I start from the stability depth, since the branches I have stored might have been discarded by the consensus? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Until the explorer has a database I guess you need to start from 0. But after that, I was thinking on starting from Also, I was thinking on sending all blocks of a given height before the next one, separate branches can be applied potentially in parallel, so I think it's better than sending one branch at a time. I did write this because it was the simplest thing I could think of, though... Originally I thought about the explorer sending the list of tips it has, but that's not that simple I think. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've been also been wondering if this endpoint shouldn't be merged with the live block subscription, because otherwise there is a chance of missing a block in the middle if you switch from one stream to the other. In that case the block subscription could have an optional parameter to sync before, and then start sending new blocks. But clients can work around that by starting both I guess, I'm not really sure what's idiomatic here. |
||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. same here |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
tonic::include_proto!("iohk.chain.watch"); |
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.
A newline please :)