Libraries for Cryptographic Sortition and VRF#37
Libraries for Cryptographic Sortition and VRF#37Olshansk merged 87 commits intomilestone/v1-prototypefrom
Conversation
- Support 4 validators + 1 local debugging client - Debug ports are specified but disabled
…s used by the Dockerfile
@Olshansk Did you mean to say "don't make any changes to the existing prototype?" |
|
Yup, thanks for the catch @luyzdeleon! Updated. |
| ) | ||
|
|
||
| type EventsChannel chan types.Event | ||
| type EventsChannel chan types.PocketEvent |
There was a problem hiding this comment.
Pocket should not be used as a prefix IMO
| // The key is a hex encoded representation of the validator byte address. | ||
| type ValMap map[string]*Validator | ||
|
|
||
| type Validator struct { |
There was a problem hiding this comment.
There's going to be a lot of contention around this structure as at this time there's not good justification to have a shared Validator type
It needs to be made more explicit that this is a temp
luyzdeleon
left a comment
There was a problem hiding this comment.
I think this PR is in a good direction, if I might summarize my pending questions are:
-
Staked amounts being handled as float types when they should be ints (uPOKT vs POKT denominations).
-
Why is there PreP2P module code included in this PR?
-
Some shared data structures like the Validator would be more appropiate inside of the
consensus_types
| } | ||
|
|
||
| networkMessage := types.PocketEvent{} | ||
| if err := proto.Unmarshal(data, &networkMessage); err != nil { |
There was a problem hiding this comment.
I agree with having a single "Encoder/Decoder" interface and let that use anything it needs underneath.
Olshansk
left a comment
There was a problem hiding this comment.
@luyzdeleon @andrewnguyen22 Please take another look when you have a chance. Some things to keep in mind:
-
Since our git histories are a little messy right now, the original PR extended more than just the base crypto libraries here, but that is mostly resolved and the PR is much smaller.
-
I refactored the tests and added a lot more documentation in
sortition.goandsortition_test.go, so that can be the focus of the re-review. -
I added details as to why I chose this VRF library over others, but ultimately I don't have super strong reasoning one way or another.
Olshansk
left a comment
There was a problem hiding this comment.
@andrewnguyen22 Tended to the last set of comments.
PTAL at the README again as I added some interesting points there.
|
@luyzdeleon Please take a look again when you have a chance. The two places I'd focus on per your comments are:
|
Description
This PR is meant to partially address the V1 consensus prototype: #28.
It is a set of libraries that are meant to be used for leader election as described in the consensus spec.
Please note that these are just standalone libraries that do not make any changes to the existing prototype and can be reviewed independently from other changes.
Details
Testing
1. Pull changes (if not already local):
2. Run unit tests
[Optional] The log statement in
TestSortitionBasiccan be commented out for some visibility as to whatmake test_sortitiondoes.