Describe group creation process and next steps - #28
Conversation
mhluongo
left a comment
mhluongo
left a comment
There was a problem hiding this comment.
Left some early comments to go with this. Biggest conceptual idea is that there's no leader, and I'm not sure it's a useful crutch- I think we need to go straight to sibling nodes with the blockchain as a leader / dealer / oracle.
Another concern- we all need to use the same language or we'll be talking past eachother. Check out https://github.com/keep-network/keep-core/blob/master/docs/glossary.adoc (pinned version https://github.com/keep-network/keep-core/blob/57573951db51082cc743ccca442528004b20466d/docs/glossary.adoc). If you need new concepts / names, make sure they go there as well
| Here's a list of the components from the diagram above and what each one does. | ||
|
|
||
| **CLI** - Client that want us to generate a random number | ||
| * request random number |
There was a problem hiding this comment.
Relay requests are coming in on the Ethereum chain- if we allow requests off-chain there's no canonical ordering, so it's not clear which entry is the tip
| **CLI** - Client that want us to generate a random number | ||
| * request random number | ||
|
|
||
| **KMA** - Keep Master that acts as gate keeper between the chain and random#-generating-groups |
There was a problem hiding this comment.
We can't have a "master" or master election without losing the uptime and censorship benefits of a threshold signature. Each node in a group needs to do these things themselves, and coordinate at a bare minimum (eg to publish the key to the chain)
|
|
||
| **KMA** - Keep Master that acts as gate keeper between the chain and random#-generating-groups | ||
| * init new group creation | ||
| ** set # of nodes in group |
There was a problem hiding this comment.
This will be a network-wide magic number
| **KMA** - Keep Master that acts as gate keeper between the chain and random#-generating-groups | ||
| * init new group creation | ||
| ** set # of nodes in group | ||
| ** select nodes that can join |
There was a problem hiding this comment.
This needs to be decided by the last relay entry using sortition across all stakers, rather than an elected leader
|
|
||
| **ETH** - Ethereum blockchain | ||
| * run contract to verify stake | ||
| * accepts published random number |
There was a problem hiding this comment.
This is also where relay requests are published, relay entries are challenged and validated, and stakes are slashed in the case of misbehavior. It also pays our participants
| * The swim lane diagram may not be correct but it helps me visualize the system's components and can be a good point of discussion on Monday. | ||
| * How do clients initially request a random number? | ||
| * Are we using the concept of a Leader node rather than KMA (Keep Master node) to set # of members in group, dissolve group, etc? | ||
| * Is there a need for assigning a "group number"? |
There was a problem hiding this comment.
The group public key (or a hash of the key) works as an ID
|
|
||
| * The swim lane diagram may not be correct but it helps me visualize the system's components and can be a good point of discussion on Monday. | ||
| * How do clients initially request a random number? | ||
| * Are we using the concept of a Leader node rather than KMA (Keep Master node) to set # of members in group, dissolve group, etc? |
There was a problem hiding this comment.
Neither- the nodes are siblings. The only "leader" is the blockchain, acting as a dealer and arbitrator. There is an idea of a "leader group", as an existing group gets chosen each relay request
|
Not sure whether there's supposed to be code with this. Worthwhile PR either way, but it sounds like you've got some code you're playing with- might as well include it for discussion |
run-relay.sh creates a docker network for and runs relay nodes, each with its own IP address. - The first node will be the leader node; The remaining nodes are worker nodes. - This will allow from 4 to 245 nodes per relay group
|
This PR seems like it's probably not the main development direction at the moment, so we can probably close it in favor of the redo of #39, right? |
|
Closing this PR in favor of the redo of #39 |
Add pagination to subgraph queries
3 participants
Please don't be alarmed by the blue components (KMA, WRK, GRP). They are conceptual and may not be represented as such in the code.