-
Notifications
You must be signed in to change notification settings - Fork 214
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
poet: allow one submission of PoST per miner per round per poet service #3458
Comments
Design proposalUpon registration, the node should provide:
PoET service steps:
Optional
If any is invalid, then the produced ATX would be invalid. Allowing this to happen is applicable, but verifying it might allow dropping the requirement for nodes to sign the registration request; it is enforcing validity on the registration data, and by doing so making a registration counterfeit a non-issue: if/when the node will register for the given round, and fail due to the previous registration, it will still be able to listen to the broadcasted results and utilize it. Footnotes
|
LGTM Good job on the structure of this spec! Very readable, keeping the technicalities to the footnotes... |
## Motivation Structures for Poet's GRPC API are duplicated in go-spacemesh code without good reason. Prework for: #3458 ## Changes Removed duplicated structures and use the structures autogenerated from poet's API protosbufs. ## Test Plan unit tests ## DevOps Notes - [x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources) - [x] This PR does not affect public APIs - [x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.) - [x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)
@moshababo What about go-spacemesh/common/types/activation.go Lines 100 to 111 in 9d921e4
|
It needs to be added as well (I didn't mention it because it didn't exist at the time I wrote the proposal). |
@moshababo, I have a few questions:
Could You please update the design proposal to include it? I guess that the challenge hash for an initial ATX:
should include
Could You please point out these rules?
Do I understand correctly that Poet is supposed to call back the Node that submitted challenge data to ask it for more details? These details will always be required, so perhaps they should be passed in the initial Alternatively, to avoid figuring out how to call back the node and create a grpc client for it etc., a bidirectional GRPC stream could be used. The server (Poet) would send commands in response to These commands could be in form of rpc Submit (stream SubmitRequest) returns (stream SubmitResponse) {}
message ATX {
....
}
message SubmitRequest {
message ChallengeData {
...
}
oneof cmd {
ChallengeData submit = 1;
ATX atx = 2;
}
}
message SubmitResponse {
message Finished {
string roundId = 1;
bytes challenge_hash = 2;
}
oneof cmd {
bytes fetch_adx = 1;
Finished finished = 2;
}
} |
@moshababo few more questions:
Why not just pass the sequence in the challenge data?
Challenge data must be serialized consistently anyway for signing. How about we use the serialized representation for hashing too? Then it would become consistent for both cases (initial and non-initial):
(I cannot decide ATM if What about the structure of an ATX? It currently contains the |
Yes, the challenge hash should include it. I think that updating the original proposal comment isn’t the best approach (assuming it won’t be the last time). I suggest that you’ll maintain a snapshot of the latest design/impl specs elsewhere, or just consider the entire thread for that purpose.
The PoST consensus rules are currently defined in the node’s config, with the following params:
The PoST config are network-level params, so they will need to be queried just once.
The value is ought to be the prev sequence + 1. So I didn’t see much utility in passing and then verifying it, instead of just computing it. But passing it might allow better flexibility for future use cases.
This serialization and hashing are currently done in the node. The implementation purpose is to mimic it. Appending well-defined byte arrays is the simplest way to serialize, and the usual practice for producing preimages. I’m not sure that incorporating a more robust serialization scheme is needed here, even if it’s used elsewhere.
The ATX wire serialization is defined in the node's gRPC API via protobuf. Once fetched, that should be sufficient in order to perform the associated checks. Why else would you need to define it separately? |
## Motivation The extra K1 and K2 are needed in Poet for #3458 Closes #3707 ## Changes Fill K1 and K2 in `SmesherService::PostConfig` ## Test Plan unit tests ## DevOps Notes - [x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources) - [x] This PR does not affect public APIs - [x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.) - [x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)
## Motivation Implemented service for verifying poet challenges by its trusted gateway. Poet is supposed to relay submitted challenges to its gateway for verification and hashing. Part of #3458 ## Test Plan - unit tests - tested e2e (systests) with updated poet POC using this service ## DevOps Notes - [x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources) - [x] This PR does not affect public APIs - [x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.) - [x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)
## Motivation Part of #3458 Closes #3708 ## Changes Updated the poet client and the nipost builder to use the new extended Poet Submit API. ## Test Plan - unit tests - e2e system tests with the new Poet ## DevOps Notes - [x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources) - [x] This PR does not affect public APIs - [x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.) - [x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)
## Motivation Part of #3458 Closes #3708 ## Changes Updated the poet client and the nipost builder to use the new extended Poet Submit API. ## Test Plan - unit tests - e2e system tests with the new Poet ## DevOps Notes - [x] This PR does not require configuration changes (e.g., environment variables, GitHub secrets, VM resources) - [x] This PR does not affect public APIs - [x] This PR does not rely on a new version of external services (PoET, elasticsearch, etc.) - [x] This PR does not make changes to log messages (which monitoring infrastructure may rely on)
Done |
Description
condensing Noam's comments in slack:
To enforce this, the node will need to submit the entire “poet challenge” (NIPostChallenge) to the PoET and it will calculate the hash itself (could be good to return the hash in the response)
This part is not trivial, I think we may want the PoET to ask a node (it already has access to the “PoET gateway” - maybe we should rename it) to validate this data structure.
If this is a smesher’s first ATX, then the NIPostChallenge includes the initial PoST proof - which needs to be validated.
If it’s a subsequent ATX, the NIPostChallenge only includes a reference to the PrevATXID - that previous ATX includes the PoST proof that came after the previous PoET run (we only do one PoST proof each epoch). So validation here must be contextual - the challenge only tells the PoET which smesher it is, but to validate that they still expend resources, we must actually inspect the mesh. This is trivial for the node to do, but not for the context-less PoET.
Tasks:
The text was updated successfully, but these errors were encountered: